Zusammenfassung

  • Am 1. September 2026 sahen die DNSOP-Vorsitzenden klare Unterstützung für die Annahme von draft-huque-dnsop-multi-alg-rules-08, verwiesen die Komplexitätsbedenken aber ausdrücklich in die weitere Arbeitsgruppenarbeit.
  • Der Entwurf würde bei bestimmten Kombinationen erlauben, nur eine Signatur eines als UNIVERSAL eingestuften Algorithmus auszuliefern.
  • Dieselbe Einstufung würde bestimmen, wie ein Validator einen lokal abgeschalteten Algorithmus behandelt. Sie wäre damit ausführbare Regel und kein beschreibendes Etikett.
  • Daniel Kade schlägt für jede spätere Statusänderung einen eigenen, datierten Einsatznachweis vor. Die Dokumentannahme wählt die Aufgabe; eine Standards Action müsste die Registeränderung ermächtigen.

Der Annahmebeschluss enthält seinen Vorbehalt

Die Abschlussnachricht verbindet zwei Feststellungen. Für die Annahme des Dokuments gebe es klare Unterstützung. Bedenken wegen der Komplexität des vorgeschlagenen Mechanismus seien in der weiteren Arbeit zu behandeln. Wer nur den ersten Satz übernimmt, erweitert den Beschluss über seinen dokumentierten Umfang hinaus.

Der Aufruf lief vom 13. bis 31. August. Im aktuellen Datatracker ist das Active Internet-Draft nun bei DNSOP als Adopted by a WG verzeichnet. Der IESG-Status lautet weiterhin I-D Exists; weder Document Shepherd noch verantwortlicher Area Director oder Telechat-Termin sind eingetragen. Revision 08 steht unter Änderungskontrolle der Arbeitsgruppe. Sie ist weder RFC noch genehmigte IETF-Regel.

Eine Annahme entscheidet, dass die Arbeitsgruppe Problem und Textgrundlage bearbeitet. Sie soll Änderungen ermöglichen, nicht die eingereichte Fassung einfrieren. Genau diese Offenheit haben die Vorsitzenden hier sichtbar gelassen.

Warum die geltende Regel Vollständigkeit verlangt

RFC 4035 verlangt für jedes RRset mindestens eine RRSIG mit einem DNSKEY jedes Algorithmus im Apex-DNSKEY-Satz. Der Apex-DNSKEY-Satz muss außerdem mit jedem im übergeordneten DS-Satz auftauchenden Algorithmus signiert sein. RFC 6840 formuliert die Vollständigkeitspflicht für Signierer erneut, während Validatoren jeden gültigen Pfad akzeptieren sollen.

Der Signierer kennt die Fähigkeiten aller Validatoren nicht. Der vollständige Satz verhindert, dass das Entfernen einer unterstützten Signatur wie eine erlaubte Auslassung wirkt. Dafür entsteht Koordinationslast. RFC 8901 setzt bei mehreren Signierern einen gemeinsamen Algorithmus voraus. Zwei DNS-Anbieter mit disjunkten Algorithmusmengen können nicht einfach ihre Schlüssel nebeneinanderstellen und unter den bestehenden Regeln störungsfrei wechseln.

Revision 08 will diese Bindung lockern. Sie nennt dauerhaften Multi-Signer-Betrieb, Anbieterwechsel, getrennte KSK- und ZSK-Umstellungen, die Vorabveröffentlichung eines Trust Anchors und den Versuch neuer Algorithmen bei nur einem Anbieter. DNSOP hat diese Problemfamilie angenommen. Der genaue Lösungsweg bleibt veränderbar.

Das Registerwort würde Pakete und Entscheidungen verändern

Der Entwurf schlägt im IANA-Register die Spalte Validation support status vor. Zulässig wären UNIVERSAL, FORMERLY-UNIVERSAL oder ein leeres Feld. Anfangs sollen die Algorithmen 8 und 13 UNIVERSAL sein. Das heutige IANA-Register der DNSSEC-Algorithmen kennt diese Spalte nicht; es führt 8 und 13 als MUST für die Validierungsimplementierung.

