Dlaczego na świecie jest tylko 13 grup serwerów głównych DNS?

1. Twarde ograniczenie protokołu: 512 bajtów

1.1 MTU w IPv4 i niefragmentowany UDP

Wczesne sieci ARPANET / IPv4 wymagały minimalnego MTU 576 bajtów. Każdy host musiał móc odbierać pakiety tej wielkości, inaczej nie dało się zagwarantować nawet podstawowej osiągalności (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 bajtów długości całkowitej − typowe 20 bajtów nagłówka IP − 8 bajtów nagłówka UDP ≈ 548 bajtów do wykorzystania (z opcjami IP nagłówek może mieć 60 bajtów, więc zostaje mniej)
• RFC 1035 § 4.2.1 przyjęło bardziej zachowawczą potęgę dwójki, 512 bajtów, jako twardy limit dla DNS przez UDP — bezpieczny nawet wtedy, gdy nagłówek IP zawiera pełne opcje
• Jeśli odpowiedź UDP przekracza 512 bajtów, musi zostać obcięta z ustawioną flagą TC, co zmusza klienta do przejścia na TCP — a trójetapowe uzgadnianie TCP kilkakrotnie zwiększa opóźnienie pierwszego rozwiązania nazwy

Innymi słowy: „pełna lista serwerów głównych musi zmieścić się w jednym pakiecie UDP o rozmiarze 512 bajtów” — w przeciwnym razie każde zapytanie do serwerów głównych na świecie musiałoby iść przez TCP, co na sprzęcie z lat 80. byłoby niemal katastrofą.

1.2 Układ bajtów w wiadomości DNS

Pełna struktura odpowiedzi na zapytanie o rekordy NS dla . (serwer zwraca wszystkie rekordy NS serwerów głównych oraz rekordy glue A):

Header   (12 bajtów)

Wzór na długość całkowitą:

Po podstawieniu limitu 512 bajtów:

Teoretycznie mieści się do 15 grup, ale potrzebny jest zapas na podpisy DNSSEC, pseudorekord EDNS0 OPT i wypełnienie pól, więc ustalono 13 grup — RFC 2010 (1996) określiło kryteria operacyjne serwerów głównych, a liczba nie zmieniła się od uruchomienia M-root w kolejnym roku.

1.3 Test w praktyce — <code>dig +noedns -t ns .</code> zwraca ok. 490–510 bajtów

Tyle teorii. Teraz naprawdę odpytajmy serwer główny za pomocą dig i zobaczmy, jak duża jest rzeczywista odpowiedź:

$ 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.
…  (łącznie 13 rekordów NS, c–l pominięto)
.                       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
…  (zmieściło się wszystkich 13 rekordów glue A)
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
↑ zmieściły się tylko 2 rekordy AAAA — pakiet jest pełny

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

Kluczowy wiersz na końcu — łączny rozmiar odpowiedzi ok. 490–510 bajtów, wyraźnie poniżej 512 (dokładna wartość zależy od tego, który serwer główny odpytujesz i ile rekordów glue IPv6 wraca) — zgadza się z powyższym budżetem bajtów. Zwróć uwagę na flagę +noedns: dig domyślnie wysyła EDNS0, a wtedy odpowiedź ma znacznie ponad 800 bajtów. Właśnie dlatego 512 bajtów przestało być twardym limitem, gdy EDNS0 stało się powszechne — ale liczba 13 była już wtedy ustalona.

2. Skąd się wzięło 13? Krótka historia

Ta liczba nie była ustalona od początku. Liczba serwerów głównych kilkakrotnie rosła; po uruchomieniu M-root (WIDE, Japonia) w 1997 roku już się nie zmieniła:

Po ustaleniu liczby 13 nazwy literowe od A do M nigdy się nie zmieniają — modernizuje się tylko sprzęt i dodaje kopie anycast. Plik wskazówek serwerów głównych Internetu (named.root) od dawna jest wbudowany w kod miliardów resolverów rekurencyjnych i klientów stub; zmiana choćby jednej liczby oznaczałaby aktualizację całego Internetu.

3. Ale czy na świecie naprawdę jest tylko 13 maszyn?

Nie. To najczęstsze nieporozumienie. „13 grup serwerów głównych” oznacza 13 nazw NS (a–m.root-servers.net), z których każda odpowiada jednemu adresowi IPv4 i jednemu IPv6 — a nie 13 fizycznym maszynom.

Za każdym adresem IP stoi klaster anycast — ten sam adres IP jest jednocześnie ogłaszany przez BGP z setek centrów danych na świecie, a zapytanie DNS użytkownika trafia do najbliższej kopii według RTT. Gdy serwer główny „pada”, zwykle oznacza to tylko prace serwisowe przy kopii w jednym mieście — globalne rozwiązywanie nazw działa bez zakłóceń.

Stan 13 grup serwerów głównych w 2024 roku

W Chinach kontynentalnych (Pekin, Szanghaj, Shenzhen, Kanton, Hefei i inne) działają węzły anycast kilku serwerów głównych, m.in. F / I / J / K / L; zmierzony RTT do serwerów głównych z Chin wynosi zwykle poniżej 20 ms.

4. Po wprowadzeniu EDNS0 512 bajtów przestało być realnym limitem

Możesz zapytać: pakiety DNS o rozmiarze 4 KB i większe są dziś powszechne, więc dlaczego po prostu nie „przekroczyć 13”?

• EDNS0 (RFC 2671 z 1999 roku, obecnie RFC 6891) — negocjuje większy ładunek UDP (zwykle 4096 bajtów), obsługiwany przez każdy nowoczesny resolver
• DNSSEC wymaga EDNS0, bo same dane podpisów znacznie przekraczają 512 bajtów
• Przejście na TCP (fallback) — nowoczesne trójetapowe uzgadnianie TCP plus TLS / cookies jest już tanie

Ale lista serwerów głównych jest dziś konsensusem całej sieci: każdy resolver rekurencyjny na świecie ma te 13 grup zapisanych na sztywno w pliku wskazówek (named.root), a za tymi resolverami stoją miliardy urządzeń. Motywacja do zmiany jest zerowa, a ryzyko to rozbicie globalnego Internetu, więc ta liczba niemal na pewno już zawsze będzie wynosić 13.

W skrócie: „13 grup” dawno przestało mieć fizyczne uzasadnienie, ale inżynieryjnie nie da się tego zmienić.

5. Najważniejsze wnioski

1. Przyczyna historyczna: limit 512 bajtów dla DNS przez UDP → matematyczny pułap 15 grup → wybrano 13 z zapasem, ustalone po uruchomieniu M-root w 1997 roku
2. Bezwładność protokołu: aktualizacja plików wskazówek na miliardach urządzeń jest niewykonalna, więc liczba się nie zmienia
3. Rzeczywista pojemność: liczba węzłów anycast przekracza 1395, więc ryzyko awarii pojedynczego punktu jest bliskie zeru
4. Dostępność z Chin: kilka serwerów głównych, m.in. F / I / J / K / L, ma kopie w Chinach kontynentalnych, a zmierzony RTT wynosi < 20 ms