Zusammenfassung

  • ARIN bezeichnet Digest-Typ 3 in der öffentlichen Delegation-Key-Anleitung als MD5 und nennt eine Länge von 32. IANA weist DS-Digest-Typ 3 dagegen GOST R34.11-94 zu; der Eintrag ist inzwischen als veraltet markiert.
  • Die Längenspalte nennt keine Einheit. Der 256-Bit-Digest von GOST umfasst 32 Oktette oder 64 Hexadezimalzeichen. Daraus lässt sich keine tatsächlich durchgesetzte Eingabegrenze der API ableiten.
  • Alle vier aktuellen Empfehlungsspalten bei IANA tragen für Typ 3 MUST NOT, entsprechend RFC 9906. Den Namen zu berichtigen würde die Verwendung nicht wieder empfehlen. API, Zonen, Signaturprogramme und Resolver wurden nicht getestet.

Eine falsche Zuordnung, nicht bloß ein anderer Name

Wer eine kurze Feldtabelle liest, erwartet meist keine Grundsatzfrage. Doch bei ARINs öffentlicher Reg-RWS-Anleitung stellt sie sich unmittelbar: Kann eine Dienstbeschreibung einer registrierten DS-Nummer eine andere kryptografische Funktion zuweisen? Die Antwort der maßgeblichen Registrierung ist eindeutig. Nummer 3 bezeichnet GOST R34.11-94 und nicht MD5.

Im Abschnitt Delegation Key steht für Digest-Typ 3 der Name MD5, daneben die Länge 32. IANAs Register der DS-Digest-Typen nennt GOST und markiert den Eintrag als veraltet. Die ursprüngliche Zuweisung in RFC 5933 verwendet ebenfalls GOST. Das sind keine unterschiedlichen Schreibweisen derselben Funktion und keine Frage nach einer verständlicheren Übersetzung.

Der Befund bezieht sich auf öffentlich zugängliche Seiten, die am 14. September 2026 erfasst wurden. Damit ist der Beobachtungszeitpunkt bekannt. Wann die betreffende Zeile eingeführt oder geändert wurde und wie lange die Abweichung besteht, wurde nicht festgestellt. Aus neueren Algorithmen an anderer Stelle lässt sich keine vollständige Überarbeitungsgeschichte dieser Tabelle rekonstruieren.

Ein DS-Eintrag enthält eine Digest-Typnummer zusammen mit Digest-Daten. Die Nummer bestimmt, welche Funktion die Daten darstellen sollen. Ein lesbarer Name hilft Menschen bei der Auswahl oder Prüfung, schafft jedoch keine private Bedeutung der Protokollnummer für einen einzelnen Anbieter. Das Feld ist nicht nur eine Bezeichnung in einer Benutzeroberfläche.

Daraus folgt ein bedingtes Risiko: Würde ein Client-Autor nach dem MD5-Namen die Daten berechnen und sie mit Typ 3 verbinden, könnte diese Kombination der registrierten Bedeutung widersprechen. Es wurde kein Client entdeckt, der so handelt, und keine entsprechende Übermittlung oder DNS-Antwort geprüft. Eine mögliche Fehlerkette ist nicht mit einer beobachteten Fehlerkette gleichzusetzen.

Was hier nicht ausgeführt wurde

Für diesen Artikel wurde weder ein privates ARIN-Konto geöffnet noch ein API-Schlüssel eingesetzt. Es wurden keine DS-Daten erzeugt, hochgeladen, gelöscht oder verändert. Der öffentliche Text zeigt nicht, was die laufende API annimmt, zurückweist, speichert oder veröffentlicht. Die Behauptung, ARIN verwende tatsächlich MD5 unter Typ 3, würde deshalb über den vorhandenen Beleg hinausgehen.

Diese Grenze schmälert die dokumentarische Aussage nicht. Eine Anleitung soll den Nutzer gerade vor falschen Zuordnungen bewahren. Sie schützt aber die Trennung zwischen Beschreibung und Ausführung. Ein falsch benanntes Feld ist ein konkreter Gegenstand für eine Berichtigung; ein Laufzeitfehler verlangt zusätzlich eine passende Beobachtung unter definierten Bedingungen.

