Domain Name System

본 글은 educative.io 의 Grokking Modern System Design Interview 코스의 Domain Name System 챕터 내용을 정리한 글입니다.

The origin of DNS

휴대전화는 고유의 전화번호가 각 사용자에게 연결되어있다. 친구에게 전화를 하려면 우리는 먼저 친구의 전화번호를 기억해야한다. 이렇게 기억해야할 연락처가 늘어나면서, 우리는 전화번호부를 관리하여 연락처들을 관리하고, 필요한 경우에 원하는 사람에게 전화를 할 수 있다.

비슷하게 컴퓨터들도 고유한 IP 주소로 서로를 구별할 수 있다. 특정 머신이 호스팅하는 웹사이트를 방문하기 위해 IP 주소를 사용한다. 하지만 사람들이 도메인 네임을 방문하기 위해 IP 주소를 일일이 기억하긴 어렵기 때문에 전화번호부와 비슷한 저장소를 두어 모든 도메인 네임과 IP 주소의 매핑을 관리하도록 할 수 있다. DNS 가 어떻게 인터넷상의 전화번호부 역할을 하는지 알아보자.

What is DNS?

DNS (domain name system) 은 인간 친화적인 도메인 이름을 기계판독이 가능한 (machine-readable) IP 주소로 연결해주는 인터넷의 네이밍 서비스이다.

사용자가 도메인네임을 브라우저에 입력하면, 브라우저는 DNS 인프라에 질의하여 도메인네임을 IP 주소로 번역해야한다. 이렇게 IP 주소를 확보하면, 사용자의 요청은 목적지 웹서버로 전달된다.

이러한 동작은 매우 빠르게 수행되고, 사용자는 최소한의 지연만을 경험하게 된다.

Important details

• Name servers
  • DNS 는 단일 서버가 아니라 여러 서버로 이루어진 완성된 인프라이다.
  • 사용자 질의에 응답하는 DNS 서버들을 네임서버 라고 한다
• Resource Records
  • DNS DB 는 resource records (RR) 의 형태를 통해 도메인 네임과 IP 주소의 매핑을 저장한다
  • RR 은 사용자가 네임서버로 요청하는 정보의 가장 작은 단위이다
  • RR 에는 다음과 같이 여러 타입이 있다.

Type Name Value Desc Example (Type, Name, Value)

Type	Name	Value	Desc	Example (Type, Name, Value)
A	Hostname	IP address	hostname → IP 주소 매핑	(A, relay.main.educative.io, 104.18.2.119)
NS	Domain name	Hostname	도메인 네임 → authoritative DNS 의 hostname	(NS, educative.io, dns.educative.io)
CNAME	Hostname	Canonical name	alias → canonical hostname 매핑	(CNAME, educative.io, server1.primary.educative.io)
MX	Hostname	Canonical name	mail server alias → canonical hostname	(MX, mail.educative.io, mailserver1.backup.educative.io)

• Caching
  • DNS 는 사용자의 요청 지연시간을 감소시키기 위해 서로 다른 레이어들에 캐시를 사용한다
  • DNS 인프라는 전체 인터넷의 질의들을 수용해야 하기 때문에 캐싱이 부하 감소에 중요한 역할을 한다
• Hierarchy
  • DNS 네임서버는 계층형식이다.
  • 계층구조는 계속 증가하는 크기와 쿼리 로드를 갖는 DNS 가 높은 확장성을 가질 수 있도록 해준다.

DNS hierarchy

전에도 기술했듯이, DNS 는 단일 서버가 아니라 여러 서버로 이루어진 완성된 인프라이다.

DNS 계층구조는 주로 4개 타입의 서버로 구성되어 있다.

1. DNS resolver
   1. querying sequence 를 시작하고 다른 DNS name server 로 요청을 전파한다
   2. 보편적으로 사용자 자체 네트워크 내에 존재
   3. 캐시를 이용해 DNS 쿼리를 빠르게 제공할 수도 있다
   4. local 또는 default 서버라고 불리기도 한다
2. Root-level nameservers
   1. local 서버들로부터 요청을 받는다
   2. .com, .edu, .us 와 같은 top-level 도메인 네임에 따라 네임서버들을 관리한다
   3. educative.io 의 IP 주소를 요청했다면, root level 네임서버는 .io 도메인의 IP 주소를 갖고있는 TLD (top-level domain) 서버들의 목록을 반환할 것이다
3. Top-level domain (TLD) name servers
   1. authoritative 네임서버의 IP 주소들을 갖는 서버들이다
   2. 쿼리를 통해 organization 의 authoritative 서버에 속하는 IP 주소들이 반환될 것이다
