Zusammenfassung

  • RFC 9905 ist IETF Standards Track vom November 2025 und aktualisiert RFC 4034 und RFC 5155.
  • RSASHA1 und RSASHA1-NSEC3-SHA1 dürfen nicht zum Erzeugen neuer DS-, DNSKEY- oder RRSIG-Records verwendet werden.
  • Validator-Implementierungen müssen die Validierung mit beiden Algorithmen weiterhin unterstützen. Das ist eine Übergangspflicht, keine Erlaubnis, neue SHA-1-Signaturen zu erzeugen.

Die entscheidende Aussage lautet nicht «SHA-1 ist überall sofort abzuschalten», sondern: Produktion und Konsum erhalten verschiedene Vorgaben. Autoritative Signer dürfen keine DNSKEY- oder RRSIG-Records mit den beiden Algorithmen neu erstellen. Für DS gilt dasselbe Verbot. Enthält eine Delegation nur einen DS dieser Art, muss ein Validator sie unter den genannten Bedingungen als insecure behandeln. Das ist nicht dasselbe wie bogus oder ein Validierungsfehler. Fehlt ein weiterer DS mit einem akzeptierten Algorithmus, werden die Daten unterhalb der Delegationsstelle entsprechend als nicht gesichert behandelt.

Auf der Verbrauchsseite bleibt die Implementierungspflicht bestehen, weil zum Veröffentlichungszeitpunkt noch Domains mit diesen Algorithmen vorhanden waren. Deshalb dürfen Validator-Betreiber nicht allgemein behaupten, SHA-1-Unterstützung jetzt entfernen zu können. Software, die die Validierung bereits entfernt hat, benötigt möglicherweise einen manuellen Build, um das weiterhin verlangte Implementierungsniveau zu erreichen.

Die operative Abfolge

  1. Authoritativer Signer: Inventarisiere DNSKEY, RRSIG und die verwendete Signaturalgorithmik. Baue den Wechsel auf einen von den IANA-Registern empfohlenen stärkeren Algorithmus auf. Neue DS-, DNSKEY- oder RRSIG-Records mit RSASHA1 oder RSASHA1-NSEC3-SHA1 werden nicht erzeugt.
  2. DS-Veröffentlichung: Prüfe den stärkeren DNSKEY- und RRSIG-Pfad unabhängig, bevor ein akzeptierter DS beim Parent veröffentlicht wird. Protokolliere alte und neue Werte, TTLs, Zeitpunkte und Antworten von mehreren Resolvern. Ein alter SHA-1-DS darf nicht neu erzeugt werden.
  3. Rekursive Validierung: Teste den stärkeren Pfad und belege zugleich, dass die Implementierung den verbliebenen SHA-1-Bestand noch validieren kann. Ein Delegationsfall mit ausschließlich altem DS ist als insecure zu prüfen, nicht als bogus zu etikettieren.

Überlappung bedeutet hier, dass der stärkere Pfad bereits veröffentlicht und geprüft wird, während noch alte Daten im installierten Bestand und in Caches existieren. Sie bedeutet nicht, weiterhin SHA-1-Material zu signieren. Rollback-Nachweise sollten die letzte funktionierende stärkere Signatur- und DS-Konfiguration, TTL-Fenster, Prüfresultate und einen sicheren Wiederherstellungsweg dokumentieren. Ein Rollback darf nicht die verbotene Neuerzeugung von SHA-1-Records voraussetzen.

Konkrete Prüfungen

  • Verhindert die Signer-Pipeline die Erzeugung von DS, DNSKEY und RRSIG mit beiden SHA-1-Algorithmen?
  • Gibt es einen stärkeren, von den IANA-Registern empfohlenen Algorithmus, und validiert ein unabhängiger rekursiver Resolver ihn?
  • Sind «nicht mehr signieren» und «weiter validieren» als zwei getrennte Kontrollen dokumentiert?
  • Wird eine Delegation mit ausschließlich SHA-1-DS als insecure und nicht als bogus oder fehlgeschlagen ausgewiesen?
  • Ist nachvollziehbar, ob eine Softwareversion SHA-1-Validierung entfernt hat und deshalb ein manueller Build erforderlich ist?

Der Betreiberpfad ist eindeutig: Produziert die Zone noch SHA-1, stoppe diese Produktionsstrecke und migriere auf einen stärkeren Algorithmus. Ist nur ein alter DS veröffentlicht, korrigiere die Delegation und koordiniere einen akzeptierten DS. Fehlt dem Validator die Implementierung, stelle sie wieder her oder erzeuge einen passenden manuellen Build, bevor der Übergang als abgeschlossen gilt. Aussagen über Verbreitung, Herstellerverhalten, Vorfälle, Performance oder künftige Registry-Änderungen sind aus dem eingefrorenen Quellenbestand nicht ableitbar.

Quellen