Die RFC-Nummern sind fünfstellig geworden, und eine der ersten macht die automatische DNSSEC-Verwaltung zur empfohlenen Praxis

Der erste fünfstellige RFC erschien am 15. Juni 2026: RFC 10008, "The HTTP QUERY Method", ein Proposed Standard, der eine neue HTTP-Methode für sichere und idempotente Anfragen mit Inhalt im Request-Body definiert. Am 17. Juli folgte RFC 10002, "Certificate Management over CMS (CMC)", der die RFCs 5272 und 6402 ablöst.

Dass die höhere Nummer zuerst erschien, ist kein Fehler. RFC-Nummern werden vor der endgültigen Veröffentlichung vergeben. Dokumente verbleiben unterschiedlich lange im redaktionellen Verfahren, und normativ voneinander abhängige Dokumente werden teilweise gemeinsam in sogenannten Clustern bearbeitet, sodass eines auf das andere wartet. Die Veröffentlichungsreihenfolge entspricht deshalb nicht zwingend der Nummernfolge.

RFCs sind die Dokumentenreihe, in der die technischen Grundlagen des Internets festgehalten werden. Sie beginnt 1969 und wird vom RFC Editor herausgegeben. Ein großer Teil der technischen Standards entsteht in den Arbeitsgruppen der Internet Engineering Task Force; daneben veröffentlicht die Reihe Dokumente weiterer Publikationsströme, etwa des Internet Architecture Boards, der Internet Research Task Force und des Independent Submission Editors. Nicht jedes Dokument darin ist ein Standard, die Reihe umfasst ebenso informelle Beschreibungen, experimentelle Verfahren und Empfehlungen für den Betrieb. Der veröffentlichte Text wird nachträglich nicht mehr revidiert. Fehler werden über Errata dokumentiert, inhaltliche Weiterentwicklung erfolgt durch neue Dokumente, die das Bestehende aktualisieren oder ersetzen, und auch deshalb wächst die Zahl beständig.

Die Nummer, die es nicht geben wird

Über Jahre hinweg waren RFC-Nummern, die mit 00 enden, für Momentaufnahmen der offiziellen Internetprotokollstandards reserviert. Die Praxis begann laut RFC 7101 mit RFC 2200 im Juni 1997, ein Vorläufer war RFC 1280 aus dem März 1992. Das letzte dieser Dokumente war RFC 5000 im Mai 2008. Mit RFC 7101 beendete der RFC Editor die Praxis im Dezember 2013 formell, weil eine fortlaufend aktualisierte Online-Liste die Snapshots überflüssig machte. Seit RFC 7100 standen die runden Nummern wieder für gewöhnliche Zuweisungen zur Verfügung.

Für RFC 10000 kam es trotzdem anders. Das RFC Production Center teilte am 14. März 2026 mit, die Nummer nicht herauszugeben. Ein Testdokument werde nicht benötigt, weil für das neue Warteschlangensystem eine eigene Testumgebung existiere und für einen Aprilscherz-RFC die neue Infrastruktur nicht rechtzeitig einsatzbereit sei. Geplant ist stattdessen eine Rückschau zum sechzigsten Jahrestag der Reihe im Jahr 2029.

Damit erhält die Nummer 10000 ausgerechnet dadurch einen Sonderstatus, dass sie kein Dokument bezeichnen wird. Anders als RFC 1000 oder RFC 5000 steht sie nicht für einen Meilenstein, sondern für eine Lücke.

Die Meldung für die Branche

Am 23. Juli 2026 ist RFC 10026 erschienen, "Operational Recommendations for DNSSEC Delegation Signer (DS) Automation", verfasst von Steve Sheng und Peter Thomassen. Er trägt den Status Best Current Practice (BCP) und die Nummer BCP 246.

Das Dokument führt kein neues Protokoll ein und ersetzt keinen bestehenden Standard. Es beschreibt, wie Registries und Registrare die automatische Übernahme von DS-Parametern betreiben sollten, und gliedert sich in vier Themenbereiche: Annahme und sichere Verarbeitung von CDS- und CDNSKEY-Einträgen, Berichterstattung und Transparenz, das Zusammenspiel mit Registrar- und Registry-Sperren sowie den Umgang mit mehreren gleichzeitig beteiligten Automatisierungsstellen.

Vor allem verbindlich formuliert sind die Prüfungen vor einer Übernahme. Wer DS-Daten automatisch verarbeitet, muss die Übereinstimmung zwischen veröffentlichten CDS- und CDNSKEY-Einträgen sicherstellen und prüfen, dass der resultierende DS-Satz die Validierung weiterhin zulässt, und dies über alle autoritativen Nameserver einer Zone hinweg tun. Scheitert eine dieser Prüfungen, unterbleibt die Aktualisierung. Ebenfalls verbindlich: Ein Registrar- oder Registry-Lock allein ist kein Grund, die DS-Automatisierung auszusetzen, denn solche Sperren richten sich gegen Änderungen durch Dritte, nicht gegen die Registry selbst. Und beide Seiten müssen daneben einen manuellen Pfad für die DS-Pflege freihalten.

