[Web] DNS (Domain Name System)

인터넷에 연결된 각각의 컴퓨터 등의 장치를 호스트(host)라고 부른다. 그리고 전 세계의 호스트들은 서로 통신을 하기 위해 반드시 IP 주소를 가지고 있어야 한다. 초창기에는 이러한 IP 주소를 이용하여 다른 호스트에 접속하는 것만으로도 큰 혁명이었다. 그러나 점점 IP 주소를 기억해서 사용하는 것에 대한 불만이 쏟아져 나오기 시작했고, 이로 인해 DNS(Domain Name System)라는 것이 탄생하였다. DNS 기술의 핵심은 숫자로 되어 있어서 기억하기 어려운 IP 주소에 이름을 붙여주는 것이며, 이를 위해서는 도메인 이름과 IP 주소 사이의 맵핑 정보들을 기록하고 있는 DNS 서버가 필요하다. 이번 포스팅을 통해 DNS 기술에 대해 한 번 알아보도록 하자.

 

1. hosts 파일

각 운영체제는 정해진 경로(검색을 통해 알아보자)에 hosts라는 파일이 위치한다. 이 파일의 역할은 도메인 이름과 IP 주소 사이의 맵핑 정보들을 기록해두는 것으로, 전화번호부와 유사한 역할을 수행한다. 브라우저는 도메인 이름을 통해 접속을 시도할 때 가장 먼저 이 파일의 내용을 참조하며, 이 파일에 해당 도메인 이름의 맵핑 정보가 존재하지 않으면 DNS 서버에게 질의한다(아래에서 자세히 설명할 예정). 

 

그러나 이 파일은 함부로 수정할 수 없게 되어 있기 때문에 수정하려면 관리자 권한으로 편집기를 실행한 후에 이 파일을 열어서 수정해야 한다. 왜 함부로 수정할 수 없게 했을까? 심각한 보안 위협에 노출될 수 있기 때문이다. 해커가 내 컴퓨터의 hosts 파일을 조작할 수 있다면, 내가 자주 방문하는 도메인 이름에 악성 사이트의 IP 주소를 맵핑시킴으로써 개인정보를 빼갈 수 있다. 더군다나 그 악성 사이트의 생김새가 원래 방문하려는 사이트와 매우 유사하다면 이 사실을 눈치조차 채지 못할 수도 있다(이러한 해킹 수법을 피싱이라고 한다). 따라서 hosts 파일은 백신을 통해 수시로 변조되지는 않는지 검사 되도록 하는 걸 권장한다.

 

2. DNS의 태동 (DNS 탄생 이전)

앞서 설명한 hosts 파일의 내용은 당연하게도 내 컴퓨터에서만 유효하다. 따라서 도메인 이름과 IP 주소의 맵핑 정보들을 모든 호스트들이 공유하려면 모든 호스트가 동일한 hosts 파일을 가지고 있어야 한다. 그래서 인터넷 초창기에는 Standard Research Institute(이하 SRI)라는 기구에서 하나의 hosts 파일을 관리하고, 이를 모든 호스트들이 다운로드하여서 사용하곤 하였다. 특정 IP 주소에 도메인 이름을 붙이고 싶다면 이를 SRI에게 요청을 하고, 그러면 SRI의 직원이 해당 내용을 hosts 파일에 수기로 기록하는 방식이다. 이러한 방식도 초창기에는 충분히 혁신적이었다. 그러나 시간이 갈수록 많은 한계에 부딪혔다. 해당 hosts 파일을 다운로드하기 전까지는 추가/수정된 도메인 이름에 대해 알 수 없었고, hosts 파일을 수정하는 것 또한 사람이 수기로 하는 것이다 보니 비효율적일 수밖에 없었다. 이러한 문제점들을 해결하기 위해 탄생한 기술이 바로 DNS(Domain Name System)이다(1983).

 

3. DNS의 기본 동작 원리

DNS 서버는 도메인 이름과 IP 주소들의 맵핑 정보들을 내부적으로 레코드(Record)의 형태로 기록한다. 그리고 각각의 호스트들은 인터넷에 연결되는 순간에 자동으로 (로컬) DNS 서버의 IP 주소가 세팅된다. 이제 브라우저에 도메인 이름을 입력하여 접속을 시도하면, 우선 파일 시스템에 존재하는 hosts 파일의 내용을 확인한다. 만약 그곳에서 해당 도메인 이름의 IP 주소를 알아내지 못하면, 미리 세팅되어 있는 DNS 서버에게 찾아가서 해당 도메인 이름의 IP 주소를 물어본다(이를 '질의'라고 표현한다). 기존 방식과 비교했을 때 DNS는 도메인 등록 행정 절차가 간소화 및 자동화되었을 뿐만 아니라, DNS 서버 내부에서 도메인 이름과 IP 주소의 맵핑 정보가 수정/추가되는 즉시 해당 DNS 서버를 사용하는 모든 호스트들은 그 사실을 알게 된다는 장점이 있다.

 

