Zusammenfassung

  • Eine Root-Hints-Datei ist ein Bootstrap-Weg, keine dauerhafte Aussage über DNS-Autorität.
  • RFC 9609 beschreibt den Übergang: . nach NS fragen, die autoritative Root-Antwort normal cachen und bei ausbleibender Antwort eine andere konfigurierte Adresse versuchen.
  • Konfiguration sagt, wo eine Frage beginnen kann; die DNS-Antwort liefert den aktuellen Zustand; die TTL beendet dessen Aktualität.

Analyse

Ein leerer Cache erzeugt einen Kreis. Um einen Nameserver zu finden, müsste der Resolver bereits einen Nameserver kennen. Root Hints durchbrechen diesen Kreis mit Adressen einiger Root-Server-Identifikatoren. Die Datei enthält nicht die Root-Zone und bestimmt keine fortdauernde Autorität. Sie macht nur die erste Frage zustellbar.

Diese Frage verwendet den Root-Namen ., den Typ NS und die Klasse IN. RFC 9609 nennt sie Priming Query. Sie geht an eine konfigurierte Adresse und soll den aktuellen Root-NS-RRset sowie verfügbare IPv4- und IPv6-Adressen in den Cache bringen. Aus Distributionskonfiguration wird gelernter DNS-Zustand.

Das Ersetzen ist notwendig, weil Adressen altern. Root-Server-Identifikatoren sind seit 1997 stabil, ihre zugehörigen Adressen können sich jedoch ändern. RFC 9609 spricht bewusst von mutmaßlichen Adressen. Was bei Auslieferung stimmt, kann später Verzögerungen oder Ausfälle verursachen.

Der historische Ursprung liegt in RFC 1034. Dessen Resolver-Algorithmus nannte die Rückfallstruktur SBELT, Sicherheitsgurt. Wenn der Cache keinen brauchbaren Server lieferte, wurden konfigurierte Helfer in die Arbeitsliste übernommen. Der Gurt verhinderte den Absturz in einen leeren Zustand; er lenkte nicht jede weitere Anfrage.

RFC 8109 dokumentierte Priming 2017 als BCP 209. RFC 9609 löste sie 2025 ab und ist die aktuelle BCP. Sie präzisierte den Inhalt der Startinformation, Prefetch, die Wiederbeschaffung fehlender Adressen, Root-Server-Identifikatoren und den Unterschied zwischen Priming-Antwort und Referral.

Die Anfrage hat enge Bedingungen. RD sollte null sein. EDNS0 sollte verwendet und mindestens 1024 Oktette sollten wieder zusammengesetzt werden können. Bei UDP sollte der Quellport zufällig sein; DNS Cookies können Off-Path-Fälschung zusätzlich erschweren. Ein falscher Startpunkt kann jede spätere Auflösung beeinflussen.

Die Antwort muss NOERROR sein, AA setzen und den Root-NS-RRset in Answer tragen. Authority muss leer sein, weil der gefragte RRset bereits in der Antwort steht. Additional kann A und AAAA der genannten Identifikatoren enthalten.

Diese Adressen sind kein Glue. Die Nachricht verweist nicht auf eine Kindzone, sondern antwortet direkt auf die Root-NS-Frage. Deshalb gilt die TC-Regel aus RFC 9471 für unvollständiges Delegations-Glue nicht. Fehlende Adressen erzwingen hier kein Truncation-Bit.

Eine Wiederholung derselben Frage vervollständigt die Liste nicht zwingend. Feste Reihenfolgen können dieselben Daten erneut auslassen. Der Resolver muss A und AAAA für fehlende Identifikatoren direkt abfragen. Er darf auch nicht exakt dreizehn NS erwarten, obwohl der hier eingefrorene IANA-Snapshot dreizehn enthält.

Nach dem Caching gilt die TTL. Der Root-NS-RRset läuft wie andere DNS-Daten ab. Prefetch vor Ablauf ist möglich; RFC 9609 empfiehlt dafür aktuelle Cache-Adressen statt eines vorschnellen Rückgriffs auf möglicherweise alte Konfiguration.

Antwortet ein Ziel nicht, muss eine andere konfigurierte Adresse versucht werden. Die Auswahl sollte zufällig über erreichbare Ziele verteilt sein und die tatsächliche IPv4-/IPv6-Konnektivität berücksichtigen. Redundanz besteht erst, wenn die Implementierung den Pfad wirklich wechselt.

Die für diesen Artikel eingefrorene IANA-Datei named.root nennt die Root-Zonen-Version 2026072901. Sie enthält dreizehn Identifikatoren mit je einem A- und AAAA-Eintrag und zeigt eine TTL von 3.600.000 Sekunden. Das sind keine dreizehn physischen Maschinen; jeder Identifikator erreicht viele Anycast-Instanzen.

Das Sicherheitsproblem bleibt. Eine gefälschte Priming-Antwort kann künftige Anfragen umleiten. RFC 9609 sieht keine endgültige Verhinderung, solange diese Antworten nicht durch DNSSEC geschützt sind. Spätere Validierung kann manche Angriffe erkennen, macht aber Hints oder Startadressen nicht zur authentisierten Autorität.

Nach dem Priming wählt der Resolver weiterhin eine Strategie: schnellsten Server messen, Leistungsgruppen bilden oder zufällig auswählen. Die BCP schreibt keinen Algorithmus vor und rät, die Root bei dieser Entscheidung nicht besonders zu behandeln. Wichtigkeit hebt Ablauf und Erreichbarkeit nicht auf.

Die historische Reife liegt in der Begrenzung. Der Distributor liefert eine Route für die erste Frage. Autorität liefert den aktuellen Zustand. Die TTL entzieht ihm Aktualität. Retry entzieht einer Adresse ihr Monopol. Ein Hinweis bleibt nützlich, weil eine bessere Antwort ihn ersetzen muss.

Sources