새 도메인에 A 레코드를 추가했는데, 내 컴퓨터에서는 접속이 되지만 다른 사람 컴퓨터에서는 "서버를 찾을 수 없다"는 오류가 납니다. DNS 전파 지연 문제인데, 어디서 지연이 생기는지, 얼마나 기다려야 하는지 알 수가 없습니다. DNS가 계층 구조로 동작하는 원리를 모르면 레코드를 바꿀 때마다 이 불확실성을 그냥 감수해야 합니다.

확대

DNS는 왜 계층 구조인가

전 세계 수십억 개의 도메인 정보를 한 서버에 저장하는 것은 불가능합니다. DNS는 이 문제를 계층적 위임(Hierarchical Delegation) 구조로 해결합니다.

                    [. (Root)]
                   /    |    \
             [.com]  [.org]  [.kr]   ← TLD (Top-Level Domain)
               /
        [example.com]               ← Authoritative NS
           /     \
       [www]    [mail]              ← 실제 호스트 레코드

• Root NS: 전 세계 13개(실제로는 anycast로 수백 개) 서버. TLD를 어디서 관리하는지 알고 있음
• TLD NS: .com, .kr, .org 등 최상위 도메인 관리. Authoritative NS 위치를 알고 있음
• Authoritative NS: 특정 도메인(example.com)의 실제 레코드를 보유하는 서버

재귀 질의 과정 (www.example.com 조회 시)

브라우저에서 www.example.com을 입력하는 순간, 화면 뒤에서는 다음과 같은 대화가 진행됩니다. 당신의 컴퓨터는 답을 모르니 ISP가 제공하는 로컬 DNS 리졸버에게 물어봅니다. 리졸버도 캐시에 없으면 Root NS부터 차례로 위임 정보를 따라가며 최종 답을 찾아옵니다. 이 모든 과정이 보통 수십 밀리초 안에 완료됩니다.

확대

Recursive vs Iterative 질의

DNS 질의 방식에는 두 종류가 있습니다. "끝까지 답을 찾아와 주는" 재귀 방식과, "저기 가서 물어봐"라며 다음 단계만 알려주는 반복 방식입니다. 실제 DNS 통신에서 이 두 방식이 역할을 나눠 사용됩니다.

클라이언트는 Local Resolver에게 재귀 질의를 합니다. Local Resolver가 실제로 Root → TLD → Authoritative를 순차적으로(Iterative) 방문하여 답을 가져옵니다.

DNS 캐싱과 TTL

응답받은 레코드는 TTL(Time To Live) 동안 캐시에 저장됩니다. 캐시된 동안은 동일 질의에 대해 전체 계층 탐색 없이 즉시 응답합니다.

www.example.com A 93.184.216.34 TTL 3600
                               ↑
                         3600초(1시간) 동안 캐시 유지

DNS 전파 지연의 원인: 도메인 IP를 변경해도 이전 TTL 동안은 구 IP가 캐시에 남아 있습니다. TTL을 300(5분)으로 낮춘 후 변경하면 더 빠르게 전파됩니다.

앞에서 리졸버가 위임 체인을 밟는 원리를 봤다면, 이번엔 curl https://www.example.com 한 줄이 IP를 얻기까지 내 컴퓨터 안쪽에서 무슨 일이 먼저 일어나는지부터 끝까지 따라갑니다. 실제로 이름 해석은 리졸버로 나가기 전에 /etc/hosts·/etc/nsswitch.conf·/etc/resolv.conf라는 로컬 관문을 먼저 지납니다. 이 관문을 모르면 "dig는 되는데 앱은 안 되는" 증상 앞에서 원인을 못 찾습니다. 아래 8단계를 알면 어디서 막혔는지 한 단계로 좁힐 수 있습니다.