4. Public DNS 서버

앞서 간단히 말했지만, 모든 호스트들은 인터넷에 연결되는 즉시 가입한 통신사(Internet Provider, ISP)에 따라 사용할 (로컬) DNS 서버의 IP 주소가 자동으로 세팅된다. 그런데 자동으로 세팅된 DNS 서버가 아닌 다른 DNS 서버를 사용하고 싶을 수도 있다. 예를 들어, 기본적으로 DNS 서버는 우리가 무슨 도메인 이름으로 접속하려 하는지 모두 알 수 있기 때문에 자동으로 연결된 DNS 서버를 신뢰하지 않을 수도 있다. 이러한 경우에 사용할 수 있도록 무료로 제공되는 DNS 서버들이 바로 Public DNS 서버이다. 실제로 구글에 검색해 보면 여러 종류의 Public DNS 서버가 존재함을 알 수 있다. DNS 서버를 수동으로 설정해주는 법은 운영체제별로 다르니, 검색을 통해 직접 알아보도록 하자.

 

5. 도메인 이름의 구조

실제로 DNS 서버는 한 대만 존재하는 것이 아니라 수천수만 대가 전 세계에 흩어져 있다. 이를 이해하려면 도메인 이름의 구조를 알아야 한다. blog.example.com이라는 도메인 이름을 예로 들면, 도메인 이름의 구조는 다음과 같다. 참고로 맨 뒤의 .은 생략되어 있는 것이다. 실제로 맨 뒤에 .을 붙여서 입력해도 동일하게 인식된다는 것을 알 수 있을 것이다.

 

▼ 도메인 이름의 구조 (출처 : 생활코딩)

 

.은 Root 도메인, com은 Top-level 도메인(이하 TLD), example은 Second-level 도메인(이하 SLD), blog는 서브 도메인을 의미한다. 그리고 각 부분별로 이를 담당하는 네임 서버(또는 DNS 서버)들이 존재한다. 즉 '.' 도메인을 담당하는 Root 네임 서버가 존재하고, com 혹은 net 등의 도메인을 담당하는 TLD 네임 서버들이 존재하며, example.com 또는 example.net 등의 도메인을 담당하는 SLD 네임 서버들이 존재하는 식이다. 참고로 NS라는 네임 서버가 D라는 도메인을 담당할 때, "NS가 D의(에 대한) Authoritative 네임 서버"라고 표현(NS가 D에 대한 권한을 가지기 때문)한다.

 

한편, 각 네임 서버는 자신이 담당하는 도메인의 하위 도메인을 담당하는 네임 서버의 위치 정보(도메인 이름)를 알고 있다. 즉 Root 네임 서버들은 TLD 네임 서버들의 위치 정보를 알고 있고, TLD 네임 서버들은 SLD 네임 서버들의 위치 정보를 알고 있다. 그리고 최하위 도메인을 담당하는 네임 서버들은 자신이 담당하는 도메인 이름에 맵핑된 IP 주소를 알고 있다.

 

이러한 맥락을 바탕으로 앞서 설명했던 DNS의 기본 동작 원리를 조금 더 자세히 풀어보면 다음과 같다. 도메인 이름 blog.example.com에 해당하는 IP 주소를 알아내는 과정을 예로 들어보겠다. 참고로 앞서 언급했던, 인터넷이 연결되는 즉시 IP 주소가 세팅되는 DNS 서버는 특별히 로컬 네임 서버라고 부른다.

 

1. 파일 시스템에 존재하는 hosts 파일의 내용 확인
2. 로컬 네임 서버가 Root 네임 서버에게 질의 : com 담당 네임 서버의 위치 정보를 대신 알려준다.
3. 로컬 네임 서버가 com 담당 네임 서버에게 질의 : example.com 담당 네임 서버의 위치 정보를 대신 알려준다.
4. 로컬 네임 서버가 example.com 담당 네임 서버에게 질의 : blog.example.com 담당 네임 서버의 위치 정보를 대신 알려준다.
5. 로컬 네임 서버가 blog.example.com 담당 네임 서버에게 질의 : 요청된 도메인에 맵핑된 위치 정보를 알려준다.
6. 로컬 네임 서버가 응답받은 IP 주소를 가지고 브라우저가 해당 IP 주소에 접속을 시도한다.

 

