--- id: "root-zone" kind: "glossary-term" title: "Root-Zone" language: "de" category: "DNS und technische Grundlagen" updated: "2026-10-10T23:13:20Z" canonical: "https://tldlog.com/de/glossar/root-zone/" translations: en: "https://tldlog.com/glossary/root-zone/" es: "https://tldlog.com/es/glosario/zona-raiz/" fr: "https://tldlog.com/fr/glossaire/zone-racine/" it: "https://tldlog.com/it/glossario/zona-radice/" pt-BR: "https://tldlog.com/pt/glossario/zona-raiz/" ru: "https://tldlog.com/ru/glossariy/kornevaya-zona/" zh-Hans: "https://tldlog.com/zh/cihui/genqu/" --- # Root-Zone Die oberste Ebene des DNS. Sie listet jede TLD, etwa .com oder .es, und die Nameserver jeder einzelnen auf. Eine neue TLD ins Internet aufzunehmen bedeutet, sie in die Root-Zone einzutragen, ein Vorgang, den die IANA koordiniert. Die Root-Zone ist die Spitze des Domain Name System: eine kleine, öffentliche Liste aller Top-Level-Domains (TLDs) wie .com oder .es und der Server, die für jede von ihnen antworten. Weiß ein Resolver nicht, wo er eine TLD findet, fragt er einen Root-Server, der aus der Root-Zone antwortet. Eine TLD funktioniert im Internet erst, wenn sie dort eingetragen ist. ## Was die Root-Zone ist und was sie enthält Die IANA beschreibt die Root-Zone als „hauptsächlich aus Delegationen von Top-Level-Domains bestehend“. Für jede TLD enthält sie die Nameserver als NS-Records sowie die DS-Records, die die TLD in die DNSSEC-Vertrauenskette einbinden. Außerdem enthält sie die Adressen der Root-Server selbst. Einzelne Domains wie example.com enthält sie nicht: Sie verweist nur auf die Server der jeweiligen TLD. Jeder kann die vollständige Root-Zone-Datei bei der IANA herunterladen, mit denselben Daten, die die Root-Server ausliefern. Die IANA führt außerdem die Root Zone Database, in der Verwalter, technische Angaben und Kontakte jeder TLD verzeichnet sind. Die Root-Zone ist seit Juli 2010 mit DNSSEC signiert. ## Root-Server: wie viele es gibt und wer sie betreibt Die Root-Zone wird von 13 benannten Identitäten ausgeliefert, a.root-servers.net bis m.root-servers.net. Diese Zahl zählt Namen und Adressen, nicht Maschinen: Die IANA spricht von „einem Netz aus Hunderten von Servern in vielen Ländern“. Am 9. Oktober 2026 zählte root-servers.org 2.047 aktive Instanzen, betrieben von 12 unabhängigen Organisationen; Verisign betreibt zwei Identitäten, a und j. Nach einer RSSAC-Erklärung von 2019 müssen die Betreiber voneinander und von jeder Regierung oder übergeordneten Organisation unabhängig bleiben, und sie arbeiten unter verschiedenen Rechtsordnungen. ## Wie eine TLD in die Root aufgenommen oder aus ihr entfernt wird Die Aufnahme einer TLD heißt Delegation und ist ein eigener Schritt, getrennt von der Bewerbung. Bei einer neuen gTLD folgt sie, nachdem die ICANN ein Registry Agreement unterzeichnet und die Tests vor der Delegation durchgeführt hat. Der Registry-Betreiber übermittelt dann Verwalter, Kontakte, Nameserver und DS-Records über das Root-Zone-Management-System der IANA, und seine NS-Records werden in die Root-Zone aufgenommen. Jede Änderung an der Root-Zone, auch neue Nameserver für eine bestehende TLD, durchläuft die Prüfungen und technischen Tests der IANA und muss von den Kontakten der TLD bestätigt werden, bevor sie umgesetzt wird. Ein wesentlicher Kontrollwechsel gilt als Redelegierung, mit eigenen Kriterien. Eine ccTLD gibt es, weil ihr Land oder Gebiet einen Code in ISO 3166-1 hat. Wird der Code gestrichen, stellt die IANA eine Notice of Removal aus. Stand Oktober 2026 wird die ccTLD standardmäßig nach fünf Jahren entfernt, höchstens nach 10 Jahren, wenn innerhalb von 12 Monaten nach der Mitteilung eine Verlängerung beantragt wird. Der ICANN-Vorstand hat diese Richtlinie am 22. September 2022 beschlossen. Bei einer gTLD, deren Registry Agreement beendet wird und die die ICANN nicht an einen nachfolgenden Registry-Betreiber überträgt, wird die Delegation widerrufen; die Zeichenfolge kann in einer künftigen Bewerbungsrunde erneut angeboten werden. ## Wer Änderungen kontrolliert: IANA, Maintainer und Betreiber - **Die IANA**, deren Funktionen PTI wahrnimmt, eine Tochtergesellschaft der ICANN, prüft jeden Änderungsantrag und führt die Root Zone Database. Änderungen gehen vom Verwalter der TLD aus, der sie online einreicht und bestätigen muss. - **Verisign** stellt als Root Zone Maintainer nach einem Vertrag mit der ICANN die Zone im Auftrag der IANA zusammen, signiert sie mit dem Zone Signing Key und schickt sie an die Betreiber. Stand Oktober 2026 läuft der Vertrag (unterzeichnet am 28. September 2016, geändert am 20. Oktober 2024) in Laufzeiten von acht Jahren, die sich automatisch verlängern. - **Die Root-Server-Betreiber** liefern die Zone genau so aus, wie sie verteilt wurde. RSSAC001 (Dezember 2015) hält fest, dass ein Betreiber die signierten Daten nicht verändern könnte, ohne ihre Signaturen ungültig zu machen. ## Mythen über das „Abschalten des Internets“ an der Root - **Es gibt keinen einzelnen Schalter.** Zwölf unabhängige Betreiber in verschiedenen Rechtsordnungen betreiben mehr als 2.000 Instanzen. - **Betreiber können Records nicht unbemerkt ändern.** Die DNSSEC-Signaturen würden eine Änderung offenlegen. - **Ein kurzer Ausfall fällt kaum auf.** Laut RFC 8806 halten Resolver TLD-Daten in der Regel „in der Größenordnung von ein oder zwei Tagen“ im Cache. Unangreifbar ist die Root deshalb nicht. Am 23. Dezember 2025 traf ein DDoS-Angriff 10 der 13 Identitäten, erreichte in der Spitze mehr als ein Terabit pro Sekunde und dauerte knapp zehn Minuten. Der Bericht der Betreiber vom Juli 2026 stellte keine bekannten Fehler fest, die für Endnutzer sichtbar waren, nur geringe Verzögerungen bei einigen Abfragen, und führt dies auf die Unabhängigkeit und Vielfalt der Betreiber zurück. ## Lokale Kopien der Root und warum Resolver sie vorhalten Ein Resolver startet normalerweise mit Root Hints, einer kurzen Liste von Namen und Adressen der Root-Server, die meist in seine Software eingebaut ist; die IANA veröffentlicht die offizielle Fassung. Beim Start fragt der Resolver einen Root-Server nach der aktuellen Liste, ein Schritt namens Priming (RFC 9609, Februar 2025), weil sich die Adressen der Root-Server gelegentlich ändern. Eine hyperlokale Root geht weiter: Der Resolver hält eine vollständige Kopie der Root-Zone auf derselben Maschine vor und beantwortet damit nur seine eigenen Anfragen (RFC 8806, Juni 2020). Die Kopie muss mit DNSSEC validiert und mit der echten Zone identisch sein; lässt sie sich nicht rechtzeitig aktualisieren, muss der Resolver sofort wieder die Root-Server nutzen. Als Ziele werden Zuverlässigkeit bei Angriffen und Datenschutz genannt. RFC 8806 erwartet bei bestehenden TLDs, die meist schon im Cache liegen, kaum Geschwindigkeitsgewinn und warnt, dass eine fehlerhafte Einrichtung Nutzern falsche Daten liefern kann. Eine hyperlokale Root kopiert die offizielle Zone, eine alternative Root verändert sie. Stand 9. Oktober 2026 ist der Root-KSK-Rollover für den 11. Oktober 2026 geplant; dann löst KSK-2024 den KSK-2017 ab. Validierende Resolver, auch hyperlokale Roots, brauchen den aktualisierten Vertrauensanker. ## Quellen - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Root Zone Change Request Process (IANA)](https://www.iana.org/help/root-zone-process) - [December 2025 DDoS against multiple DNS root servers (root server operators)](https://root-servers.org/media/news/2025-12-23_DDoS.pdf) - [RFC 8806: Running a Root Server Local to a Resolver](https://www.rfc-editor.org/rfc/rfc8806.txt) ## verwandte begriffe - [Root-Server](https://tldlog.com/de/glossar/root-server/) - [Delegation (TLD)](https://tldlog.com/de/glossar/delegation-tld/) - [IANA](https://tldlog.com/de/glossar/iana/) - [PTI](https://tldlog.com/de/glossar/pti/)