4. Authoritative name servers
   1. 질의 대상이 되는 웹서버나 맵 서버의 IP 주소를 제공하는 해당 조직의 DNS 네임서버이다

Question

: DNS 이름은 어떻게 처리될까? 예로, educative.io 는 왼쪽에서 오른쪽, 또는 오른쪽에서 왼쪽 중 어떤 방향으로 처리될까?

→ UNIX 파일들과는 다르게, DNS 이름들은 오른쪽에서 왼쪽으로 처리된다. resolver 는 .io 를 먼저, educative 를 다음 순서로 해결할 것이다.

Iterative versus recursive query resolution

DNS 쿼리의 두가지 방법

1. Iterative
   1. 로컬 서버가 root → TLD → authoritative 서버 순으로 요청을 보낸다
2. Recursive
   1. 유저가 local server 에 요청을 보내면 local server 가 root DNS 네임서버에 이어서 요청한다
   2. root 네임서버는 다른 네임서버로 요청을 전달한다

보통 iterative query 가 DNS 인프라의 로드를 줄일 수 있어서 더 선호된다

요새는 Google, Cloudflare 등이 서드파티 public DNS resolver 를 제공하며 이 DNS 서버들이 로컬 ISP DNS 설비보다 더 빠른 응답을 제공하기도 한다.

https://developers.google.com/speed/public-dns?hl=ko

Caching

캐싱은 자주 요청되는 자원 레코드들의 (resource records) 의 임시 저장소를 말한다. record 는 이름-값 바인딩을 나타내는 DNS DB 의 데이터 단위이다. 캐싱은 사용자의 응답시간과 네트워크 트래픽을 감소시킨다. 캐싱을 여러 레이어에 사용할 때, DNS 인프라의 많은 쿼리 부하를 줄일 수 있다. 캐싱은 브라우저, 운영체제, 사용자의 네트워크 내에 있는 로컬 네임 서버, 또는 ISP 의 DNS resolver 등에 구현될 수 있다.

DNS as a distributed system

• 분산시스템으로서의 장점
  • SPOF 가 되는 것을 방지한다
  • 사용자가 근처 서버에서 응답을 받게 하면서 쿼리 대기시간을 줄일 수 있다
  • 유지보수 및 업그레이드 중 높은 수준의 유연성을 제공한다
• A 부터 M 까지 이름붙은 13 개의 root name server 가 있고, 서버 인스턴스는 전세계에 분포되어있다. 이 서버들은 12개의 다른 조직에 의해 관리된다
• https://www.iana.org/domains/root/servers

Highly scalable

• 13개 루트 레벨 서버의 약 1,000개의 복제된 인스턴스가 사용자 쿼리를 처리하기 위해 전략적으로 전 세계에 분산되어 있다
• 쿼리를 처리하기 위한 작업량은 TLD 와 root server, organization 에 의해 자체적으로 관리되는 authoritative 서버로 분산되어 처리된다.
• DNS 계층구조에서 본 것 처럼, 서로 다른 서비스는 계층의 서로 다른 부분들을 처리하여 시스템이 확장성과 관리성을 갖게 한다

Reliable

DNS 를 신뢰성 있는 시스템으로 만드는 세가지 요소가 있다

• caching
  • 여러 레이어에서 작동하는 캐싱은 자주 방문되는 서비스들의 풍부한 캐시를 유지한다.
  • DNS 서버가 잠시 다운되어도 캐시된 레코드들이 서빙될 수 있어 DNS 시스템을 신뢰성 있게 만든다
• server replication
  • DNS 는 사용자 요청을 낮은 지연으로 처리하기 위해 전세계에 퍼져있는 논리 서버들을 복제했다.
  • 중복되는 서버들은 전체 시스템의 신뢰성을 향상시킨다.
• protocol
  • 많은 클라이언트들이 DNS 를 신뢰성 없는 UDP (user datagram protocol) 으로 사용하지만, UDP 도 장점이 있다.
  • UDP 는 빠르기 때문에 DNS 의 성능을 향상시킨다.
  • 또한 인터넷 서비스의 신뢰성이 초기보다 발전되었기 때문에 보통 TCP 보다는 UDP 가 선호된다.
  • DNS resolver 는 이전 요청의 답을 받지 못한 경우 UDP 요청을 다시 보낼 수 있다.
  • 이러한 요청-응답이 왕복 1회만에 가능하므로 데이터 교환 전에 3방향 핸드셰이크가 필요한 TCP 보다 더 짧은 지연을 제공한다.