▼ DNS 상세 동작 원리

 

6. 도메인 등록 과정과 원리

그렇다면 도메인을 등록하는 과정은 어떠할지 간단히 알아보자. 이를 이해하기 위해서는 우선 총 네 개의 주체를 기억해야 한다. 바로 ICANN(국제 인터넷 주소 관리 기구), 등록소(Registry, 레지스트리), 등록대행자(Registrar, 레지스트라), 등록자(Registrant, 레지스트란트)이다. 각각에 대해 한 번 알아보자.

 

• ICANN : 전 세계의 IP 주소를 관리하고, (13개의) Root 네임 서버들을 관리하는 비영리 기구이다.
• 등록소 : TLD 네임 서버들을 관리하는 기구들을 일컫는다. 각 TLD는 반드시 하나의 등록소에 의해 관리되지만, 하나의 등록소는 여러 TLD를 관리할 수 있다. 예를 들어 VeriSign이라는 등록소는 com 도메인뿐만 아니라 net 도메인도 함께 관리한다.
• 등록대행자 : 우리가 도메인을 등록하고자 할 때 이용하는 기관들을 일컫는다(EX. 가비아 등).
• 등록자 : 우리와 같이 등록대행자를 통해 도메인을 등록하고자 하는 개인이나 기업을 일컫는다.

 

등록자가 eldorado.com이라는 이름의 도메인을 등록하는 과정은 다음과 같다. 레코드에 대한 설명은 뒷부분을 참고 바란다.

 

1. 등록대행자에게 eldorado.com이라는 이름의 도메인 등록을 요청한다. (유효한 도메인 이름이라 가정)
2. eldorado.com에 대한 Authoritative 네임 서버를 한 대 준비한다. 그러나 대부분 등록대행자가 이러한 네임 서버를 제공한다.
3. 등록대행자에게 앞서 구축한 Authoritative 네임 서버의 위치 정보(도메인 이름)를 전달하고, 등록대행자는 이를 다시 등록소에게 전달한다. 그러면 등록소는 전달받은 Authoritative 네임 서버의 위치 정보를 com 담당 네임 서버에 기록한다. 이는 곧 NS 타입의 레코드를 추가해주는 것을 의미한다(eldorado.com NS ???). 만약 등록대행자가 자동으로 네임 서버를 제공했다면, 이 과정은 자동으로 진행될 것이다.
4. Authoritative 네임 서버에 eldorado.com에 맵핑되는 IP 주소를 세팅해준다. 이는 곧 A 타입의 레코드를 추가해주는 것을 의미한다(eldorado.com A ???). 이로써 도메인 등록이 완료된다. 필요한 경우, 서브 도메인을 위한 레코드를 이곳에 추가할 수도 있다(이렇게 하면 도메인을 별도로 다시 구매할 필요가 없다).

 

▼ 도메인 등록 과정과 원리 (출처 : 생활코딩)

 

7. DNS record & CNAME

앞에서 살펴본 것처럼 각각의 DNS 서버에는 특정 도메인 이름에 대한 정보들을 레코드(Record)의 형태로 저장한다. 그리고 각각의 레코드는 타입이 존재한다. 우리가 살펴본 두 가지 타입은 바로 A 타입과 NS 타입이다. A 타입의 레코드는 도메인 이름에 IP 주소를 맵핑하는 정보를 의미하며, NS 타입의 레코드는 가리키는 네임 서버의 위치 정보를 의미한다.

 

이밖에도 유용한 레코드 타입으로 CNAME(= Canonical Name)이라는 것이 존재한다. CNAME 타입의 레코드는 이미 존재하는 도메인 이름에 또 다른 도메인 이름을 맵핑하는 정보를 의미한다. 만약 여러 도메인 이름이 하나의 도메인 이름을 가리키는 상황이라면, 여러 개의 A 타입 레코드를 정의하는 것보다 하나의 A 타입 레코드를 정의하고 나머지 레코드들을 CNAME 타입으로 정의하는 것이 훨씬 효율적이다.

 

▼ 예) eldorado.com의 Authoritative 네임 서버가 가지고 있는 레코드 집합

이름	타입	값	의미
	A	52.231.13.22	eldorado.com에 52.231.13.22 IP 주소를 맵핑
etc	A	52.231.13.22	etc.eldorado.com에 52.231.13.22 IP 주소를 맵핑
api.eldorado.com	CNAME	eldorado.com	api.eldorado.com에 52.231.13.22 IP 주소를 맵핑

 