Auch der Zustand einer bestimmten Delegation bleibt offen. Das öffentlich erklärte Format verrät nicht, welche Daten ein einzelner Betreiber eingegeben hat, wie sein Client sie berechnet oder welche anderen Systeme sie verarbeitet haben. Wer aus der Tabelle eine bereits unsichere, fehlerhafte oder unerreichbare Zone ableitet, überspringt mehrere Betriebsgrenzen ohne Belege.

Zwei Nummernräume im selben Eingabeformat

Delegation Key ist in ARINs Referenz Teil einer Delegation Payload. Zu seinen Feldern gehören algorithm und digestType. Das erste bezieht sich auf den DNSKEY-Algorithmus, das zweite auf die Digest-Funktion des DS-Eintrags. Beide sind Zahlenfelder, gehören aber nicht zur selben Zuweisungsliste. Ihre Nähe im Format macht die Zahlen nicht austauschbar.

Der veröffentlichte Algorithmuskatalog führt unter anderem 5, 7, 8, 10, 13, 14, 15 und 16 mit Namen aus den RSA-, ECDSA- und EdDSA-Familien. Die Digest-Tabelle ordnet 1 SHA1, 2 SHA256, 3 MD5 und 4 SHA384 zu. Die Längen lauten 40, 64, 32 und 96. Dies ist eine Wiedergabe der Dokumentation und keine überprüfte Liste akzeptierter Algorithmen in Produktion.

ARIN erläutert, dass Algorithmus- und Digest-Namen aus den eingegebenen Zahlen bestimmt werden und übermittelte Namen verworfen werden. Nach dieser beschriebenen Schnittstelle könnte ein anders eingegebener Name die Bedeutung der Zahl nicht überschreiben. Gerade deshalb muss die Referenz für den Leser den richtigen Namen zum gewählten Zahlenfeld nennen.

Die Beschreibung beweist nicht, welchen Namen der Dienst heute zurückgibt, welche Prüfungen zuerst laufen oder wie eine konkrete Fehlermeldung lautet. Sie zeigt auch nicht die gespeicherte Darstellung. Für solche Aussagen wäre ein datierter Ausführungsnachweis mit klaren Eingaben und passenden Berechtigungen nötig. Dieser Nachweis liegt hier nicht vor.

RFC 5933 verdeutlicht die Trennung: Der DNSKEY-Signaturalgorithmus ECC-GOST erhielt die Nummer 12; der DS-Digest GOST R34.11-94 erhielt 3. DS-Digest-Typ 3 ist somit nicht DNSKEY-Algorithmus 3. Er ist ebenso wenig das DNSKEY-Protokollfeld mit dem Wert 3 oder ein Schlüsselkennzeichen, in dem diese Zahl vorkommt. Erst der benannte Nummernraum liefert den Sinn.

Die Digest-Eingabe ist ebenfalls definiert

RFC 4034 beschreibt den DS-Digest-Typ als Kennung des Algorithmus, mit dem der Digest erstellt wird. Die Eingabe besteht aus dem kanonischen DNSKEY-Eigentümernamen, gefolgt von den DNSKEY-Datensatzdaten. Dazu gehören Flags, Protokoll, Algorithmus und öffentlicher Schlüssel. Eine beliebige sichtbare Zeichenfolge des öffentlichen Schlüssels allein beschreibt den Eingang des Verfahrens nicht ausreichend.

Funktionswahl, Eingabeaufbau und Ergebnisdarstellung sind deshalb getrennte Erklärungsaufgaben. Ein korrigierter Name bestätigt nicht automatisch den richtigen Aufbau der Daten. Ein richtiger Aufbau erklärt nicht automatisch die Einheit einer Längenangabe. Eine gute Referenz verringert diese Mehrdeutigkeiten, statt den Nutzer aus Nachbarfeldern auf nicht genannte Regeln schließen zu lassen.