Enthält ein DS- oder Trust-Anchor-Satz mindestens einen UNIVERSAL-Algorithmus und keinen FORMERLY-UNIVERSAL, müsste der Signierer nur mit einem universellen Algorithmus signieren. Signaturen weiterer angekündigter Algorithmen wären optional. In allen anderen Kombinationen bliebe der vollständige Satz Pflicht.

Auch der Validator erhielte eine neue Verzweigung. Unterstützt er einen angekündigten UNIVERSAL- oder früher universellen Algorithmus nicht, soll er die Zone als unsigniert behandeln, selbst wenn er einen anderen angekündigten Algorithmus unterstützt. Sonst akzeptiert er jeden gültigen Pfad. Bei lokaler Abschaltung muss er sich also an den früheren globalen Status erinnern.

Das Label ist deshalb weder Auszeichnung noch grobe Verbreitungsangabe. Es entscheidet, was ein Signierer weglassen darf und ob eine konkrete Unverträglichkeit als Insecure oder Bogus endet. Eine verfrühte oder veraltete Einstufung wird damit zu Verfügbarkeits- und Sicherheitsverhalten.

RFC 9904 trennt bereits Einsatzempfehlung und Implementierungsanforderung und macht die IANA-Register zur kanonischen Quelle. Werte sollen sich mit der Kryptografie und Verbreitung ändern; Ausphasung erfolgt normalerweise schrittweise. Die neue Spalte hätte jedoch eine andere Wirkung. Sie braucht eine eigene Begründung, auch wenn sie neben vertrauten Feldern steht.

Zustimmung zur Bearbeitung ließ Designwiderspruch bestehen

Im öffentlichen Thread wird der Vorbehalt konkret. Mark Andrews widersprach dem Entwurf und seinem Rückschluss auf weltweite Validatorunterstützung. Paul Hoffman befürwortete die Lockerung der bisherigen Vollständigkeitspflicht, lehnte aber die derzeitige Lebenszyklus-Taxonomie ab. Paul Wouters unterstützte die Annahme und verlangte erhebliche Vereinfachung.

Das sind Einzelbeiträge, keine Stimmen, aus denen dieser Artikel einen neuen Konsens berechnen könnte. Sie zeigen, welche Fragen die Vorsitzenden nicht geschlossen haben: Generalisierung, Lebenszyklusgedächtnis, alte Validatoren, lokale Präferenz und künftige Post-Quanten-Verfahren.

Der Entwurf benennt die zentrale Grenze selbst. Universelle Unterstützung lässt sich nicht auf Protokollebene feststellen. Die Gemeinschaft soll einen Algorithmus erst hochstufen, wenn die nicht unterstützende Validatorpopulation als vernachlässigbar gilt. Dafür fehlen ohne gesonderten Nachweis Stichprobe, Zeitpunkt und Entscheidungsschwelle.

Für jede Klassifikation ein eigener Nachweis

Jede spätere Standards Action sollte einen kompakten Beleg mitführen: Algorithmus und Registerversion, Messdatum, beobachtete Validatorgruppe, bekannte Ausschlüsse, alte Implementierungen und die Regel, nach der fehlende Unterstützung als vernachlässigbar galt.

Der Beleg sollte außerdem erwartete Secure-, Insecure- und Bogus-Ergebnisse repräsentativer Multi-Signer- und Anbieterwechselzustände enthalten, lokale Präferenzen einordnen, Abhängigkeiten nennen sowie Wirksamkeitsfenster und Verantwortliche für Notfallübergang oder Rücknahme festlegen. Resolveridentitäten und geschäftliche Flottendaten können geschützt bleiben. Die Reichweite einer globalen Interoperabilitätsaussage muss sichtbar sein.

Heng Lus Disziplin der minimalen gemeinsamen Schicht liefert den Maßstab: Gemeinsam klassifiziert wird nur, was unabhängige Betreiber für Interoperabilität zwingend gemeinsam wissen müssen. Die Präferenz zwischen sonst zulässigen Algorithmen bleibt lokal, sofern eine spätere Standardentscheidung diese Grenze nicht ausdrücklich und begründet verändert.

DNSOP nahm das Problem und die Verantwortung für weitere Textarbeit an. Das mächtige Registerwort muss seine Autorität erst in den folgenden Stufen gewinnen. Ein getrennter Klassifikationsnachweis verhindert, dass Dokumentstatus vorzeitig zu Netzstatus wird.

Quellen