Question

: 네트워크가 혼잡할 경우는 DNS 가 UDP 를 계속 사용해야 할까?

→ 보통은 UDP 를 사용하지만 메시지 크기가 원래 패킷 사이즈인 512B 를 초과하면 TCP 를 사용할 수도 있다. 큰 크기의 패킷은 혼잡한 네트워크에 더 취약하기 때문이다. DNS 는 영역 전송 (zone transfer) 시에는 항상 TCP 를 사용한다. 또한 일부 클라이언트는 개인정보 보호를 위해 전송계층 보안을 사용하려고 TCP 를 사용하기도 한다.

Consistent

DNS 는 다양한 프로토콜을 이용하여 계층구조의 복제 서버간에 정보를 업데이트하고 전송한다. DNS 는 쓰기보다 읽기가 자주 발생해서 고성능을 얻기 위해 강한 일관성에 타협했다. 하지만 DNS 는 궁극적인 일관성을 제공하고 복제된 서버에 레코드를 느리게 업데이트 한다. 보통 인터넷상의 DNS 서버들에 레코드를 업데이트 하는데 수초에서 최대 3일까지 걸릴 수 있다. 서로 다른 DNS 클러스터간에 정보를 전파하는데 걸리는 시간은 DNS 인프라, 업데이트 크기, 그리고 DNS 트리의 어떤 부분이 업데이트 되는지에 따라 달라진다.

캐싱으로 인해 일관성이 저하될 수도 있다. authoritative 서버들은 조직 내에 위치하기 때문에 조직에서 서버 장에가 발생할 경우 특정 resource record 들이 업데이트 될 수 있다. 이런 경우 default/local 그리고 ISP 서버들의 캐시된 레코드가 만료될 수 있다. 이 문제를 완화하기 위해 각 캐시된 레코드는 time-to-live (TTL) 이라는 만료 시간을 가진다.

Question

: 고가용성을 위해서는 TTL 값이 작아야 할까? 커야할까?

→ 고가용성을 위해서는 TTL 값이 작아야한다. 서버 또는 클러스터에 장애가 발생할 경우, 조직이 resource record 를 바로 업데이트 할 수 있기 때문이다. 사용자는 TTL 이 만료되지 않은 시간동안만 사용하지 못할 것이다. 그러나 TTL 값이 크면 조직은 resource record 를 업데이트 하겠지만 사용자는 오래 전에 죽었을 수도 있는 예전 서버에 핑을 날리고 있을 수 있다. 고가용성을 원하는 회사들은 TTL 값을 120초로 낮게 유지하여 장애시에도 최대 다운타임을 수 분으로 유지한다.

Test it out

• nslookup
  • Non-authoritative answer 는 Google 의 authoritative 서버가 아닌 서버로부터 제공된 답이다.
  • 이 응답은 쿼리에 응답하도록 설정된 두번째, 세번째, 네번째… 네임서버들이 제공한 답이다
    • 예를들어 오피스의 DNS resolver, ISP 네임서버, ISP 의 ISP 네임서버 등등..
  • 간단히 말해서 구글의 authoritative name server 응답의 캐시된 버전이라고 할 수 있다.
  • 여러 도메인 이름을 시도하면 대부분 캐시된 응답을 받을 수 있다.
  • 같은 커맨드를 여러번 실행하면 같은 IP 주소들이 다른 순서로 나열된 응답을 받을 수도 있다. 이유는 DNS 가 간접적으로 로드밸런싱을 수행하기 때문이다.

$ nslookup www.google.com
Server:		168.126.63.1
Address:	168.126.63.1#53

Non-authoritative answer:
Name:	www.google.com
Address: 142.250.76.132

 

• dig
  • Query time 은 DNS 서버로부터 응답을 받는 데 걸린 시간이다
  • ANSWER SECTION 의 161 이라는 값은 몇초동안 캐시 엔트리가 유지될 것인지 나타낸다

$ dig www.google.com

; <<>> DiG 9.10.6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30848
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		161	IN	A	142.250.206.228

;; Query time: 23 msec
;; SERVER: 168.126.63.1#53(168.126.63.1)
;; WHEN: Sun Mar 19 18:56:50 KST 2023
;; MSG SIZE  rcvd: 59

 

Question

: 웹사이트에 연결할 IP 를 알려주는 DNS 가 필요한 경우, DNS resolver 의 IP 주소를 어떻게 알 수 있을까?

→ 사용자의 운영체제에는 DNS resolver 의 IP 가 들어있는 설정 파일 (/etc/resolv.conf 등) 이 있다.