Zusammenfassung

  • RFC 9718 trennt das DNSSEC-Root-Schlüsselmaterial von den Verfahren, die seine Verteilungsdatei authentifizieren; weder die ICANN-CA noch die Web-PKI ist der DNSSEC-Vertrauensanker.
  • Ein nutzbarer Anker erfordert fünf getrennte Urteile: echte Datei, zulässiger Zeitraum, widerspruchsfreie Darstellung, unterstützte Verarbeitung und bewusste Annahme durch den Betreiber.

Eine Vertrauenskette lässt sich leicht von oben nach unten erklären. Ein Validator beginnt mit einem vertrauenswürdigen Schlüssel, prüft die Root-Zone und folgt signierten Delegationen. Die unbequeme Frage zeigt nach oben: Wer hat den ersten Schlüssel geprüft?

RFC 4033 verschleiert diese Grenze nicht. Ein Vertrauensanker ist ein autoritativer DNSKEY oder ein DS-Hash, der in einem Validator konfiguriert ist. Sein Anfangswert wird auf sicherem oder vertrauenswürdigem Weg außerhalb des DNS beschafft. DNSSEC authentifiziert alles unterhalb des Ankers, nicht die Entscheidung, die ihn vertrauenswürdig machte.

Hier liegt der bleibende Beitrag von RFC 9718, den Joe Abley mitverfasst hat und der im Januar 2025 als Informational RFC der IETF erschien. Er ersetzt RFC 7958 und beschreibt die Veröffentlichung der Root-Zonen-Anker durch IANA. Außerprotokollarisches Vertrauen verschwindet nicht; seine Nahtstellen werden benannt.

Die erste Naht liegt zwischen Objekt und Umschlag. IANA veröffentlicht ein XML-Dokument mit KeyDigest-Einträgen. Eine abgesetzte CMS-Signatur kann zu einer von ICANN kontrollierten Zertifizierungsstelle führen; HTTPS kann die Übertragung unter der Web-PKI authentifizieren. Beides hilft zu klären, ob die Datei vom erwarteten Herausgeber stammt und unverändert blieb.

Doch die ICANN-CA ist ausdrücklich kein DNSSEC-Vertrauensanker. Die Zertifikatskette authentifiziert das Veröffentlichungsobjekt. Erst nach Verarbeitung und Annahme kann der Hash oder öffentliche Schlüssel darin zum DNSSEC-Anker werden. Wer beides „Vertrauenswurzel“ nennt, verwischt zwei Systeme und den Moment, in dem ein Betreiber den Zustand seines Validators ändert.

Die Änderung gegenüber RFC 7958 verschärft diese Trennung. Das ältere Modell enthielt PKIX-Zertifikate und Zertifikatsanträge für einzelne Schlüssel sowie einen abgesetzten OpenPGP-Weg. RFC 9718 entfernt sie, weil sie das außerprotokollarische Vertrauen in Authentifizierungsschlüssel mit dem Vertrauen in DNSSEC-Root-Schlüssel vermischten. Mehr kryptografische Verpackung beseitigte die Startentscheidung nicht.

Auch die XML-Datei kennt mehrere Zustände. validFrom und validUntil begrenzen den Zeitraum, in dem ein KeyDigest genutzt werden darf. Sie belegen weder eine flächendeckende Installation noch ordnen sie diese an. Eine korrekt signierte, aber zeitlich überholte Datei ist nicht automatisch eine zulässige aktuelle Konfiguration.

Das optionale publickeyinfo kann zusätzlich einen DNSKEY-Public-Key und Flags enthalten. Damit lässt sich DNSKEY-Material direkt bilden, zugleich entsteht eine Konsistenzpflicht: Stimmen öffentlicher Schlüssel und Hash nicht überein, darf dieser KeyDigest nicht verwendet werden. Eine gültige CMS-Signatur heilt keinen inneren Widerspruch.

Optionalität bedeutet lokale Fähigkeit. Zwei konforme Programme können aus demselben authentischen XML unterschiedliche Kandidatenmengen bilden, wenn nur eines publickeyinfo versteht. Gleiche Herkunft garantiert keine gleiche Interpretation. Parser-Version, Umwandlung und Ausgabe gehören in den Betriebsnachweis.

Selbst das XML-Attribut source ist nur ein Hinweis. Eine URL zeigt einen Fundort; ihre Nennung im Dokument verleiht ihr keine Weisungsbefugnis. Ein Ort ist kein Mandat.

Am Ende steht die Annahme. RFC 9718 lässt dem Validator-Betreiber die Entscheidung, Anker nach eigener Richtlinie zu übernehmen. IANA veröffentlicht, Zertifikatssysteme helfen bei der Herkunftsprüfung, Implementierer parsen, Anbieter paketieren, Betreiber verändern den Vertrauenszustand des Resolvers. Keine dieser Flächen darf die andere verkörpern.

RFC 5011 beseitigt die erste Entscheidung nicht. Ein Validator, der bereits einem Anker vertraut, kann nach Beobachtungs- und Haltefristen Nachfolger innerhalb des Protokolls lernen. Bestehendes Vertrauen authentifiziert den Übergang; es kann die ursprüngliche Installation nicht rückwirkend begründen.

Die aktuelle IANA-Seite zeigt die Verteilungsobjekte: root-anchors.xml trägt die Daten, root-anchors.p7s die abgesetzte Signatur und icannbundle.pem die Zertifikate zu ihrer Prüfung. Sie weist zugleich darauf hin, dass Anbieter Updates unterschiedlich und zu verschiedenen Zeiten ausliefern.

In der Formatmitteilung vom November 2024 forderte IANA regelmäßiges Abrufen und Tests des überarbeiteten Formats. Erfolgreiche Veröffentlichung ist kein erfolgreicher Einsatz: Eine echte, aktuelle Datei kann an einem Parser, einem alten Paket oder einer ablehnenden lokalen Richtlinie enden.

Die aktuelle root-anchors.xml ist das maschinenlesbare Veröffentlichungsobjekt, keine Erklärung, dass ein bestimmter Resolver ihre Einträge angenommen hat.

Die NSRC-Biografie nennt Ableys Leitung der ICANN DNS Operations und seine Mitarbeit am DNSSEC-Einsatz in der Root-Zone. Das macht ihn nicht zum Souverän der Root-Zone. Es erklärt die operative Disziplin des RFC: Benachbarte Nachweise dürfen sich nicht gegenseitig vertreten.

Ein prüfbarer Empfangsbeleg braucht fünf Antworten: Wie wurden Herkunft und Inhalt geprüft? Lag der Eintrag im gültigen Zeitraum? Stimmten seine Darstellungen überein? Welcher Parser erzeugte den Kandidaten? Wer nahm ihn nach welcher Regel in welchen Validator auf? „Signatur gültig“ beantwortet nur die erste Frage.