7. DNS for name resolution

1. DNS (Domain name system)

DNS(Domain name system)란 string of letters를 IP address로 resolve하는 광범위한 distributed network service이다. 

이것을 이용하면 단지 웹사이트의 이름을 기억함으로서, 항상 특정 웹사이트에 접속가능하다. 웹서버의 IP주소가 변경되었다고 해도 말이다. 또한, 만약 다른 장소로 이동해 특정 웹사이트를 접속하는 경우 해당 장소와 가까운 서버의 IP주소로 지정함으로서 훨씬 더 빠른 서비스를 받을 수 있다. 쉽게 말해, 원하는 서비스를 받을 수 있는 최적의 길을 알려주는 시스템이다.

 

1) Steps of Name Resolution

Name resolution이란, DNS를 이용해 domain name을 IP address로 바꾸는 과정을 말한다.

Computer가 현대 네트워크 내에서 동작하기위해서는 4가지 요소가 configuration되어 있어야 한다.

- IP address

- Subnet mask

- Gateway for a host

- DNS server

 

DNS server에는 크게 5가지 유형이 있다.

- Caching name servers

- Recursive name servers

- Root name servers

- TLD name servers

- Authoritative name servers

 

하나의 DNS server는 위의 역할 중 여러개를 동시에 할 수 있다.

Caching name server는 일정시간동안 domain name lookup을 저장하는 것이 목적이다. 매 TCP연결설정마다, domain name의 fully qualified resolution을 하지 않도록 하기 위해 이를 구성한다. 

Recursive name server는 full DNS resolution request를 수행한다. 

이러한 Caching, Recursive name server는 주로 ISP나 local network에서 제공되며, 대부분의 경우 하나의 server가 두가지 역할을 동시에 수행한다. 

예를 들어,  Computer A가 www.naver.com 이라는 주소를 입력하면, TCP connection을 위해 IP주소를 알아야하고 Computer A에 설정된 Cache/Recursive DNS server의 IP주소로 해당 사이트의 IP주소를 요청한다. 만약, caching된 것이 없다면 DNS server는 fully recursive resolution을 수행하여  IP주소를 알아낸 뒤, Computer A로 IP주소를 전송한다. 

이후에 같은 local network내에 있는 Computer B가 동일합 웹사이트로 접속하고, 동일한 Cache/Recursive DNS server설정이 되어있다면, 이번에 IP주소를 요청했을 때는 TTL이 아직 지나지 않았다면,  cache에서 꺼내어 바로 IP주소를 응답하게 된다. 

TTL(Time to live)이란, domain name 소유자에 의해 설정되는 값으로, 얼마나 오래 name server가 해당 IP주소항목을 caching할 수 있는지 나타낸다.  예전에는 network bandwidth때문에 하루이상으로 설정되었지만, 요즘에는 인터넷의 발달로 인해 수분에서 수시간 정도로 설정된다. 여전히 TTL이 길게 설정된 경우도 있는데, 이럴 경우 변경된 DNS record가 전체 인터넷에 전달되기까지의 시간은 TTL시간이 된다. 

 

Full recursive resolution은 다음과 같은 과정을 거친다.

(1) Cache/Recursive server는 총 13개가 존재하는 Root name server에 질의한다. 예전에는 지리적인 위치에 따라서 이 중 어떤 server에 접속될지 결정되었지만, 지금은 Anycast 이용하여 결정된다. 이것은 traffic을 location, congestion, link health등의 요인에 따라 다른 목적지로 route 하는 방식이다. 실제로는 root name server의 갯수가 물리적으로 13개는 아니고, 13개의 Authoirity가 root name lookup을 제공한다고 보면된다. 

(2) Root name server는 Cache/Recursive server에 어떤 TLD name server에 query하면 되는지 Respond & Redirection한다. TLD(Top-Level Domain)은 DNS resolution system의 hierarchical구조에서 최상단을 나타낸다. 예를 들어, www.facebook.com 에서  .com을 나타낸다.

(3) Cache/Recursive server는 TLD name server에 query한다. Root name server처럼 anycast로 도달할 수 있는 TLD server가 선택된다. 

(4) TLD name server는 어떤 Authoritative name sever에 query하면 되는지 Respond & Redirection한다. Authoritative name server는 TLD를 제외한 나머지 2부분에 대한 lookup을 담당한다. 예를 들어, www.facebook 이다.

(5) Cache/Recursive server는 Authoritative name server에 query한다. 

(6) Authoritative name server는 해당하는 domain name에 대한 실제 IP address를 응답한다. 

 

이러한 엄격한 구조와 제어의 DNS lookup방식은 악의적인 Redirection을 방지하도록 하는 최선의 방법이다. 

우리가 사용하는 device에도 DNS cache가 있는데, 이것을 이용하면 매 TCP Connection마다 Cache/Recursive server에 요청하지 않고도 특정 domain name의 IP로 데이터를 보낼 수 있다. 

 

2) DNS and UDP

DNS lookup을 TCP방식으로 통신할 경우, full recurvise resolution시 TCP 연결및해제가 여러번 일어나고 패킷자체에 여러 부가적인 정보를 담게되므로 많은 traffic을 발생시킨다. DNS lookup의 목적이 데이터 전송이라는 원래 목적이 아닌 부가적인 목적인 것을 감안하면, 이러한 overhead는 좋지 않다. 따라서, DNS lookup은 UDP방식을 이용하고 응답을 못받았을 경우, 단순히 재전송한다.

 

 

2. Detail of name resolution 

 

1) Resource record types

DNS는 실제로 수많은 정의된 resource record type을 사용하고, 이것은 여러종류의 DNS resolution을 가능하게 한다. 

