Zusammenfassung

  • RFC 9824 erlaubt für einen nicht existierenden Namen einen Header mit NOERROR, eine leere Answer Section und einen signierten NSEC- oder NSEC3-Beweis mit NXNAME. Die authentisierte Aussage steht im Body; der DNS-Header ist kryptografisch nicht geschützt.
  • Das optionale EDNS-Signal Compact Answers OK kann NXDOMAIN wiederherstellen, gilt aber Hop für Hop. Der Resolver muss die Fähigkeit mit dem gecachten Beweis verbinden und die Darstellung an den nächsten Fragenden anpassen.
  • Compact Answers verringern Beweismaterial und Online-Signierarbeit gegenüber anderen dynamischen Formen, verhindern aber aggressive negative Synthese. Validierung, Darstellung, Cache, Last und Anwendungseffekt brauchen getrennte Belege.

Leere Felder besitzen keine einheitliche Bedeutung

Die Eingangsszene ist konstruiert. Sie zeigt, weshalb Negation ohne benannten Zeugen gefährlich ist. Ein leerer Wert kann Ergebnis, Auslassung, Nichtbeobachtung oder echte Abwesenheit bedeuten. Erst ein prüfbarer Beweis begrenzt die Interpretation.

RFC 9824 spezifiziert Compact Denial of Existence in DNSSEC. Gewöhnliche authentisierte Negation muss zeigen, dass weder der genaue Name existiert noch ein Wildcard die Antwort erzeugen konnte. Beim Online Signing können dafür bis zu zwei signierte NSEC- oder drei signierte NSEC3-Records nötig sein.

Compact Denial ändert die Aussageform. Für einen nicht existierenden Namen ohne Wildcard-Treffer erzeugt der autoritative Server eine NODATA-artige Antwort: RCODE NOERROR, leere Answer Section und einen einzigen, zum QNAME passenden, minimal abdeckenden signierten NSEC- oder NSEC3-Record. Für den Beweis wird behauptet, der Name existiere, besitze aber den abgefragten RR-Typ nicht.

Die RFC-Editor-Seite und der Datatracker führen RFC 9824 als Proposed Standard vom September 2025, der RFC 4034 und 4035 aktualisiert. Historie, Referenzen und Referenced-by-Daten dokumentieren den öffentlichen Standardisierungskontext, nicht die Implementierung eines benannten Systems.

NXNAME trennt Nicht-Existenz vom Empty Non-Terminal

Eine leere Answer Section beweist wenig. Ein existierender Name kann den gefragten Typ nicht besitzen. Ein Empty Non-Terminal existiert durch Nachfahren, obwohl es selbst keine RRsets hat. Beide können karge Bitmaps liefern.

RFC 9824 definiert deshalb den synthetischen Meta-TYPE NXNAME mit Wert 128. Bei NSEC enthält der Bitmap für einen nicht existierenden Namen RRSIG, NSEC und NXNAME. Bei NSEC3 ist NXNAME der einzige Eintrag. Ein Empty Non-Terminal trägt ihn nicht. Die Schlussfolgerung entsteht nicht mehr aus bloßer Leere, sondern aus signiertem Material.

Die IANA DNS Parameters registrieren NXNAME, das CO-Flag und EDE 30. Registrierung koordiniert Bezeichner; sie weist weder Aktivierung noch Validierung oder Wirkung nach.

NXNAME ist kein gewöhnlicher Zone Record. Er soll ausschließlich im NSEC/NSEC3-Bitmap eines Compact Answer für einen nicht existierenden Namen auftreten. Eine explizite NXNAME-QTYPE-Anfrage erhält FORMERR; optional kommt EDE 30 Invalid Query Type hinzu. Ein Resolver darf sie nicht weiterleiten und keine iterative Auflösung starten. RFC 8914 stellt den allgemeinen EDE-Rahmen bereit.

Der Header präsentiert, der Body belegt

RFC 9824 stellt klar, dass der DNS-Header nicht kryptografisch geschützt ist. Der RCODE kann nicht authentisiert werden; die signierten Daten im Body sind die stärkere Grundlage für eine Aussage über Nicht-Existenz.

