DNS 해석 전체 과정 — 브라우저에서 루트 서버까지 몇 단계를 거칩니까?

1. 전체 8단계 흐름도

┌─────────────────────────────────────────────────────────────┐
│  브라우저 (Chrome / Firefox)에 google.com 입력              │
└────────────────┬────────────────────────────────────────────┘
                 │ ① 브라우저 DNS 캐시 (Chrome 약 60초)
                 ↓ 미스
┌─────────────────────────────────────────────────────────────┐
│  OS 스텁 리졸버 + 시스템 DNS 캐시                           │
└────────────────┬────────────────────────────────────────────┘
                 │ ② 시스템 캐시 미스 → 공유기로 UDP 쿼리 전송
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  가정용 공유기 DNS 포워딩 + 공유기 캐시                     │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ 공유기 캐시 미스 → ISP 재귀 리졸버로 전달
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ISP / 공용 재귀 리졸버 (1.1.1.1 / 8.8.8.8 / 223.5.5.5)     │
│  캐시 적중: 바로 반환, 전체 과정 1-5ms                      │
│  캐시 미스: 아래의 "전체 조회" 흐름으로 진행                │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ 루트 NS에 "google.com은 어디에 있습니까?" 질의
                 ↓
        루트 네임서버 13개 클러스터 (a~m.root-servers.net)
                 │ ⑤ 응답: "모릅니다. .com의 NS에 물어보세요: a.gtld-servers.net"
                 ↓
        .com TLD 권한 있는 서버 (Verisign)
                 │ ⑥ 응답: "저도 전부는 모릅니다. google.com의 NS에 물어보세요: ns1.google.com"
                 ↓
        google.com 권한 있는 서버 (Google이 직접 운영)
                 │ ⑦ 응답: "google.com의 A 레코드 = 142.250.x.x"
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ 재귀 리졸버가 답을 (TTL에 따라) 캐시하고                 │
│     클라이언트에 반환, 경로상의 각 계층도                   │
│     각자 사본을 캐시                                        │
└─────────────────────────────────────────────────────────────┘

핵심: 실제 환경에서는 8단계 전체를 거치는 경우가 거의 없습니다. 주요 사이트의 IP 주소는 거의 항상 재귀 리졸버의 캐시에 있으므로 일반 사용자는 ④단계까지만 가고 응답을 받습니다. 잘 알려지지 않은 도메인, 오랫동안 방문하지 않은 사이트, TTL이 만료된 경우, 새로 등록한 도메인일 때만 전체 흐름이 실행됩니다.

2. DNS 캐시 5개 계층 상세 해설

DNS는 1983년 설계 당시부터 한 가지 사실을 고려했습니다: 조회가 변경보다 10만 배 많다는 것입니다. 그래서 곳곳에 캐시가 있으며, 각 계층은 TTL(Time To Live) 동안 데이터를 보관합니다.

3. 재귀 질의 vs 반복 질의 — 핵심 개념

3.1 재귀 질의 (Recursive)

클라이언트(브라우저 / OS 스텁)는 ISP의 재귀 리졸버에게 “google.com의 IP를 찾아 주세요. 과정은 상관없습니다.”라고 요청합니다. 재귀 리졸버는 전체 조회를 끝까지 수행해 최종 결과를 반환해야 합니다.

3.2 반복 질의 (Iterative)

재귀 리졸버가 루트, TLD, 권한 있는 서버와 주고받는 과정은 반복 질의입니다 — 루트에 물으면 루트가 “.com에 물어보세요”라고 답하고, .com에 물으면 .com이 “google에 물어보세요”라고 답하고, 다시 google에 묻는 식입니다. 각 단계는 한 계층만 건너가며, “루트에 물으면 루트가 모든 것을 대신 처리해 주는” 방식이 아닙니다.

4. 직접 테스트하기 — dig +trace

dig +trace는 전체 반복 조회를 강제로 수행하고 모든 단계를 보여 줍니다:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① 1번째 홉 — 루트(.)에 질의
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (루트 NS 레코드 13개)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② 2번째 홉 — .io TLD에 질의
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (.io의 NS 4개)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ 3번째 홉 — cleanip.io의 권한 있는 서버에 질의
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ 마침내 응답 수신
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

결과 해석:

