DNS 해석, 처음부터 끝까지

매번 브라우저에 도메인을 입력할 때마다, 당신이 원하는 사이트로 가는 패킷 하나가 도착하기 전에 연속된 조회들이 실행된다. 그 연속의 대부분은 눈에 보이지 않고, 대부분의 설명들은 "마치 전화번호부 같은 것"에서 멈춘다. 여기서는 정확히 무슨 일이 일어나는지, 사람들이 보통 건너뛰는 부분을 포함해 단계별로 설명한다.

stub resolver는 똑똑하지 않다

당신의 운영 체제는 자체적으로 실제 DNS 해석을 하지 않는다. 대신 stub resolver를 실행하는데, 이것은 단지 당신의 쿼리를 /etc/resolv.conf에 설정된 DNS 서버(Linux)나 네트워크 어댑터 설정(Windows)으로 전달하기만 하는 얇은 코드 조각이다. 다음으로 확인할 수 있다:

cat /etc/resolv.conf

그 파일은 보통 당신의 라우터(예: 192.168.1.1), ISP의 resolver, 또는 1.1.1.1이나 8.8.8.8 같은 공개 resolver를 가리킨다. stub resolver는 OS나 systemd-resolved 같은 로컬 daemon이 제공하는 것 이상의 캐시 로직을 갖지 않는다.

recursive resolver가 실제 작업을 한다

당신의 쿼리가 recursive resolver에 도달하면, 그 서버는 여러 다른 서버에 물어봐야 하더라도 답을 찾는 작업을 맡는다. 이전 조회에서 이미 캐시된 답이 있으면 즉시 반환된다. TTL은 다음으로 확인할 수 있다:

dig example.com

ANSWER SECTION을 보자 — 레코드 타입 앞의 숫자(예를 들어 A 앞의 300)는 초 단위의 TTL이다. 이것이 resolver가 다시 물어보기 전에 레코드를 캐시할 수 있는 기간이다.

아무것도 캐시되지 않았으면, recursive resolver는 DNS 계층의 루트에서부터 내려가는 과정을 시작한다.

Root, TLD, 그리고 권한 있는 서버

13개의 루트 서버 주소가 있다(a.root-servers.net부터 m.root-servers.net까지). 각각은 anycast 라우팅을 통해 많은 물리적 머신으로 지원된다. 루트 서버는 example.com이 어디 있는지 모르지만, .com을 처리하는 서버들을 알고 있으므로 그 referral을 반환한다.

resolver는 그 다음 .com TLD 서버에 묻는다. 이 서버도 최종 답을 모르지만 example.com에 대해 권한이 있는 nameserver들을 알고 있다. 이 delegation을 직접 볼 수 있다:

dig +trace example.com

이 명령어는 모든 홉을 보여준다: root, TLD, 도메인에 대한 권한 있는 nameserver들, 그리고 실제 A나 AAAA 레코드로 끝난다. 이것이 DNS를 이론적으로가 아니라 시각적으로 이해하기 위한 최고의 명령어다.

권한 있는 nameserver는 마지막 정거장이다. 이것은 도메인 소유자가 실제로 설정한 서버로, 보통 registrar의 DNS 패널이나 Route 53이나 Cloudflare DNS 같은 서비스를 통한다. 이것이 전체 체인에서 캐시된 사본이나 referral이 아닌 실제의 정규 답을 갖는 유일한 서버다.

실제로 마주치는 레코드 타입들

A 레코드는 이름을 IPv4 주소에 매핑하고, AAAA는 IPv6에 대해 동일하게 한다. CNAME은 한 이름을 IP가 아닌 다른 이름으로 가리키는데, 이것이 Cloudflare나 Fastly 같은 CDN이 raw IP를 노출하지 않고 트래픽을 라우팅하는 방식이다. MX 레코드는 메일 라우팅을 처리하고, TXT 레코드는 임의의 텍스트를 전달한다. 가장 일반적으로 SPF, DKIM, 도메인 verification 문자열에 쓰인다. NS 레코드는 어떤 서버들이 zone에 대해 권한이 있는지 세상에 알려주며, 이 레코드 타입이 처음부터 delegation을 가능하게 하는 것이다.

캐싱이 실제로 어디에 있는가

캐싱은 여러 층에서 동시에 일어난다: 브라우저 자신(chrome://net-internals/#dns에서 볼 수 있는 Chrome의 DNS 캐시), OS resolver 캐시, 로컬 라우터, 그리고 upstream의 recursive resolver. 이것이 DNS 변경이 한 기기에서는 즉시 작동하는 것으로 보이고 다른 기기에서는 몇 시간이 걸리는 이유다 — 당신이 같은 캐시를 치고 있지 않기 때문이다.

계획된 마이그레이션 전에 레코드의 TTL을 낮출 때, 당신은 즉시 뭔가를 빨리하고 있지 않다. 당신은 단지 변경이 실제로 일어난 후 stale 데이터가 지속될 수 있는 윈도우를 줄이고 있을 뿐이다. 이것을 cutover 5분 전이 아니라 최소 한 TTL 사이클 전에 하자.

이것이 troubleshooting에 중요한 이유

사이트에 도달할 수 없을 때, dig +trace는 정확히 어느 층이 broken 되었는지 알려준다: root/TLD 문제는 misconfigured 권한 있는 서버나 당신 자신의 머신의 stale 캐시와는 완전히 다르게 보인다. dig example.com을 dig example.com @1.1.1.1 같은 알려진 좋은 resolver와 비교하면, 문제가 당신의 로컬 resolver인지 도메인의 실제 DNS 설정인지를 분리할 수 있다.

DNS는 보통 100ms 이하로 해석되고 아무도 생각하지 않기 때문에 외부에서는 단순해 보인다. 내부적으로는 distributed, cached, hierarchical query 시스템이며, 1980년대 이후로 구조상 거의 변하지 않고 실행되어 왔다. 이것은 원래 설계가 얼마나 잘 견디었는지에 대한 꽤 좋은 논거다.

더 나아가고 싶다면, Korra Studio는 DEFENSE_GRID에서 DNS 보안 확장, exfiltration 기법으로서의 DNS 터널링, Python에서 당신 자신의 resolver를 처음부터 구축하기에 관련된 세그먼트를 가지고 있다.