Waarom zijn er wereldwijd maar 13 groepen rootnameservers?

1. De harde protocolbeperking: 512 bytes

1.1 IPv4-MTU en ongefragmenteerde UDP

Vroege ARPANET- / IPv4-netwerken schreven een minimale MTU van 576 bytes voor. Elke host moest pakketten van die grootte kunnen ontvangen, anders kon zelfs basale bereikbaarheid niet worden gegarandeerd (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 bytes totale lengte − typische IP-header van 20 bytes − UDP-header van 8 bytes ≈ 548 bytes bruikbaar (met IP-opties kan de header tot 60 bytes groeien, waardoor er minder overblijft)
• RFC 1035 § 4.2.1 koos de voorzichtigere macht van twee, 512 bytes, als harde limiet voor DNS over UDP — veilig, zelfs als de IP-header alle opties bevat
• Is een UDP-antwoord groter dan 512 bytes, dan moet het worden afgekapt met de TC-vlag gezet, waardoor de client terugvalt op TCP — en de three-way handshake van TCP vermenigvuldigt de latentie van de eerste resolutie

Met andere woorden: “de volledige lijst met rootservers moet in één UDP-pakket van 512 bytes passen” — anders zou elke rootquery wereldwijd via TCP moeten gaan, wat op hardware uit de jaren 80 bijna catastrofaal was geweest.

1.2 Indeling van het DNS-bericht in bytes

De volledige antwoordstructuur voor een query naar de NS-records van . (de server geeft alle root-NS-records plus glue-A-records terug):

Header   (12 bytes)

Formule voor de totale lengte:

Met de limiet van 512 bytes ingevuld:

In theorie zijn er zo maximaal 15 groepen mogelijk, maar er is ruimte nodig voor DNSSEC-handtekeningen, het EDNS0-OPT-pseudorecord en opvulling van velden, dus werd het 13 groepen — RFC 2010 (1996) legde de operationele criteria voor rootservers vast, en het aantal is niet meer veranderd sinds M-root het jaar daarop online kwam.

1.3 Test het zelf — <code>dig +noedns -t ns .</code> geeft ongeveer 490–510 bytes terug

Tot zover de theorie. Laten we nu met dig echt een rootserver bevragen en kijken hoe groot het werkelijke antwoord is:

$ 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.
…  (13 NS-records in totaal, c–l weggelaten)
.                       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
…  (alle 13 glue-A-records passen erin)
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
↑ er passen maar 2 AAAA-records in — het pakket is vol

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

De belangrijke regel aan het eind — een totaal antwoord van ongeveer 490–510 bytes, ruim onder 512 (het precieze getal hangt af van welke root je bevraagt en hoeveel IPv6-glue-records terugkomen) — klopt met het bytebudget hierboven. Let op de vlag +noedns: dig stuurt standaard EDNS0 mee, en dan is het antwoord ruim 800 bytes. Precies daarom is 512 bytes geen harde limiet meer sinds EDNS0 overal wordt ondersteund — maar toen lag 13 al vast.

2. Waar komt 13 vandaan? Een korte geschiedenis

Dit getal lag niet vanaf het begin vast. Het aantal rootservers is meerdere keren uitgebreid; nadat M-root (WIDE, Japan) in 1997 online kwam, is het nooit meer veranderd:

Sinds het aantal op 13 vastligt, veranderen de letternamen A t/m M nooit — alleen de hardware wordt vernieuwd en er komen anycast-mirrors bij. Het root-hintbestand van het internet (named.root) zit al lang ingebakken in de code van miljarden recursieve resolvers en stub-clients; één getal wijzigen zou betekenen dat het hele internet moet upgraden.

3. Maar zijn er wereldwijd echt maar 13 machines?

Nee. Dit is het meest voorkomende misverstand. “13 groepen rootservers” verwijst naar 13 NS-namen (a–m.root-servers.net), elk gekoppeld aan één IPv4- en één IPv6-adres — niet naar 13 fysieke machines.

Achter elk IP-adres zit een anycast-cluster — hetzelfde IP-adres wordt tegelijk door honderden datacenters wereldwijd via BGP aangekondigd, en de DNS-query van een gebruiker wordt op basis van RTT naar de dichtstbijzijnde mirror gerouteerd. Als een rootserver “uitvalt”, betekent dat meestal alleen dat de mirror in één stad in onderhoud is — de wereldwijde resolutie merkt daar niets van.

Status van de 13 rootservergroepen in 2024

Op het Chinese vasteland (Peking, Shanghai, Shenzhen, Guangzhou, Hefei en meer) staan anycast-mirrors van meerdere rootservers, waaronder F / I / J / K / L; de gemeten RTT naar rootservers vanuit China ligt doorgaans onder 20ms.

4. Sinds EDNS0 is 512 bytes geen echte limiet meer

Je vraagt je misschien af: DNS-pakketten van 4 KB of meer zijn tegenwoordig heel gewoon, dus waarom niet gewoon “voorbij 13 gaan”?

• EDNS0 (RFC 2671 uit 1999, nu RFC 6891) — onderhandelt over een grotere UDP-payload (meestal 4096 bytes) en wordt door elke moderne resolver ondersteund
• DNSSEC vereist EDNS0, omdat de handtekeningdata alleen al ver boven 512 bytes uitkomt
• TCP-fallback — een moderne three-way handshake van TCP plus TLS / cookies is inmiddels goedkoop

Maar de lijst met rootservers is nu een consensus over het hele netwerk: elke recursieve resolver ter wereld heeft deze 13 groepen hard vastgelegd in zijn hintbestand (named.root), en achter die resolvers zitten miljarden apparaten. De drijfveer om iets te veranderen is nul, en het risico is een versplinterd wereldwijd internet, dus dit getal blijft vrijwel zeker voor altijd 13.

Kortom: “13 groepen” is fysiek al lang achterhaald, maar technisch onmogelijk terug te draaien.

5. De belangrijkste punten

1. Historische reden: de limiet van 512 bytes voor DNS over UDP → een wiskundig plafond van 15 groepen → met marge werd het 13, vastgelegd toen M-root in 1997 online kwam
2. Protocolinertie: de hintbestanden op miljarden apparaten bijwerken is onhaalbaar, dus het verandert nooit
3. Werkelijke capaciteit: 1395+ anycast-mirrors, waardoor het risico op een single point of failure bijna nul is
4. Bereikbaar vanuit China: meerdere rootservers, waaronder F / I / J / K / L, hebben mirrors op het Chinese vasteland, met een gemeten RTT < 20ms