[앱]  curl https://www.example.com
   │
   ① getaddrinfo("www.example.com") 호출        (앱은 libc 리졸버에 이름 해석을 맡김)
   │
   ② /etc/nsswitch.conf의 hosts: 순서 결정        (hosts: files dns → files 먼저)
   │
   ③ /etc/hosts 확인 (files 조회원)               (매치되면 즉시 반환, DNS로 안 감)
   │    미스 ↓
   ④ stub resolver가 /etc/resolv.conf의 nameserver로 재귀 질의 (RD=1)
   │
   ⑤ 리커시브 리졸버 캐시 확인                     (히트면 즉답 — 두 번째 조회가 빠른 이유)
   │    미스 ↓ (리졸버가 반복 질의로 위임 체인을 대신 밟음)
   ⑥ Root(.) NS  → ".com은 이 TLD 서버들"          (NS 리퍼럴)
   │
   ⑦ .com TLD NS → "example.com은 이 권한 NS"      (NS 리퍼럴)
   │
   ⑧ example.com 권한 NS → A 레코드 권위 응답       (authoritative answer)
   ▼
[리졸버]  A 93.184.216.34 를 앱에 반환 + TTL 동안 캐시 (다음 조회는 ⑤에서 즉답)

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 "이름 해석 성공"은 세 관문을 모두 통과했다는 뜻입니다 — 로컬 경로(②③④)에서 DNS까지 갔고, 리졸버(⑤)가 위임 체인(⑥⑦)을 밟아, 권한 NS(⑧)가 권위 응답을 냈습니다. 안 될 때는 이 셋을 각각 다른 도구로 좁힙니다: getent hosts www.example.com은 ①②③(nsswitch·hosts 로컬 경로)을, dig @8.8.8.8과 로컬 dig 비교는 ④⑤(내 리졸버 vs 전체)를, dig +trace는 ⑥⑦⑧(위임 체인)을 검사합니다. 이름→IP를 찾는 것이 정방향(A/AAAA), IP→이름을 찾는 것이 **역방향(PTR, in-addr.arpa)**으로 방향만 반대일 뿐 같은 계층을 탑니다. 그리고 "레코드를 만들었는데 안 보임"은 레코드 자기 TTL이 아니라 **SOA minimum(부정 캐시 TTL)**이 지배한다는 점을 기억하면 ⑧에서 헤매지 않습니다.

새 서비스를 서브도메인으로 분리하려는데 도메인 관리 패널에 A, CNAME, MX, TXT가 가득합니다. CNAME으로 연결하면 되는 상황인지, A 레코드를 직접 추가해야 하는지, CNAME을 루트 도메인에 쓰면 왜 안 되는지 헷갈립니다. 각 레코드 타입의 용도와 제약을 모르면 도메인 설정 한 번에 삽질을 반복하게 됩니다.

확대

핵심 레코드 타입

DNS 레코드는 타입마다 역할이 다릅니다. 웹 서버 주소를 가리키는 A 레코드부터, 이메일 서버를 지정하는 MX, 도메인 소유권 인증에 쓰는 TXT까지 — 각 타입이 어떤 목적에 쓰이는지 알면 도메인 설정 화면이 더 이상 낯설지 않습니다.

A 레코드 — 도메인 → IPv4

example.com.     3600  IN  A  93.184.216.34
www.example.com. 3600  IN  A  93.184.216.34

가장 기본적인 레코드입니다. 하나의 도메인에 여러 A 레코드를 등록하면 라운드 로빈 DNS 로드밸런싱이 됩니다.

AAAA 레코드 — 도메인 → IPv6

example.com.  3600  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

CNAME 레코드 — 도메인 별칭

www.example.com.   3600  IN  CNAME  example.com.
blog.example.com.  3600  IN  CNAME  example.com.

www.example.com을 조회하면 → example.com을 다시 조회 → A 레코드로 IP를 반환합니다.

주의: CNAME은 다른 레코드와 공존할 수 없습니다. 루트 도메인(example.com)에는 CNAME을 사용할 수 없고 A 레코드나 ALIAS 레코드를 사용해야 합니다.

