[Network] 하향식 접근 네트워크 - 2. Application Layer - (4) DNS

이 글은 이화여자대학교 이미정 교수님의 2014년 2학기 컴퓨터 네트워크 강의를 기반으로 재구성한 것입니다. 삽화는 링크를 출처로, 저작권은 J.F Kurose and K.W. Ross에게 있다는 것을 밝힙니다.

 Application Layer에서는 크게 3가지를 살펴본다.

1. application principle
   
   • client-server 구조
   • peer-to-peer (P2P) 구조
   • transport layer service model
2. internet protocol - HTTP, electronic mail(SMTP, POP3, IMAP), DNS, P2P
3. network application의 작성을 위한 interface - socket, UDP, TCP

 이 글에서는 DNS를 살펴본다.

DNS에 관한 내용은 1%의 네트워크 - 1. 웹 브라우저가 하는 일 포스팅에도 작성되어 있다. 필요 시 참고하면 좋다.

 

 

DNS, Domain Name System

 internet host는 32bit의 IP address를 사용해 식별한다. 그러나 IP address는 사람이 외우기 어렵기 때문에 사용자들은 IP address에 해당하는 이름 - host name, 또는 domain name이라고 부른다. - 을 사용한다.

 때문에 사용자가 작성한 host name을 IP address로 변환하는 과정이 필요한데, [host name - IP address]의 mapping을 가지고 있는 distributed, hierarchical DB가 DNS이다.

DNS는 모든 network application에서 필요하기 때문에 network core에서 지원하는 것이 합리적이다.
그러나 internet의 기본 이념 중 하나는, internet은 packet을 운반만 하고, 나머지는 edge로 모으는 것이다. 이를 달성하기 위해 DNS를 application layer로 뺀다.

 

 

DNS의 기능

1. translation : hostname을 IP address로 변환하는 기능
2. host aliasing : 실제 domain name과 달리, 외부에 알리는 domain name은 유의미하고 짧은 것이 좋다. 때문에 외부에는 별칭을 알리는데, 이 때 별칭을 실제 이름으로 변환하는 것을 말한다.
   • tistory.com을 입력했는데 실제 URL은 www.tistory.com으로 입력되는 경우이다.
3. mail server aliasing : @ 뒤에 있는 것을 사용해 mail server를 식별하는 기능이다.
4. load distribution : server는 분산 처리를 위해 replica가 존재할 수 있다. 이 때 각 server는 다른 IP address를 가지는데, DNS server는 round robin 방식으로 IP address를 알려준다.
   • 예를 들어 127.0.0.1, 127.0.0.2, 127.0.0.3을 DNS server에 등록해 두면 첫 조회에는 127.0.0.1을, 다음 조회는 127.0.0.2를, 다음에는 127.0.0.3을, 다음에는 127.0.0.1을, ... 리턴한다.

 

 

Decentralized하게 사용하는 이유

 DNS는 decentralized(distributed) DB이다. 이렇게 사용하는 데에는 몇 가지 이유가 있다. centralized로 만든 경우를 생각해 보자.

• single point of failure가 발생한다. 만약 중앙 DNS가 멈추면 모든 DNS가 멈추고, 그러면 인터넷이 동작하지 않는다.
• 전 세계가 DNS를 사용하기 때문에 만약 중앙 DNS가 있는 경우 traffic이 몰린다.
• DNS는 utilization이 100%에 가깝게 사용되기 때문에, 유지보수가 어렵다.
• 중앙 DNS부터 거리가 먼 경우 응답시간이 달라지기 때문에 fair하지 않으며, 먼 거리에 packet을 운반시키는 경우 resource가 많이 낭비된다.
• size가 큰 만큼 DB 관리가 어렵다.

 

 

 

DNS Hierarchy

DNS hierarchy

 DNS는 크게 3단계로 나뉘며, 각 layer에 해당하는 DNS server는 자신의 바로 한 칸 아래에 있는 DNS server의 IP address를 가지고 있다.

• root DNS server
• TLD server, Top Level DNS server : 최상위 domain을 관리하는 DNS server이다.
• authoritative DNS server : 각 기관의 DNS server이다.

 

