Warum gibt es weltweit nur 13 Gruppen von Root-Nameservern?

1. Die harte Protokollgrenze: 512 Byte

1.1 IPv4-MTU und unfragmentiertes UDP

Frühe ARPANET- bzw. IPv4-Netze schrieben eine minimale MTU von 576 Byte vor. Jeder Host musste Pakete dieser Größe annehmen können, sonst wäre nicht einmal die grundlegende Erreichbarkeit gewährleistet (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 Byte Gesamtlänge − typischer 20-Byte-IP-Header − 8-Byte-UDP-Header ≈ 548 Byte nutzbar (mit IP-Optionen kann der Header bis zu 60 Byte groß sein, dann bleibt weniger)
• RFC 1035 § 4.2.1 legte die vorsichtigere Zweierpotenz 512 Byte als harte Obergrenze für DNS über UDP fest – das bleibt auch dann sicher, wenn der IP-Header alle Optionen enthält
• Überschreitet eine UDP-Antwort 512 Byte, muss sie gekürzt und das TC-Flag gesetzt werden; der Client weicht dann auf TCP aus – und der TCP-Drei-Wege-Handshake vervielfacht die Latenz der ersten Auflösung

Anders gesagt: „Die vollständige Root-Server-Liste muss in ein einziges 512-Byte-UDP-Paket passen“ – andernfalls müsste weltweit jede Root-Abfrage über TCP laufen, was auf der Hardware der 1980er-Jahre nahezu katastrophal gewesen wäre.

1.2 Byte-Aufbau der DNS-Nachricht

Aufbau der vollständigen Antwort auf eine Abfrage der NS-Records für . (der Server liefert alle Root-NS-Records plus die Glue-A-Records):

Header   (12 Byte)

Formel für die Gesamtlänge:

Mit der 512-Byte-Grenze eingesetzt:

Theoretisch wären bis zu 15 Gruppen möglich, doch es braucht Reserve für DNSSEC-Signaturen, den EDNS0-OPT-Pseudo-Record und Auffüllbytes – daher blieb es bei 13 Gruppen. RFC 2010 (1996) legte die Betriebskriterien für Root-Server fest, und seit M-Root im Folgejahr in Betrieb ging, hat sich die Zahl nicht mehr geändert.

1.3 Selbst testen – <code>dig +noedns -t ns .</code> liefert rund 490–510 Byte

So weit die Theorie. Jetzt fragen wir mit dig tatsächlich einen Root-Server ab und sehen nach, wie groß die echte Antwort ist:

$ 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.
…  (insgesamt 13 NS-Records, c–l ausgelassen)
.                       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 hinein)
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
↑ nur 2 AAAA-Records passen hinein – das Paket ist voll

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

Entscheidend ist die letzte Zeile: eine Antwort von insgesamt rund 490–510 Byte, deutlich unter 512 (der genaue Wert hängt davon ab, welchen Root-Server Sie fragen und wie viele IPv6-Glue-Records zurückkommen). Das deckt sich mit dem Byte-Budget oben. Beachten Sie das Flag +noedns: dig sendet standardmäßig EDNS0, und dann ist die Antwort weit über 800 Byte groß. Genau deshalb ist 512 Byte keine harte Grenze mehr, seit EDNS0 überall unterstützt wird – doch da stand die 13 längst fest.

2. Woher kommt die 13? Ein kurzer Rückblick

Diese Zahl stand nicht von Anfang an fest. Die Zahl der Root-Server wurde mehrfach erhöht; seit M-Root (WIDE, Japan) 1997 in Betrieb ging, hat sie sich nicht mehr verändert:

Seit die Zahl auf 13 festgelegt ist, ändern sich die Buchstabennamen A bis M nie – es wird nur Hardware erneuert, und es kommen Anycast-Spiegelserver hinzu. Die Root-Hints-Datei des Internets (named.root) ist seit Langem fest im Code von Milliarden rekursiver Resolver und Stub-Clients verankert; schon eine einzige Zahl zu ändern, hieße, das gesamte Internet zu aktualisieren.

3. Gibt es weltweit wirklich nur 13 Maschinen?

Nein. Das ist das häufigste Missverständnis. „13 Gruppen von Root-Servern“ meint 13 NS-Namen (a–m.root-servers.net), die jeweils auf eine IPv4- und eine IPv6-Adresse zeigen – nicht 13 physische Maschinen.

Hinter jeder IP steht ein Anycast-Cluster: Dieselbe IP-Adresse wird von Hunderten Rechenzentren weltweit gleichzeitig per BGP angekündigt, und die DNS-Abfrage eines Nutzers wird nach RTT zum nächstgelegenen Spiegelserver geroutet. Wenn ein Root-Server „ausfällt“, wird meist nur der Spiegelserver einer einzelnen Stadt gewartet – die weltweite Auflösung ist davon nicht betroffen.

Stand der 13 Root-Server-Gruppen im Jahr 2024

In Festlandchina (Peking, Shanghai, Shenzhen, Guangzhou, Hefei und weiteren Städten) stehen Anycast-Spiegelserver mehrerer Root-Server, darunter F / I / J / K / L; die gemessene RTT zu den Root-Servern liegt innerhalb Chinas meist unter 20 ms.

4. Seit EDNS0 sind 512 Byte keine echte Grenze mehr

Sie fragen sich vielleicht: DNS-Pakete von 4 KB und mehr sind heute üblich – warum also nicht einfach „über 13 hinausgehen“?

• EDNS0 (RFC 2671 von 1999, aktuell RFC 6891) – handelt eine größere UDP-Nutzlast aus (meist 4096 Byte) und wird von jedem modernen Resolver unterstützt
• DNSSEC setzt EDNS0 zwingend voraus, da allein die Signaturdaten weit über 512 Byte liegen
• TCP-Fallback – moderne TCP-Drei-Wege-Handshakes plus TLS / Cookies sind inzwischen günstig

Die Root-Server-Liste ist inzwischen jedoch ein netzweiter Konsens: Jeder rekursive Resolver der Welt hat diese 13 Gruppen fest in seiner Hints-Datei (named.root) hinterlegt, und hinter diesen Resolvern stehen Milliarden von Endgeräten. Der Anreiz für eine Änderung ist null, das Risiko dagegen ein zersplittertes globales Internet – daher bleibt diese Zahl mit ziemlicher Sicherheit für immer bei 13.

Kurz: „13 Gruppen“ ist physisch längst überholt, technisch aber nicht mehr umzustoßen.

5. Das Wichtigste in Kürze

1. Historischer Grund: 512-Byte-Grenze für DNS über UDP → rechnerische Obergrenze von 15 Gruppen → mit Reserve auf 13 festgelegt, fix seit der Inbetriebnahme von M-Root 1997
2. Protokollträgheit: Die Hints-Dateien auf Milliarden von Endgeräten zu aktualisieren, ist nicht praktikabel – daher ändert sich nichts
3. Tatsächliche Kapazität: über 1395 Anycast-Spiegelserver, das Risiko eines Single Point of Failure liegt nahe null
4. Aus China erreichbar: Mehrere Root-Server, darunter F / I / J / K / L, haben Spiegelserver in Festlandchina, gemessene RTT < 20 ms