가장 일반적으로 사용하는 DNS record type은 A record이고, 특정한 domain name이 IPv4 address를 가리킨다.

많은 traffic이 몰리는 domain name의 경우, 하나의 IPv4 address가 아닌 list of address를 return하게된다. 

 

예를 들어, client가 full recursive resolution에 대한 응답으로 10.1.1.1, 10.1.1.2, 10.1.1.3, 10.1.1.4를 받게 된다. client가 이 중 첫번째 IP를 사용하도록 설정되어있는 경우, 만약 10.1.1.1으로부터 응답이 오지 않는다면 다른 IP를 사용할 수 있다.

DNS server는 이러한 순서가 정해진 list를 round robin방식으로 list의 순서를 변경해가며 client에 응답할 수 있다. 1회 변경이 일어났다면, list는 10.1.1.2, 10.1.1.3, 10.1.1.4, 10.1.1.1일 것이다.

이런 방식을 사용하여 traffic의 load를 balancing할 수 있다.

 

또다른 record type으로는 Quad A record가 있다. A record와 다른점은, IPv6를 가리킨다는 점이다.

CNAME record(Canonical NAME record)도 많이 사용한다. 이것은 특정 domain name을 다른 canonical domain name으로 traffic을 Response & Redirect한다. 특정 canonical domain name으로 redirecting하고 싶은 모든 domain name을 CNAME record로 응답하도록 설정함으로서, canonical domain name을 갖는 단일 Authoritative name server가 IP address를 관리하고 변경하도록 설정할 수 있다. 예를 들어, facebook.com을 lookup했을 때, Authoritative name server는 www.facebook.com에 해당하는 Authoritative server 로 traffic을 Response & Redirect 한다. 

 

MX record(Mail eXchange record) 는 특정 domain name에 대해 Mail server를 응답하는 record type이다. Web site의 경우 각각 자신만의 mail server를 가지고 있고, 그곳으로 올바르게 mail이 전송되도록 하기 위해 이를 사용한다. 

SRV record(SeRVice record) 는 특정 domain name에 대해 service의 위치를 알려주는 record type이다. MX record와 다른 점은 MX record는 오직 mail server만을 응답하지만, SRV는 여러 다른 service type을 응답할 수 있다는 것이다. 

TXT record(Text record) 는 특정 domain name에 대해 텍스트(text)를 응답하는 record type이다. 원래는 server, network 정보등 인간이 읽을 수 있도록 메세지를 남기기 위한 목적이다. 하지만 자유형식을 가지고 있기 때문에, 요즘에는 DNS로 의도되지 않은 data를 service provider가 전달하기위해 사용되기도 한다. 예를 들어, network configuration information, additional email information 등이 전달된다. 

 

2) Anatomy of a Domain name

Domain name은 총 3가지 요소로 이루어져있다.

TLD는 Domain name hierarchical구조의 top-level으로  .com, .ecu, .kr, .pizza 등 여러가지 등으로 제한되어있다. 이러한 수많은 TLD를 관리하는 non-profit organization은 ICANN(Internet Corporation for Assigned Names and Numbers)이다.

Domains는 domain name에서 .facebook, .naver 와 같은 부분이며 경계를 나누기 위해 사용한다. TLC name server의 제어는 특정 authoritative name server의 경계 안으로 이동한다. 이것은 개인이나 회사에 의해 선택되어 등록된다. 하지만, 이것은 predefined TLD인 www로 끝나야 하고 이것은 sub domain이다. 

이러한 3가지 요소를 조합하면, FQDN(Fully Qualified Domain Name)을 얻게 된다. 

Register company는 등록되지 않은 domain name을 ICANN과 협의하여 판매하는 회사이고, 여기서 FQDN을 얻을 수 있다. 또한, domain name을 구해하면, subdomain은 우리가 원하는 대로 설정할 수 있다. 

예를 들자면, www.financial.naver.com,  www.interesting.client.naver.com  등이 있을 수 있다. subdomain의 경우 하나의 FQDN에 대해 기술적으로 127 level까지 설정할 수 있고, domain name의 길이 등 여러가지 설정에 대한 제약사항이 있다.

 

3) DNS Zones

DNS zones는 여러 level의 domain을 쉽게 control하기 위해 도입된 관리의 영역이다.

Authoritative name server는 자신의 DNS zone대한 책임을 가지고 있다. Root name server, TLD name server이 각각의 DNS zone에 대한 책임을 가지고 있듯이 말이다. 예를 들어, .com TLD name server는 google.com을 다루지 않는다. 

예를 들어, google.com을 소유한 domain name관리자가 pa.google.com, la.google.com, kr.google.com 으로 subdomain을 나누고 각기 다른 DNS zone으로 설정할 수 있다.

Authoiritative name server은 Zone File을 이용해 특정 zone의 모든 resource record를 declare한다. 참고로 zone file은 반드시 SOA(Start Of Authoity) resource record를 declare해야 한다. SOA record는 zone과 그에 대응하는 name server를 declare한다.  SOA record를 통해 우리는 NS record를 찾을 수 있는데 이것은 해당 zone에 대한 책임이 있는 name server를 가리킨다. 이렇게 되면 하나의 FQDN에 대해 여러 physical server로 service할 수 있다. 

Reverse lookup zone files는 DNS resolver에 IP주소로 요청하면, FQDN을 응답할 수 있도록하는 파일이다. 이것은 Zone file과 동일한 파일형식이지만, PTR(Pointer Resource Record)를 declare한다. 특정 IP로 온 메일이 스팸인지 아닌지 체크하기 위해, 해당 IP로 DNS reverse lookup을 하고, PTR을 확인해 domain name이 맞다면 스팸이 아닌걸로 처리할 수 있다.