Summary

  • Der erste DNSOP-Arbeitsgruppenentwurf will unter bestimmten DS- oder Trust-Anchor-Bedingungen eine Signatur mit mindestens einem UNIVERSAL-Algorithmus genügen lassen; weitere Algorithmen müssten dann nicht jede Antwort signieren.
  • Die Algorithmen 8 und 13 wären anfangs UNIVERSAL. Die aktuelle IANA-Tabelle verlangt ihre Implementierung für die Validierung bereits, enthält die vorgeschlagene neue Statusspalte aber noch nicht.
  • Ein Resolver, der einen angekündigten UNIVERSAL-Algorithmus lokal abschaltet, würde die Zone als unsigniert behandeln, selbst wenn er einen anderen angekündigten Algorithmus beherrscht. Die eigene Entscheidung kostet DNSSEC-Authentifizierung.

Eine DNS-Zone muss für alle gemeldeten Algorithmen signieren; einem validierenden Resolver reicht ein gültiger Pfad. So verteilen RFC 4035 und RFC 6840 die Arbeit. Weil der Signierer die Fähigkeiten eines fremden Resolvers nicht kennt, liefert er den ganzen Satz. Der neue Entwurf will diese Versicherung günstiger machen, sobald mindestens ein Algorithmus nach gemeinsamem Register von allen Validatoren unterstützt werden sollte.

In einer Zone mit zwei DNS-Anbietern wird aus Signaturarbeit ein Vertragsproblem. RFC 8901 beschreibt ein Modell mit getrennten Schlüsseln für jeden Anbieter. Verwenden die Anbieter unterschiedliche Algorithmen, zwingt die bisherige Vollständigkeitsregel sie zu enger Zusammenarbeit. Ein Anbieterwechsel erbt diese Last. Bei einer neuen Root-Vertrauensankerung kann die Pflicht, sämtliche Signaturen frühzeitig auszuliefern, eine lange Doppelphase erzeugen. Die Vorlage möchte Ankündigung und tatsächliche Verwendung zeitlich trennen.

Ein Wort in der IANA-Tabelle ändert den Betrieb

Der Entwurf verlangt eine IANA-Spalte namens Validation support status. Sie könnte UNIVERSAL, FORMERLY-UNIVERSAL oder leer sein. Anfangs stünden RSA/SHA-256, Nummer 8, und ECDSA P-256/SHA-256, Nummer 13, auf UNIVERSAL. Für beide fordert das heutige Register bereits eine Implementierung auf Validatorseite. Die frühere Universal-Kategorie beginnt leer. Aus der Registererwartung würde eine Grundlage dafür, welche RRSIGs ein Signierer weglassen darf.

Die vorgeschlagene Regel prüft die DS-Menge beim Elternteil oder die Trust Anchors. Gibt es dort mindestens einen UNIVERSAL-Algorithmus und keinen FORMERLY-UNIVERSAL, muss der Signierer mit einem UNIVERSAL signieren; andere Signaturen sind optional. DNSKEYs für ungenutzte Algorithmen können ebenfalls entfallen. Fehlt UNIVERSAL ganz oder steht ein ehemaliger Universalalgorithmus in der Menge, bleibt die Pflicht zu allen Algorithmen bestehen. Die Bedingung ist genauer als das Schlagwort „eine Signatur reicht“.

So könnten zwei Anbieter mit Nummer 8 und Nummer 13 jeweils einen eigenen gültigen Pfad liefern. Eine neue Vertrauensankerung dürfte vor der passenden DNSKEY und RRSIG in der Zone veröffentlicht werden. Ein Anbieter könnte einen experimentellen Post-Quanten-Algorithmus einsetzen, ohne alle Partner gleichzeitig umzurüsten. Für einen Algorithmus ohne UNIVERSAL-Status kann der endgültige Wechsel weiterhin eine Doppelphase erfordern.

Der lokale Schalter gehört in die Bilanz

Eine Zone meldet 8 und 13; ein Anbieter liefert einen gültigen Pfad über 8. Der Administrator eines Resolvers hat 8 lokal deaktiviert, obwohl 13 unterstützt wird. Nach dem Entwurf muss der Resolver die Zone als unsigniert behandeln. Er soll den Anbieter nicht mit bogus und SERVFAIL bestrafen, weil er selbst einen als verpflichtend geltenden Algorithmus abgeschaltet hat. Dasselbe gilt bei einem früher UNIVERSAL eingestuften, lokal nicht mehr unterstützten Algorithmus.

Eine DNS-Antwort kann beim Nutzer ankommen, obwohl dieser Resolver sie nicht mehr mit DNSSEC authentifiziert. Wer nur erfolgreiche Abfragen zählt, übersieht die Änderung. Monitoring muss secure, insecure und bogus trennen; das Änderungsprotokoll muss zeigen, wann und warum der Algorithmus deaktiviert wurde. Technische Unterstützung im Produkt und tatsächliche Erlaubnis in einer lokalen Konfiguration sind zwei verschiedene Tatsachen.

Die bisherige Vollständigkeitsregel schützt auch vor Angriffen. Wer alle verständlichen Signaturen entfernt und nur unbekannte übrig lässt, darf eine sichere Antwort nicht stillschweigend in eine unsichere verwandeln. Der Entwurf setzt deshalb auf die Kategorien UNIVERSAL und FORMERLY-UNIVERSAL. Ein Resolver muss sich merken, welche Algorithmen jemals UNIVERSAL waren, auch nach einer lokalen Abschaltung. Ein Fehler in dieser Erinnerung verändert seine Sicherheitsentscheidung.

Die Fassung 00 vom 31. Oktober 2026 ist ein frühes Arbeitsgruppendokument. Sie zählt keine betroffenen Resolver und belegt keinen konkreten Ausfall. Für die Einführung braucht ein Betreiber eine Matrix seiner tatsächlichen Validatoren: Was geschieht mit den Signatur-Teilmengen verschiedener Anbieter, und was bei lokal deaktivierter 8 oder 13? Ein Häkchen bei „DNSSEC unterstützt“ genügt dafür nicht.

Die Signierer bekämen Freiheit, redundante Arbeit zu lassen. Resolver-Administratoren behielten ihre Freiheit zur lokalen Sperre, müssten aber die dadurch verlorene Authentifizierung benennen. Das ist ein ehrlicherer Vertrag als eine erfolgreiche Antwort, die sich still als geprüfte ausgibt.

IETF-Entwurf · RFC 4035 · RFC 6840 · RFC 8901 · IANA-Register