IANA und die ursprüngliche RFC-Zuweisung stimmen beim GOST-Digest überein. Seine heutige Einstufung als veraltet gibt die Nummer nicht für MD5 frei. Ein Register kann den historischen Sinn eines Identifikators erhalten und gleichzeitig seine neue Verwendung ausschließen. Erkennen und empfehlen sind unterschiedliche Tätigkeiten, die nicht durch denselben kurzen Namen erledigt werden.

Der Befund lautet nicht, MD5 komme in sämtlichen DNS-nahen Techniken oder allen anderen Zusammenhängen niemals vor. Das wäre eine andere und breitere Untersuchung. Hier geht es allein darum, welche Funktion DS-Digest-Typ 3 bezeichnet. Diese Begrenzung macht die Berichtigung nicht schwächer, sondern einfacher nachprüfbar.

Eine Länge braucht eine Einheit

Die Namensabweichung lässt sich unmittelbar vergleichen. Anders liegt es bei Digest Length. ARIN nennt für Typ 3 den Wert 32, ohne die Einheit der Spalte anzugeben. Die benachbarten Werte 40, 64 und 96 passen zu Hexadezimalzeichen. Das liefert eine plausible Lesart, jedoch keinen Beleg für eine durchgesetzte Zeichenbegrenzung der API.

RFC 5933 definiert den GOST-Digest mit 256 Bit. Acht Bit ergeben ein Oktett, also 32 Oktette. Jedes Oktett benötigt in Hexadezimaldarstellung zwei Zeichen; daraus werden 64 Zeichen. RFC 4034 beschreibt den DS-Digest als Hexadezimaltext ohne Bedeutung der Groß- oder Kleinschreibung und lässt Leerraum zu. Datenmenge und Länge eines formatierten Textes sind nicht dieselbe Messung.

Falls ARIN Hexadezimalzeichen meint, beschreibt 32 nicht die GOST-Länge des registrierten Typs 3. Falls Oktette gemeint sind, stimmt 32 für GOST, während die Nachbarzeilen eine andere Erklärung brauchen. Die Seite entscheidet diese Frage nicht. Eine brauchbare Berichtigung würde die Einheit und den Umgang mit Formatierungsleerraum ausdrücklich nennen.

Aus der Spalte folgt weder, dass ein Upload mit 64 Zeichen scheitert, noch dass eine Eingabe mit 32 Zeichen gelingt. Dekodierung, Normalisierung, Prüfungsreihenfolge, Fehlerausgabe und Speicherung wurden nicht erprobt. Diese Punkte könnten getrennt untersucht werden. Sie dürfen nicht als erledigt gelten, nur weil eine plausible Erklärung für die Zahlenfolge vorliegt.

Eine Dokumentation könnte einen falschen Namen und eine unklare Einheit enthalten, ohne dass die Implementierung beide übernimmt. Andere Kombinationen sind denkbar. Die vorhandenen Belege wählen keine davon aus. Getrennte Feststellungen helfen, weitere Arbeit auf tatsächlich offene Fragen zu richten, statt die Tabellenabweichung erneut zu beweisen und damit eine Ausführungsaussage zu ersetzen.

Der richtige historische Name bleibt ausgemustert

MD5 durch GOST zu ersetzen wäre eine Korrektur des Identifikators. Es wäre keine Empfehlung, Typ 3 für eine neue Delegation einzusetzen. RFC 9906 wurde im November 2025 veröffentlicht und nimmt ECC-GOST sowie GOST R34.11-94 aus der DNSSEC-Verwendung. Die aktuelle IANA-Zeile trägt dementsprechend in allen vier Empfehlungsspalten MUST NOT.