Authoritative DNS Server

 authoritative DNS server는 각 회사나 기관이 관리하는 DNS server으로, 해당 단체에 속해있는 모든 network 기기들의 hostname과 IP address mapping을 관리한다.

 domain은 최상위 domain 아래에 있는 domain들을 관리한다.

www.tistory.com이라는 domain이 있다고 하자. 최상위 domain은 com이고, 그 아래에 tistory domain, 그 아래에 www domain이 있다. authoritative DNS server는 최상위 domain 아래에 있는 domain인 tistory domain을 관리한다.
 tistory domain의 경우, tistory라는 단체에 속해있는 모든 기기들의 hostname - IP address mapping을 가지고 있다.

 

TLD, Top Level DNS server

 TLD server는 최상위 domain에 해당하는 정보를 가지고 있으며, 관리 주체자가 있다. 예를 들어 .kr의 경우 한국인터넷정보센터가 관리하고, .edu의 경우 Educause가 관리하는 식이다.

 TLD server는 authoritative DNS server의 IP address를 가지고 있다.

 

Root DNS Server

 전 세계에 약 10대 정도 있는 server로, 몇 대 없기 때문에 모든 DNS server는 root DNS server의 IP address를 알고 있다. root DNS server는 TLD server의 IP address를 가지고 있다.

 

* Local DNS Server

 local DNS server는 DNS server의 web cache이며, default name server라고도 부르고, proxy naming server라고도 부르기도 한다. local DNS server는 DNS hierarchy에 속하지 않는다!

 local DNS server는 web cache와 동일하게 동작한다.

• host가 DNS query를 날리면 local DNS server로 들어온다.
• hi라면 그 값을 돌려준다.
• miss라면 hierarchy DNS에 query를 날린다. 이 때 query를 날리는 대상은 root DNS server이다.

 

 이 때, web cache와 동일하게 local DNS server도 cache이기 때문에 정보가 유효하지 않을 수 있다. 이를 대비해 TTL, Time To Live를 사용한다.

 

 

 

Name Resolution

 hostname으로 IP address를 찾는 과정을 name resolution이라 한다. 방법은 iteration, recursive 2가지가 있다.

 

Iteration Query

iteration query 방식

 iteration query는 query를 받은 DNS server에 mapping 정보가 없을 때, 어느 DNS server와 contact해야하는지 알려주는 방법이다. 순서는 아래와 같다.

1. 모든 host의 DNS query는 local DNS server로 먼저 간다.
2. local DNS server에 query에 해당하는 정보가 없다. local DNS server는 root DNS server에게 query를 날린다.
3. root DNS server에 query에 해당하는 mapping이 없지만 TLD server의 IP address는 있으므로 이것을 돌려준다.
4. local DNS server가 TLD server에게 query를 날린다.
5. TLD server에 query에 해당하는 mapping이 없지만 authoritative DNS server IP address는 있으므로 이것을 돌려준다.
6. local DNS server가 authoritative DNS server에게 query를 날린다.
7. authoritative DNS server에는 query에 해당하는 mapping이 있으므로 이것을 돌려준다.
8. local DNS server가 host에게 query에 해당하는 mapping을 돌려준다.

 

Recursive Query

recursive query 방식

 recursive query 방식은 query를 받은 DNS가 mapping을 구한 후에 response하는 방식이다. 이 경우 자신에게 해당하는 mapping이 없다면 올 때까지 기다린다.

1. 모든 host의 DNS query는 local DNS server로 먼저 간다. 
2. local DNS server에 query에 해당하는 정보가 없다. local DNS server는 root DNS server에게 query를 날린다.
3. root DNS server에 query에 해당하는 mapping이 없으므로 TLD server에게 요청한다.
4. TLD server에 query에 해당하는 mapping이 없으므로 authoritative DNS server에게 요청한다.
5. authoritative DNS server에는 해당하는 mapping이 있으므로 이를 TLD server에게 돌려준다.
6. TLD server는 root DNS server에게 돌려준다.
7. root DNS server는 local DNS server에게 돌려준다.
8. local DNS server는 host에게 값을 돌려준다.

 

