전 세계 루트 네임서버는 왜 13개 그룹뿐입니까?

1. 프로토콜의 엄격한 제약: 512바이트

1.1 IPv4 MTU와 단편화되지 않은 UDP

초기 ARPANET / IPv4 네트워크는 최소 MTU를 576바이트로 규정했습니다. 모든 호스트는 이 크기의 패킷을 받을 수 있어야 하며, 그렇지 않으면 가장 기본적인 도달성조차 보장할 수 없습니다(RFC 791).

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• 전체 길이 576바이트 − 일반적인 IP 헤더 20바이트 − UDP 헤더 8바이트 ≈ 548바이트 사용 가능 (IP 옵션이 붙으면 헤더가 최대 60바이트까지 커져 여유가 더 줄어듭니다)
• RFC 1035 § 4.2.1은 더 보수적인 2의 거듭제곱인 512바이트를 DNS over UDP의 엄격한 상한으로 정했습니다 — IP 헤더에 옵션이 가득 붙어도 안전한 크기입니다
• UDP 응답이 512바이트를 넘으면 잘라 내고 TC 플래그를 설정해 클라이언트가 TCP로 폴백하게 해야 합니다 — 그런데 TCP 3방향 핸드셰이크 때문에 첫 해석의 지연 시간이 몇 배로 늘어납니다

다시 말해 “전체 루트 서버 목록이 512바이트 UDP 패킷 하나에 들어가야 한다”는 뜻입니다. 그렇지 않으면 전 세계의 모든 루트 질의가 TCP를 거쳐야 했을 텐데, 1980년대 하드웨어에서는 재앙에 가까운 일이었을 것입니다.

1.2 DNS 메시지의 바이트 구조

.의 NS 레코드를 조회했을 때의 전체 응답 구조입니다(서버는 모든 루트 NS 레코드와 글루 A 레코드를 함께 반환합니다):

Header   (12바이트)

전체 길이 공식:

512바이트 제한을 대입하면:

이론상으로는 최대 15개 그룹까지 가능하지만, DNSSEC 서명, EDNS0 OPT 의사 레코드, 필드 패딩을 위한 여유 공간이 필요해 13개 그룹으로 정해졌습니다 — RFC 2010(1996년)이 루트 서버의 운영 기준을 제시했고, 이듬해 M-root가 가동된 뒤로 개수는 바뀌지 않았습니다.

1.3 직접 확인하기 — <code>dig +noedns -t ns .</code> 응답은 약 490–510바이트

여기까지가 이론입니다. 이제 dig로 루트 서버에 실제로 질의해 응답 크기가 얼마나 되는지 확인해 보겠습니다:

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (NS 레코드 총 13개, c–l 생략)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (A 글루 레코드 13개가 모두 들어감)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ AAAA 레코드는 2개만 들어감 — 패킷이 가득 참

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

핵심은 마지막 줄입니다 — 전체 응답 크기는 약 490–510바이트로 512보다 여유 있게 작습니다(정확한 값은 어느 루트에 질의하는지, IPv6 글루 레코드가 몇 개 돌아오는지에 따라 다릅니다). 이는 앞의 바이트 계산과 일치합니다. +noedns 플래그에 주의하세요: dig는 기본적으로 EDNS0 옵션을 함께 보내며, 그러면 응답이 800바이트를 훨씬 넘습니다. 바로 이 때문에 EDNS0 지원이 보편화된 뒤로 512바이트는 더 이상 엄격한 제한이 아니게 되었습니다 — 하지만 그때는 이미 13이라는 숫자가 굳어진 뒤였습니다.

2. 13은 어디서 나왔습니까? 간략한 역사

이 숫자는 처음부터 정해진 것이 아닙니다. 루트 서버 수는 여러 차례 늘어났으며, 1997년 M-root(일본 WIDE)가 가동된 뒤로는 다시 바뀌지 않았습니다:

13개로 고정된 뒤 A부터 M까지의 문자 이름은 절대 바뀌지 않습니다 — 하드웨어를 업그레이드하고 애니캐스트 미러를 늘릴 뿐입니다. 인터넷의 루트 힌트 파일(named.root)은 이미 수십억 개의 재귀 리졸버와 스텁 클라이언트 코드에 내장되어 있어, 숫자 하나를 바꾸려면 인터넷 전체를 업그레이드해야 합니다.

3. 그렇다면 전 세계에 정말 서버가 13대뿐입니까?

아닙니다. 가장 흔한 오해입니다. ‘루트 서버 13개 그룹’은 13개의 NS 이름(a–m.root-servers.net)을 뜻하며, 각 이름은 IPv4 주소 1개와 IPv6 주소 1개에 대응합니다 — 물리 서버 13대를 뜻하는 것이 아닙니다.

각 IP 뒤에는 애니캐스트 클러스터가 있습니다 — 같은 IP 주소를 전 세계 수백 곳의 데이터센터가 BGP로 동시에 광고하며, 사용자의 DNS 질의는 RTT 기준으로 가장 가까운 미러로 라우팅됩니다. 루트 서버가 ‘다운됐다’는 것은 보통 특정 도시의 미러 하나가 점검 중이라는 뜻일 뿐, 전 세계 해석에는 영향이 없습니다.

2024년 루트 서버 13개 그룹 현황

중국 본토(베이징, 상하이, 선전, 광저우, 허페이 등)에는 F / I / J / K / L 등 여러 루트 서버의 애니캐스트 미러 노드가 있으며, 중국 내에서 루트 서버까지 측정한 RTT는 보통 20ms 미만입니다.

4. EDNS0 이후 512바이트는 실질적인 제한이 아니게 됨

이런 의문이 들 수 있습니다: 요즘은 4KB 이상의 DNS 패킷도 흔한데, 왜 그냥 ‘13개 제한’을 넘어서지 않습니까?

• EDNS0 (1999년 RFC 2671, 현행 RFC 6891) — 더 큰 UDP 페이로드(일반적으로 4096바이트)를 협상할 수 있으며, 모든 최신 리졸버가 지원합니다
• DNSSEC에서는 서명 데이터만으로도 512바이트를 훨씬 넘기 때문에 EDNS0 사용이 필수입니다
• TCP 폴백 — 오늘날에는 TCP 3방향 핸드셰이크에 TLS / 쿠키를 더해도 비용이 이미 낮습니다

하지만 루트 서버 목록은 이제 네트워크 전체의 합의입니다: 지구상의 모든 재귀 리졸버는 힌트 파일(named.root)에 이 13개 그룹을 하드코딩하고 있으며, 그 리졸버들 뒤에는 수십억 대의 단말이 있습니다. 바꿀 동기는 전혀 없고, 위험은 전 세계 인터넷의 분열이므로 이 숫자는 거의 확실히 영원히 13으로 남을 것입니다.

한마디로: ‘13개 그룹’은 물리적으로는 오래전에 의미를 잃었지만, 공학적으로는 뒤집을 수 없습니다.

5. 핵심 정리

1. 역사적 이유: DNS over UDP의 512바이트 제한 → 수학적 상한 15개 그룹 → 여유를 두고 13개 그룹 선택, 1997년 M-root 가동 이후 고정
2. 프로토콜 관성: 수십억 대 단말의 힌트 파일을 업그레이드하는 것은 비현실적이므로 절대 바뀌지 않음
3. 실제 수용력: 애니캐스트 미러 노드 1395개 이상, 단일 장애점 위험은 거의 0
4. 중국에서의 도달성: F / I / J / K / L 등 여러 루트 서버가 중국 본토에 미러를 두고 있으며, 실측 RTT < 20ms