Gemeint sind Verwendung für Delegation, Verwendung für Validierung, Implementierung für Delegation und Implementierung für Validierung. Die frühere Aussage zur optionalen Implementierung in RFC 5933 erklärt einen historischen Stand. Sie setzt die spätere Ausmusterung nicht außer Kraft. Ein damaliges MAY als heutige Validierungserlaubnis anzuführen würde bei der Namensreparatur einen zweiten, zeitlichen Fehler erzeugen.

Ein Katalog kann Identifikatoren erläutern, die beim Prüfen, Ändern oder Entfernen älterer Konfigurationen auftauchen. Das ist keine Freigabe für die Erzeugung neuer Daten. Ein bestimmter Kompatibilitäts- oder Entfernungspfad bei ARIN wurde hier nicht getestet. Die Unterscheidung betrifft die Rolle einer Beschreibung und bestätigt keine Produktfunktion.

RFC 9906 trennt zudem eine nur auf ausgemusterten Verfahren beruhende Authentifizierung von einer festgestellten ungültigen Signatur. Gibt es keinen anderen akzeptablen Authentifizierungspfad, lautet die vorgesehene Behandlung insecure. Das ist nicht die weitere Validierung mit den zurückgezogenen Verfahren, um die Kette als bogus zu klassifizieren. Keiner der Begriffe bedeutet schlicht Unerreichbarkeit; der Zustand einer ARIN-Zone wurde nicht gemessen.

Für diesen Artikel ist die Ausmusterung eine Grenze der vorgeschlagenen Berichtigung, nicht das Hauptthema. Untersucht wird ein konkreter Eingabefeldname, der der Zuweisung widerspricht. Die aktuelle Empfehlung verhindert, dass ein richtiger historischer Name als Handlungsanweisung für eine neue Installation erscheint. Identifikation und Betriebsentscheidung bleiben zwei Fragen.

Elternseitige Daten sind nicht der ganze DNS-Betrieb

ARINs Anleitung für Reverse DNS liefert den Betriebskontext. Nachdem die Reverse-Zone abgesichert ist, kann ein Betreiber dem Parent DS-Daten signalisieren und sie pro Delegation über ARIN Online oder den RESTful-Provisionierungsdienst verwalten. Der besprochene Datentyp liegt damit an einer realen Grenze zwischen kindseitigem Schlüsselmaterial und seiner elternseitigen Beschreibung.

DS beim Parent zu verwalten ist nicht dasselbe wie die Child-Zone zu signieren, ihre DNSKEY-Datensätze zu veröffentlichen oder sämtliche Resolver zu betreiben. Ein irreführender Name kann das lokale Verständnis beeinflussen, ohne bis zu einer öffentlichen DNS-Antwort alle Grenzen zu überschreiten. Die Seiten enthalten keine lückenlose Geschichte einzelner Übermittlungen und ihrer Ergebnisse.

Eine angemessene Forderung ist daher eng: Namen und Zuweisung angleichen, Längeneinheit angeben, historischen Status und heutige Behandlung trennen. Wenn die tatsächliche Annahme umstritten ist, braucht sie einen eigenen datierten und reproduzierbaren Beleg. Die Untersuchung empfiehlt weder vorsorgliche DS-Löschung noch einen ungeprüften Schlüsselwechsel und liefert kein sicheres Wechselverfahren.

Quellen

  • ARINs Reg-RWS-Formatreferenz: Delegation-Key-Felder, beschriebene Namensbehandlung sowie Typen und Längen.
  • IANAs Register der DS-Digest-Typen: Zuweisung von Typ 3 und aktuelle Empfehlungen.
  • RFC 5933: getrennte GOST-Nummern und 256-Bit-Digest; die ursprünglichen Verwendungsempfehlungen sind historisch.
  • RFC 9906: Ausmusterung im November 2025 und vorgesehene Validierungsbehandlung.
  • ARINs Reverse-DNS-Anleitung: Kontext der Parent-DS-Verwaltung, kein Zustandsnachweis einer einzelnen Zone.
  • RFC 4034: DS-Semantik, Digest-Eingabe und Hexadezimaldarstellung, keine aktuelle Auswahlberatung für Algorithmen.