• 전체 과정에 5 + 121 + 53 + 12 = 191 ms가 걸렸습니다 — 처음 하는 콜드 조회는 확실히 느립니다
• 하지만 1초 뒤 같은 도메인을 다시 조회하면 1-2 ms밖에 걸리지 않습니다. ISP의 재귀 캐시에 이미 저장되어 있기 때문입니다 (TTL 300초)
• 104.21.x.x / 172.67.x.x는 Cloudflare CDN 주소입니다 — 이 사이트의 실제 오리진 IP는 CDN 뒤에 숨겨져 있습니다

5. TTL 상세 해설 — 캐시가 실제로 유지되는 시간

TTL(Time To Live)은 권한 있는 서버가 모든 재귀 리졸버에게 “최대 이 시간 동안만 캐시할 수 있다”고 알려 주는 필드이며, 단위는 초입니다.

참고: TTL은 “최대 캐시 시간”입니다 — 각 리졸버는 캐시를 더 일찍 지울 수는 있어도 늘릴 수는 없습니다. 따라서 권한 있는 서버의 TTL이 1시간이어도 일부 리졸버는 10분 만에 다시 조회할 수 있습니다.

함정: IP를 바꾸기 전에 먼저 TTL을 짧게(1-5분) 줄이고, 이전 TTL이 완전히 만료된 뒤에 전환하세요. 그러지 않으면 일부 사용자가 1시간 넘게 이전 IP로 계속 접속하게 됩니다.

6. DNS 레코드 유형 한눈에 보기

7. DNS 최적화 — 해석 속도를 높이는 방법

7.1 가까운 재귀 리졸버 선택

중국 본토: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod)가 중국 국내 사이트를 가장 빠르게 해석합니다. 그 외 지역: 1.1.1.1 (Cloudflare, 애니캐스트 커버리지가 가장 넓음) / 8.8.8.8 (Google). 자세한 내용은 다음을 참고하세요:공용 DNS 리졸버 목록.

7.2 DoH(DNS-over-HTTPS) 활성화

DNS 쿼리를 HTTPS로 암호화하면 ISP가 쿼리를 보거나 변조할 수 없습니다 (NXDOMAIN 하이재킹 차단). Chrome, Firefox, Edge 모두 지원하며 설정에서 켜기만 하면 됩니다.

7.3 미리 예열하기 (DNS Prefetch)

사이트의 <head>에 <link rel="dns-prefetch" href="//api.example.com">를 추가하면 브라우저가 유휴 시간에 미리 해석해 두므로, 실제 요청 시점에는 캐시 적중이 됩니다.

7.4 CDN + 애니캐스트 NS 사용

권한 있는 NS를 애니캐스트(Cloudflare / Route 53)에 두면 전 세계 사용자가 가장 가까운 인스턴스에 접속하므로 ③단계의 지연 시간이 100ms에서 10ms로 줄어듭니다.

7.5 TTL을 합리적으로 설정

거의 바뀌지 않는 레코드(NS / MX)는 TTL을 길게(1-7일), 전환이 필요할 수 있는 A 레코드는 짧게(5-60분) 설정하세요.

8. 자주 묻는 질문

8.1 DNS를 변경했는데 반영되지 않는 이유는 무엇입니까?

먼저 현재 TTL을 확인하세요. DNS를 변경해도 이전 TTL이 만료되기 전까지 모든 재귀 리졸버는 이전 IP를 계속 반환합니다. ‘전 세계 반영’에는 보통 TTL의 약 2배 시간이 걸립니다 (리졸버마다 동기화 시점이 다르기 때문).

• 클라이언트: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• 공용 재귀 리졸버의 캐시 만료 기다리기: 1.1.1.1 / 8.8.8.8은 캐시를 수동으로 비울 수 있는 자체 "purge" 도구를 각각 제공합니다

8.2 일부 사용자는 접속되고 일부는 안 될 때 — DNS 오염

중국 본토에서 해외 사이트에 접속할 때 흔히 발생합니다 — GFW가 가짜 DNS 응답을 주입하거나 ISP가 쿼리를 하이재킹합니다. DoH(브라우저 암호화 DNS)로 바꾸면 대부분의 DNS 오염을 우회할 수 있습니다.

8.3 도메인을 등록한 뒤 언제부터 사용할 수 있습니까?

등록이 끝나면 TLD 레지스트리가 도메인의 NS 레코드를 .com / .net 등의 최상위 권한 있는 서버에 반영하며, 보통 15분에서 24시간이 걸립니다. .cn / .com.cn 도메인은 중국 본토에서 해석되려면 ICP 등록이 필요할 수 있습니다.