Iterated Query vs Recursive Query

 위 그림만 봐도 알 수 있듯, root DNS server와 TLD의 경우, recursive query를 사용할 때 packet 출입량이 훨씬 많다.

 그러나 실제로는 DNS server는 caching을 사용하므로, iterated query와 recursive query를 섞어 사용한다.

 

 

 

DNS cache

 DNS server는 워낙 traffic이 많기 때문에 web cache와 별개로 DNS server 내부에도 caching을 하며, 이를 통해 network 전체에 흐르는 packet과 delay를 줄일 수 있다.

 caching하는 시점은 어떤 mapping이 DNS server를 지날 때이다. 때문에 DNS cache는 recursive query에서 유용한 방식이다.

 

 한편 local DNS server는 TLD server를 caching하고 있는데, 이를 통해 root DNS server로의 traffic을 줄일 수 있다. 이 때, 모든 cache에서 발생하는 문제인 out of date 문제가 발생하는데, packet의 TTL, Time To Live header를 사용해 해결한다.

 authoritative DNS server나 TLD server가 응답할 때 TTL header를 포함시키는데, local DNS server는 그 시간만큼만 caching한다. 그러나 이 경우, TTL이 끝나기 전에 mapping 정보가 바뀌면 마찬가지로 out of date 문제가 발생하기 떄문에, 만약 hostname - IP address mapping이 변경되는 경우 변경되었다고 internet 전체에 알림을 보내는 규칙이 생겼다.

 

 

 

DNS record

 DNS는 RR, Resource Record를 저장한다. RR에는 크게 [name, value, type, TTL]4가지 정보가 있으며, type에 따라 name과 value가 무엇인지 결정된다.

• type이 A인 경우 : 제일 기본적인 record이다. name은 hostname을, value는 IP address를 의미한다.
• type이 CNAME인 경우 : aliasing을 위한 record이다. name은 별명을, value는 진짜 이름(canonical name)을 의미한다.
• type이 MX인 경우 : value는 name에 해당하는 mail server를 의미한다.
• type이 NS인 경우 : name server를 위한 record이다. name은 domain을, value는 domain에 해당하는 DNS의 hostname을 의미한다.

 

 

 

DNS message

DNS message

 DNS message는 다른 protocol들과 마찬가지로 query와 reply로 나뉜다. query는 질의할 때, reply는 응답할 때 사용하며, 둘의 format은 동일하다. DNS message는 dynamic하기 때문에 각 field에 대한 길이가 header에 위치하며, 이를 통해 body를 식별한다.

• identification : query를 날릴 때 값을 적어 보내면 reply는 똑같은 값을 적어 응답한다. 이를 통해 query와 reply의 pair를 맞출 수 있다.
• flag : 총 4가지 field가 있다.
  • query인지 reply인지 여부
  • recursive query로 탐색해 달라고 요청하는 경우
  • server인 경우, recursive query 가능한지 여부
  • reply가 authoritative DNS server에서 온 것인지 여부
• questions : [host name, host type]으로 이뤄지는 query
• answers : query에 대한 resource record reply
• authority : authoritative DNS server가 보낸 resource record인 경우 여기에 담는다.
• additional info : 추가 정보(필요할 정보)를 알려준다.
  • 예를 들어 mail server를 query로 날린 경우, 해당 IP도 포함해서 알려주는 식이다.

 

 

 

DNS 등록 과정

 다음과 같은 과정으로 새로운 DNS가 등록된다.

1. 단체 관리자가 authoritative DNS server를 산다.
   • web server hostname과 IP를 type A로 mapping한다.
   • mail server의 경우 type MX로 mapping한다.
2. TLD server에 authoritative DNS server의 정보를 알린다. 알리는 정보는 authoritative DNS server IP address, hostname이다.
   • TLD server는 그 정보를 보고 resource record에 추가한다. 추가하는 내용은 NS type으로 authoritative DNS server name, A type으로 authoritative DNS server IP address이다.

 

DNS 등록 과정

 이렇게 DNS가 등록된 이후에는 일반 client가 해당 domain에 접근할 수 있다. 위 그림의 경우 local DNS server가 root DNS로 query를 날리지 않는데, local DNS server에 TLD server가 caching되었다고 보기 때문이다.

 

 

 

 

 

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.