Zusammenfassung
- Seit RFC 9904 sind die IANA-Register die maßgebliche Quelle für getrennte Nutzungs- und Implementierungsempfehlungen zu DNSSEC-Signierung, Delegation und Validierung.
- RFC 9905 verbietet neues DNSKEY-, RRSIG- und DS-Material auf SHA-1-Basis, erhält aber die Validierungsunterstützung. Ein regelkonformer Registerstand eröffnet deshalb die operative Migration; er beweist nicht deren Abschluss.
Im Register stand neben RSASHA1 für die Signaturnutzung nun MUST NOT. Gleichzeitig lieferte eine laufende Zone noch SHA-1-DNSKEYs und -Signaturen aus, und die übergeordnete Zone führte weiterhin altes Delegationsmaterial. Beides konnte wahr sein: Die Koordinationsentscheidung war weitergezogen, die verteilte Ausführung noch nicht.
Die im November 2025 veröffentlichte RFC 9904 verlagerte die zuvor in RFC 8624 zusammengefassten DNSSEC-Algorithmusempfehlungen in IANA-Register. Der Eintrag des RFC Editor hält Status und Verhältnis zu früheren Dokumenten wie RFC 9157 fest. RFC 9904 änderte die übernommenen Empfehlungsstufen zunächst nicht. Es änderte den Ort, an dem spätere Entscheidungen verbindlich verzeichnet werden.
Entscheidend ist die Form der Tabelle. Das DNS Security Algorithm Numbers Register behandelt getrennt, ob ein Algorithmus zum Signieren und zum Validieren verwendet sowie in Signatur- und Validierungssoftware implementiert werden soll. Das Register der DS-Digesttypen trennt Erzeugung und Validierung von Delegationen. Das pauschale Wort „unterstützt“ kann vier verschiedene Pflichten nicht länger verdecken.
RFC 9905 setzte diese Struktur ein. RSASHA1 und RSASHA1-NSEC3-SHA1 dürfen nicht mehr zur Erzeugung neuer DNSKEY-, RRSIG- oder DS-Daten dienen. Validierende Resolver müssen die Signaturalgorithmen jedoch weiter implementieren, solange sie noch aus dem aktiven Bestand verschwinden. Neue Abhängigkeit wird gestoppt, ohne verbliebene Zonen vor ihrem Ausstieg abzuschneiden.
Diese Asymmetrie ist Migrationsmechanik. Signatursoftware erzeugt DNSKEY und RRSIG in der Kindzone. Ein Registrar- oder Registry-Prozess ändert DS in der Elternzone. Autoritative Server konvergieren auf einen neuen Zonen-Serial. Rekursive Caches behalten ältere Datensätze bis zum Ablauf der TTL. Validatoren unterscheiden sich nach Version, Fähigkeiten und Beobachtungszeit. Der Erfolg eines einzelnen Jobs regiert diese Eigentümer und Uhren nicht.
Auch das Validierungsergebnis braucht einen präzisen Namen. RFC 9364 ordnet DNSSEC in die größere Familie der Herkunftsauthentifizierung ein; RFC 4035 unterscheidet secure, insecure, bogus und indeterminate. RFC 9905 sieht in bestimmten SHA-1-Fällen eine insecure-Behandlung vor, wenn keine akzeptierte Alternative Delegation oder Antwort validiert. Daraus folgt weder, dass jede Zone mit SHA-1 bogus ist, noch dass ihr Dienst unerreichbar sein muss.
Die Reihenfolge des Rollovers ist der kritische Punkt. RFC 9904 warnt, dass ein gleichzeitiger Wechsel des DS-Algorithmus und die Einführung eines neuen KSK die Validierung brechen kann; der DS-Algorithmus muss zuerst aktualisiert werden. RFC 6781 zeigt die erforderlichen gestuften Übergänge von RRSIG, DNSKEY und DS samt Ausbreitungs- und Cache-Ablauffristen. Ein grüner Signaturjob kann daher neben einer unsicheren Sicht entfernter Validatoren bestehen.
Ein belastbarer Abschluss verbindet mehrere Belege: IANA-Snapshot und autorisierende RFC, Software- und Konfigurationsversion des Signers, Zonen-Serial, exakte DNSKEY/RRSIG/DS-Mengen, Transaktionsbeleg der Elternzone, autoritative Messungen aus unabhängigen Blickpunkten, TTL-Fenster, Validatorversionen und -ergebnisse, Fehlertelemetrie, Rückfallzustand und das Anwendungsziel. Jeder Beleg beantwortet eine Frage; keiner darf die Aussagekraft der ganzen Kette erben.
Heng Lus Minimum Initial Specification spricht für eine schmale gemeinsame Tabelle und rechenschaftspflichtige lokale Einführung. Running-Code Primacy verlangt Nachweise aus laufenden Datensätzen und Validatoren. Reality Layers verhindert, dass Empfehlung, Konfiguration, publiziertes RRset und Nutzerauswirkung in einer institutionellen Aussage verschmelzen. Das sind offengelegte redaktionelle Prinzipien, keine zusätzlichen DNSOP-Anforderungen.
Das Register kann die Richtung des Ökosystems bestimmen. Ob eine konkrete Zone und ihre Validatoren angekommen sind, zeigt nur eine beobachtete, zeitlich gebundene Beweiskette.
Sources
- https://www.rfc-editor.org/rfc/rfc9904.html
- https://www.rfc-editor.org/info/rfc9904/
- https://www.rfc-editor.org/rfc/rfc9905.html
- https://www.rfc-editor.org/rfc/rfc8624.html
- https://www.rfc-editor.org/rfc/rfc9157.html
- https://www.rfc-editor.org/rfc/rfc9364.html
- https://www.rfc-editor.org/rfc/rfc4035.html
- https://www.rfc-editor.org/rfc/rfc6781.html
- https://www.iana.org/assignments/dns-sec-alg-numbers
- https://www.iana.org/assignments/ds-rr-types
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