MX 레코드 — 메일 서버

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

숫자(Priority)가 낮을수록 우선순위가 높습니다. mail1이 응답 없을 때 mail2로 폴백됩니다.

TXT 레코드 — 텍스트 정보

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  IN  TXT  "google-site-verification=abc123xyz"

주요 용도:

• SPF: 이메일 발송 서버 인증 (스팸 방지)
• DKIM: 이메일 서명 키 공개
• 도메인 소유권 인증: Google Search Console, AWS ACM 인증서 등

NS 레코드 — Authoritative Name Server

example.com.  IN  NS  ns1.example.com.
example.com.  IN  NS  ns2.example.com.

해당 도메인의 Authoritative NS를 지정합니다. 도메인 등록사에서 설정합니다.

SOA 레코드 — Zone의 시작 (Start of Authority)

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
    2024010101  ; Serial
    3600        ; Refresh
    900         ; Retry
    604800      ; Expire
    300         ; Minimum TTL
)

Zone 파일의 첫 번째 레코드로, 해당 도메인의 주 네임서버, 관리자 이메일, Zone 업데이트 정보를 담습니다.

레코드 타입 비교표

자주 마주치는 레코드 타입을 한 표로 정리하면 DNS 설정 화면에서 어떤 타입을 선택해야 할지 빠르게 판단할 수 있습니다.

레코드의 TTL(양성 캐싱)은 이제 이해했더라도, '레코드를 만들었는데도 안 보이거나' '특정 도메인만 간헐 실패하는' 증상은 전혀 다른 원리에서 나옵니다. 둘 다 dig 한 번은 성공하기에 넘어가기 쉽습니다.

• 부정 캐싱(negative caching): 리졸버는 '있다'는 답만이 아니라 '없다(NXDOMAIN)'는 답도 캐시합니다. 그 유지 시간은 새로 만든 레코드의 TTL이 아니라, 그 존(zone)이 함께 돌려주는 SOA 레코드의 minimum(negative TTL) 이 지배합니다. 그래서 SOA minimum이 3600이면, 이름이 없던 시절 NXDOMAIN을 받은 리졸버는 레코드를 만든 뒤에도 최대 1시간 '없음'을 계속 답합니다. '레코드를 만들기 전에 미리 조회해 보는' 습관이 이 함정을 스스로 심는 흔한 방법입니다.
• UDP 512바이트와 TCP 폴백: DNS 질의는 기본이 UDP 53입니다. 전통적으로 응답이 512바이트를 넘으면 서버가 TC(truncated) 비트를 세우고, 클라이언트는 같은 질의를 TCP 53으로 다시 던집니다. EDNS0로 더 큰 UDP 응답을 협상하지만(4096 등), 그 큰 UDP 데이터그램은 경로 MTU를 넘겨 IP 조각화(fragment)될 수 있습니다.
• 그래서 '레코드가 많은 도메인만' 실패한다: 방화벽이 UDP 53만 열고 TCP 53이나 큰 UDP 조각을 막으면, TXT·DNSSEC가 많아 응답이 큰 도메인만 폴백에 실패해 간헐 장애가 납니다. 짧은 응답 도메인은 폴백이 필요 없어 늘 정상이라 원인을 놓치기 쉽습니다.
• 진단의 관점 전환: '레코드가 맞는데 왜 클라이언트가 못 받나'를 볼 때는, 레코드 자기 TTL만 보지 말고 SOA minimum(부정 캐싱)과 응답 크기·TC 비트(UDP/TCP)를 함께 봅니다. dig +tcp, dig +bufsize=512, SOA의 마지막 필드가 이때 쓰는 도구입니다.

즉 DNS는 '이름→IP 표'가 아니라 캐시·프로토콜 한계를 가진 시스템이고, 조용한 실패는 대개 이 두 지점에서 납니다.