Zusammenfassung

  • RFC 9083 definiert delegationSigned als wahr, wenn im Parent DS-Einträge vorhanden sind. zoneSigned sowie DS- oder Schlüsseldaten sind getrennte Bestandteile des RDAP-Objekts secureDNS.
  • Das Feld ist Registrierungsbeleg, kein Live-Validierungsergebnis. Eine belastbare DNSSEC-Aussage benötigt außerdem den aktuellen Parent-DS, DNSKEY und RRSIG der Child-Zone, Erreichbarkeit, zeitliche Gültigkeit und das Ergebnis eines benannten Validators.

Ein präziser Wert mit engem Geltungsbereich

Die untersuchte LACNIC-Antwort für 84.7.200.in-addr.arpa zeigt eindeutig, was sie enthält. Das Objekt gehört zur Klasse domain. Es nennt drei Nameserver und ein secureDNS-Objekt, in dem zoneSigned und delegationSigned beide false sind; dsData ist leer.

Das ist ein nützlicher Beleg für den Datensatz, den LACNIC zum Beobachtungszeitpunkt zurückgegeben hat. Daraus folgt weder der Zustand aller Reverse-Zonen in der LACNIC-Region noch der aktuelle Betrieb der genannten Server. Die Antwort enthält keine Resolver-Ablaufspur und keine DNS-Pakete, aus denen sich eine Validierung rekonstruieren ließe.

Parent-DS ist nur ein Glied der Kette

RFC 9083 trennt die Bedeutungen bewusst. zoneSigned beschreibt, ob die Zone signiert ist. delegationSigned beschreibt, ob DS-Einträge im Parent vorhanden sind. dsData kann Key-Tag, Algorithmus, Digest und Digest-Typ enthalten; keyData kann DNSKEY-Material tragen.

Diese Felder beschreiben Registrierungsdaten. DNSSEC-Validierung ist eine Operation über eine Kette aktueller DNS-Antworten zu einem bestimmten Zeitpunkt. Ein Validator muss den Parent-DS und die DNSKEY sowie signierte Datensätze der Child-Zone abrufen, Digests und Algorithmen vergleichen, Signaturen und Zeitfenster prüfen und Erreichbarkeits- oder Antwortfehler behandeln. Ein RDAP-Wert führt diese Schritte nicht heimlich aus.

Wahr und falsch verlangen gleich genaue Sprache

Ist delegationSigned wahr, lautet die belegte Aussage: Die RDAP-Darstellung meldet DS-Einträge im Parent. Sie beweist nicht, dass die Child-Zone den passenden DNSKEY veröffentlicht, die Signaturen aktuell gültig sind, die Kette einen Trust Anchor erreicht oder ein bestimmter Resolver erfolgreich validiert.

Ist der Wert falsch, meldet die RDAP-Darstellung gemäß Felddefinition keinen Parent-DS. Sie erklärt weder den Grund noch schließt sie eine laufende Änderung aus oder garantiert denselben Befund bei einer späteren Abfrage. URL, Antwortbytes und Zeitpunkt müssen gemeinsam erhalten bleiben.

Zwei Beweisflächen getrennt dokumentieren

Die Registrierungsfläche sollte die genaue RDAP-Domain-URL, ldhName, Nameserver, secureDNS-Werte, DS- oder Schlüssel-Arrays, Antwort-Hash und Abrufzeit festhalten. Die Betriebsfläche sollte getrennt Parent- und Child-Abfragen, Serveradressen, Antwortcodes, Authoritative Flags, DNSKEY, DS, RRSIG, Validatorausgabe und Zeitkontext speichern.

Erst der Vergleich beider Flächen erlaubt eine Aussage über die gegenwärtige Validierung. Selbst dann gilt das Ergebnis nur für den angegebenen Beobachtungspunkt und Zeitpunkt. Eine funktionierende kryptografische Kette belegt weder Eigentum noch vertragliche Befugnis oder Kontrolle der Hosts.

Quellen