8. 글루 레코드 (Glue record)

앞에서 알아보았듯이, NS 타입의 레코드는 가리키는(위임받을) 네임 서버의 위치 정보를 IP 주소가 아니라 도메인 이름으로 표현한다. 따라서 로컬 네임 서버에게 해당 네임 서버의 IP 주소를 알려주기 위해서는 해당 네임 서버의 도메인 이름을 대상으로 다시 DNS 질의를 요청해야 한다. (이러한 이유로 모든 네임 서버들은 기본적으로 (13개의) Root 네임 서버의 IP 주소를 알고 있다.) 그런데 만약 IP 주소를 알아내야 하는(= 위임받을) 네임 서버의 도메인 이름이 위임하려는 도메인의 하위 도메인에 해당한다면, 다시 DNS 질의를 요청하더라도 계속 똑같은 곳에 도달함으로써 무한 루프(= 순환적 의존성)에 빠지게 될 것이다.

 

이를 위해 필요한 것이 바로 글루 레코드(Glue record)이다. 만약 위임받을 네임 서버의 도메인 이름이 위임하려는 도메인의 하위 도메인에 해당한다면, 해당 네임 서버의 도메인 이름이 어떤 IP 주소에 맵핑되는지 스스로 알고 있어야 한다. 그래야 DNS 질의가 무한 루프에 빠지지 않기 때문이다. 이러한 목적으로 추가해주는 A 타입의 레코드가 바로 글루 레코드이다. 이로써 위임받을 네임 서버의 IP 주소를 알아내기 위해 추가로 DNS 질의를 요청할 필요가 없어지는 것이다. 물론 네임 서버의 도메인 이름이 위임하려는 도메인의 하위 도메인에 해당하지 않는다면 동일한 방식으로 DNS 질의를 추가로 요청해야 할 것이다.

 

예를 들어, example.com 담당 네임 서버의 도메인 이름이 ns.example.com이라고 가정해 보자. 만약 글루 레코드가 없다면, example.com에 대한 DNS 질의를 진행하는 과정에서 example.com 담당 네임 서버의 IP 주소를 알아내기 위해 다시 example.com에 대한 DNS 질의를 요청할 것이다. 이는 무한 루프를 유발하며, 원인은 바로 ns.example.com이 example.com의 하위 도메인에 해당하기 때문이다. 따라서 com 담당 네임 서버는 example.com 담당 네임 서버에게 도메인을 위임하는 NS 타입의 레코드뿐만 아니라, 순환적 의존성을 해결하기 위한 글루 레코드도 함께 가지고 있어야 한다. 다음과 같이 말이다.

 

• example.com   NS   ns.example.com   # example.com 도메인을 ns.example.com 네임 서버에게 위임
• ns.example.com   A   XXX.XXX.XXX.XXX  # 글루 레코드 (ns.example.com 네임 서버의 IP 주소)

 

더 나은 이해를 위해 또 다른 예시를 하나 준비했다. example.com의 하위 도메인인 sub.example.com을 담당하는 네임 서버의 도메인 이름을 위한 글루 레코드이다. 따라서 이번에는 글루 레코드를 TLD 네임 서버가 아닌 example.com 담당 네임 서버에 추가해야 한다. 다음은 example.com 담당 네임 서버가 가지고 있는 레코드의 상태 예시를 보여준다.

 

• sub.example.com   NS   ns1.sub.example.com
• sub.example.com   NS   ns2.sub.example.com
• ns1.sub.example.com   A   XXX.XXX.XXX.XXX  # 글루 레코드
• ns2.sub.example.com   A   XXX.XXX.XXX.XXX  # 글루 레코드

 

9. nslookup

nslookup이라는 도구를 사용하면 특정 도메인 이름에 맵핑된 IP 주소를 쉽게 알아볼 수 있다.

 

▼ examle.com에 맵핑된 IP 주소 알아보기 ('-type=a'는 A 타입의 레코드를 검색한다는 의미이며, 생략 가능)

 

▼ example.com에 대한 Authoritative 네임 서버의 IP 주소 알아보기 ('-type=ns'는 NS 타입의 레코드를 검색한다는 의미)

 

▼ Authoritative 네임 서버를 통해 example.com에 맵핑된 IP 주소 '정확하게' 알아보기 (캐시 무시)

 

 

 

 

 

 

본 글은 아래 링크의 내용을 참고하여 학습한 내용을 나름대로 정리한 글임을 밝힙니다. (WEB2 - Domain Name System)

https://opentutorials.org/course/3276