Operativ bleibt der Header wichtig, weil Bibliotheken und Sicherheitswerkzeuge ihn konsumieren. Ein Werkzeug sieht NOERROR und meldet NODATA. Ein Validator prüft RRSIG und NXNAME und meldet Nicht-Existenz. Beide Beobachtungen gehören mit ihrem Messpunkt in den Beleg. Das bequemere Feld darf den stärkeren Zeugen nicht überschreiben.

RFC 4034 definiert NSEC, RRSIG und weitere DNSSEC Records. RFC 4035 regelt Verarbeitung und authentisierte Negation. RFC 9824 ergänzt die dynamische Compact-Ausnahme. RFC 9364 bietet den DNSSEC-Überblick, RFC 9499 die Terminologie. Kein Text macht aus einem nicht validierten Header einen signierten Fakt.

Ein Receipt verbindet Query Name und Type, DO/CO, empfangenen RCODE, NSEC/NSEC3-Form, NXNAME, öffentliche Algorithmus- und Key IDs, Validierung, Softwareversion, Zeit und Proof Fingerprint. Der private Schlüssel bleibt ausgeschlossen.

CO verleiht Darstellungsfähigkeit, nicht neue Wahrheit

RFC 9824 will NXDOMAIN nach Möglichkeit erhalten. Für DNSSEC-Antworten definiert es EDNS Compact Answers OK. Ein Resolver mit CO erklärt, dass er signiertes NXNAME zusammen mit einem zu NXDOMAIN restaurierten RCODE akzeptiert. Ein autoritativer Server mit beiden Funktionen kann CO und NXDOMAIN zurückgeben.

EDNS nach RFC 6891 ist Hop für Hop. Der Resolver muss empfangenes CO mit den Cache-Daten speichern. Setzt der nächste DNSSEC-Querier CO nicht, wird der RCODE einer NXNAME-Antwort auf NOERROR zurückgesetzt.

Der signierte Beweis bleibt identisch. Die lokale Darstellung ändert sich. Geht CO bei Persistenz oder Replikation verloren, fehlt die Grundlage zur Rekonstruktion. Ein letzter RCODE zeigt nicht, ob validiert, angepasst oder nur weitergereicht wurde.

Kompaktheit verschiebt Kosten

RFC 4470 beschreibt minimal abdeckendes NSEC und Online Signing; RFC 5155 NSEC3. RFC 9824 reduziert gegenüber größeren dynamischen Beweisen Antwortmaterial und Signieroperationen und erschwert Zonenaufzählung.

Compact Answers erlauben jedoch nicht die NXDOMAIN- und Wildcard-Synthese aus RFC 8020 und RFC 8198. Pseudozufällige Subdomain-Queries können daher bis zum autoritativen Signer gelangen, statt im aggressiven negativen Cache zu enden.

Online Signing hält private Signierfähigkeit auf Internet-erreichbarer Infrastruktur bereit und verbraucht Rechenleistung pro Proof. Die kompakte Form reduziert relative Arbeit, ist aber nicht gleichbedeutend mit vorab berechneten Signaturen. RFC 9824 lässt andere Verfahren ausdrücklich offen, wenn seine Vorteile die Exposition nicht rechtfertigen.

Das Anwendungsergebnis braucht einen eigenen Zeugen

Eine Adressbibliothek kann nach NODATA für AAAA zusätzlich A abfragen; NXDOMAIN hätte das eventuell verhindert. Ein Stub fordert vielleicht kein DNSSEC an, ein Tool ignoriert den Bitmap, ein Resolver passt den RCODE an einen Peer ohne CO an.

Running-Code Primacy folgt der ausgeführten Kette: Erzeugung, Signatur, Validierung, NXNAME-Auslegung, Cache, CO-Entscheidung, ausgegebener RCODE, Folgequeries und Anwendungseffekt. Reality Layers verhindern, dass NOERROR den signierten Beweis überstimmt oder eine valide Signatur zum Anwendungserfolg erklärt wird.

Quellen

  1. IETF Datatracker: RFC 9824
  2. Historie von RFC 9824
  3. Referenced-by-Daten
  4. Referenzen von RFC 9824
  5. Heng Lu: Minimum Initial Specification
  6. Heng Lu: Reality Layers
  7. Heng Lu: Running-Code Primacy
  8. IANA DNS Parameters
  9. Errata zu RFC 9824
  10. RFC-Editor-Information
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824