Als Empfehlungen formuliert sind die übrigen Punkte. Beim Veröffentlichen eines neuen DS-Satzes soll dessen TTL vorübergehend auf fünf bis fünfzehn Minuten gesenkt werden, damit sich eine fehlerhafte Änderung schnell zurücknehmen lässt; darunter drohen unnötige Anfragen, darüber leidet die Wiederherstellung. Danach gilt wieder der reguläre Wert. Veröffentlicht werden sollen beide Record-Typen, CDNSKEY und CDS, es sei denn, die Präferenz der übergeordneten Stelle ist bekannt. Und bei den Meldungen unterscheidet der RFC genau: Fehlgeschlagene Aktualisierungen gehen zuerst an den DNS-Betreiber der Kindzone und den technischen Kontakt, der Registrant wird erst einbezogen, wenn das Problem länger anhält, im Beispiel drei Tage.

Ein BCP beschreibt die von der IETF konsentierte gute Praxis. Wer DS-Automatisierung anbietet, ohne die vorgeschriebenen Prüfungen durchzuführen, setzt BCP 246 insoweit nicht konform um. Bei den als Empfehlungen formulierten Berichts- und Benachrichtigungsmechanismen kann eine Abweichung vertretbar sein, sollte sich jedoch an den konkreten Betriebsumständen begründen lassen.

Die Linie, in der das Dokument steht

Die automatisierte DS-Verwaltung ist kein neues Thema, sondern ein Vorhaben, das sich seit zwölf Jahren hinzieht. RFC 7344 führte 2014 die Record-Typen CDS und CDNSKEY ein, mit denen eine Kindzone der Elternzone mitteilen kann, welche Schlüsselinformationen dort hinterlegt werden sollen. RFC 8078 ergänzte 2017 das Löschsignal, mit dem sich DNSSEC für eine Delegation wieder abschalten lässt. RFC 9615 beschrieb 2024 ein Verfahren, mit dem sich die Erstsignierung kryptografisch absichern lässt, statt sich auf Wartefristen zu verlassen. RFC 10026 baut darauf auf und beschreibt, wie man das Ganze im Zusammenspiel von Registry, Registrar und Registrant betreibt.

Damit reiht er sich in eine überschaubare Zahl von Dokumenten ein, in denen der Betrieb dieser Branche tatsächlich beschrieben wird. Das Domain Name System selbst beruht bis heute auf den RFCs 1034 und 1035 von 1987. DNSSEC wurde 2005 in seiner heutigen Form durch die RFCs 4033 bis 4035 festgelegt. Die Kommunikation zwischen Registrar und Registry regelt seit 2009 das Extensible Provisioning Protocol nach RFC 5730, ergänzt um zahlreiche Erweiterungen, darunter RFC 5910 für DNSSEC-Daten aus dem Jahr 2010. Neuere EPP- und RDAP-Erweiterungen entstehen vor allem in der IETF-Arbeitsgruppe Registration Protocols Extensions, etwa in den RFCs 8807, 9154 und 9167. Der Zugriff auf Registrierungsdaten erfolgt seit 2015 über RDAP gemäß RFC 7480 und den zugehörigen Dokumenten.

Zehntausend Nummern klingen nach viel. Wer die für eine moderne Registry relevanten Spezifikationen zu DNS, DNSSEC, EPP und RDAP samt Erweiterungen zusammenzählt, kommt je nach Funktionsumfang schnell auf mehrere Dutzend Dokumente. Gemessen am Gesamtbestand ist das wenig. Gemessen daran, was davon täglich funktionieren muss, ist es reichlich.

Quellen

• RFC 10008: The HTTP QUERY Method, 15. Juni 2026
• RFC 10002: Certificate Management over CMS (CMC), 17. Juli 2026
• RFC 10026: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation, BCP 246
• RFC Production Center zur Nummer 10000, Nachricht vom 14. März 2026
• RFC 7101: List of Internet Official Protocol Standards, Replaced by a Web Page, Dezember 2013
• RFC Editor: Erläuterung zu Dokumentenclustern
• RFC 7344: Automating DNSSEC Delegation Trust Maintenance, September 2014
• RFC 8078: Managing DS Records from the Parent via CDS/CDNSKEY, März 2017
• RFC 9615: Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator, Juli 2024
• IETF: Veröffentlichte Dokumente der Arbeitsgruppe Registration Protocols Extensions (REGEXT)