Zusammenfassung

  • NXDOMAIN verneint den wirksamen Namen; NODATA lässt den Namen bestehen und verneint nur den angefragten Typ. Deshalb wird NXDOMAIN nach Name und Klasse, NODATA zusätzlich nach Typ abgelegt.
  • RFC 2308 machte negative Antworten transportierbar und sterblich. Das SOA der Zone liefert Kontext und Laufzeit; der kleinere Wert aus SOA-TTL und MINIMUM zählt herunter, danach darf der Cache die Verneinung nicht mehr benutzen.
  • DNSSEC, NXDOMAIN-Cuts und aggressive Synthese erweiterten später die Reichweite eines validierten Belegs. Das spart Anfragen, vergrößert aber die Wirkung eines falschen Umfangs. Eine DNS-Signatur beweist weder Eigentum noch dauerhafte Nichtexistenz.

Eine leere Answer-Sektion lässt mehrere Welten offen

Ein Resolver fragt nach dem A-Record von service.example und findet keinen A-Record in der Antwort. Der Name könnte fehlen. Er könnte MX, TXT oder AAAA besitzen, aber kein A. Die Nachricht könnte ein Referral sein. Der Server könnte vorübergehend ausfallen oder SERVFAIL liefern.

Die falsche Speicherung verändert den sichtbaren Namensraum. Wird ein fehlender A-Record zu einem fehlenden Namen, verschwindet ein vorhandener MX für nachfolgende Clients. Wird echtes NXDOMAIN nur als fehlendes A behandelt, entstehen unnötige Fragen nach AAAA, TXT und weiteren Typen.

NXDOMAIN ist der DNS-Name Error und gilt nach einer CNAME-Kette für den wirksamen QNAME und seine Klasse. NODATA besitzt keinen eigenen RCODE. Es wird aus NOERROR, dem fehlenden einschlägigen Ergebnis und Authority-Daten abgeleitet, die ein Referral ausschließen.

RFC 2308 übersetzt diese Bedeutung in Cache-Schlüssel: <QNAME, QCLASS> für NXDOMAIN, <QNAME, QTYPE, QCLASS> für NODATA. Der zusätzliche Typ schützt alle anderen Daten desselben Namens.

Ein Alias verschiebt den Gegenstand

Der eingegebene Alias kann existieren und auf ein nicht vorhandenes kanonisches Ziel zeigen. Dann betrifft NXDOMAIN das letzte Ziel, nicht den Alias, der einen gültigen CNAME geliefert hat.

Wer die Verneinung aus Bequemlichkeit am ersten Label speichert, wendet einen Beleg auf den falschen Gegenstand an. NODATA verlangt dieselbe Genauigkeit: Ein fehlender Typ am Ziel beseitigt weder andere Typen noch Alias-Daten oder mögliche Nachkommen.

Negatives Caching verteilt Belege. Vor der Weitergabe von „nichts“ muss feststehen, bei welchem Namen was fehlt.

Aus lokaler Erinnerung wird eine portable Aussage

RFC 1034 beschrieb negatives Caching bereits 1987, jedoch als Option. Suchpfade, Tippfehler und automatische Discovery wiederholten erfolglose Fragen. Ein gespeicherter Fehlschlag senkte Latenz und autoritativen Verkehr.

Die ursprüngliche Regel erlaubte aber keine saubere Weitergabe einer bereits gecachten negativen Antwort mit demselben Beleg und derselben Restlaufzeit. Ein Server konnte sich an „nein“ erinnern, ohne daraus eine zuverlässig übertragbare Aussage zu machen.

RFC 2308 schloss diese Lücke im März 1998. Wer überhaupt cached, muss auch negative Antworten behandeln. Bei NXDOMAIN oder NODATA legt der autoritative Server das SOA der umfassenden Zone in die Authority-Sektion. Es benennt den DNS-Kontext der Aussage und trägt ihre zeitliche Grenze.

Die negative Laufzeit ist das Minimum aus SOA-TTL und MINIMUM. Der Resolver speichert das SOA mit dem Ergebnis; bei einer Antwort aus dem Cache ist die vergangene Zeit bereits abgezogen. Bei null muss der alte Befund verworfen werden.

RFC 2308 nennt Mark Andrews mit CSIRO-Zugehörigkeit. Das ist Autorenprovenienz, nicht der institutionelle Gegenstand des Artikels. Der gemeinsame Standard und seine Nachfolger wurden im Dokumentenprozess der IETF entwickelt.

Eine Uhr, die jeder neu startet, läuft ewig

Der Namensraum ist ein Baum, doch Forwarder können Schleifen bilden. Zwei falsch konfigurierte Server können einander als Weiterleitung verwenden. Ohne portable Restlaufzeit versieht jeder die empfangene Verneinung mit einer neuen kurzen Frist und sendet sie zurück.

So kann ein vorübergehender Fehler endlos zirkulieren. RFC 2308 rät deshalb davon ab, negative Antworten ohne SOA zu cachen. Eine lokale Begrenzung ist keine Begrenzung, wenn der nächste Knoten die Uhr zurücksetzt. Das SOA bewahrt den gemeinsamen Verfall des Belegs.

Dabei wurde auch MINIMUM entwirrt. RFC 1035 hatte es als TTL-Untergrenze beschrieben; Implementierungen nutzten es zugleich als Standard und negative Laufzeit. RFC 2308 trennte den Zonendatei-Standard in $TTL, verwarf das universelle Minimum und behielt MINIMUM für negatives Caching. Laufender Code hatte die Mehrdeutigkeit offengelegt, die der spätere Vertrag begrenzte.

Implementierungen fanden zwei Arten von Abwesenheit

Der historische Anhang von RFC 2308 berichtet über CHIVES Ende der 1980er Jahre. Suchpfade erzeugten viele wiederholte Fehlschläge; das Speichern autoritativer Fehler war unter teurer Netznutzung praktisch. Für BIND beschreibt er Anfang der 1990er Jahre die Trennung von Namensfehler und NOERROR_NODATA sowie die spätere Speicherung des SOA.

Das ist weder eine Vollerhebung noch eine Erfindergeschichte. Es zeigt, dass „leer“ für interoperable Resolver zu grob war. Die RRset-Präzisierung in RFC 2181 und die Tupel in RFC 2308 machten Umsetzungserfahrung zu gemeinsamer Semantik.

Gespeicherte Abwesenheit verzögert neue Existenz

Eine richtige Verneinung altert, sobald die Zone geändert wird. Wird ein Name angelegt, während Resolver NXDOMAIN halten, bleibt er für deren Nutzer unsichtbar. Wird einem bestehenden Namen nach NODATA ein AAAA hinzugefügt, können MX und andere Daten sichtbar sein, während die neue IPv6-Erreichbarkeit noch fehlt.

Ein TTL ist kein Vertrauenswert. Es tauscht weniger autoritative Anfragen gegen langsamere Korrektur. RFC 2308 erlaubt lokale Obergrenzen und nennt ein bis drei Stunden als brauchbare Defaults; mehr als ein Tag hatte sich als problematisch erwiesen.

Caches erhalten ihre Antwort zu unterschiedlichen Zeiten und verwenden unterschiedliche Limits. Es gibt keinen globalen Ablaufzeitpunkt. Ein Einführungsplan muss alte negative Antworten berücksichtigen, nicht nur den aktuellen Inhalt der Zone.

Ausfälle bleiben eine andere Kategorie. Timeout, Unerreichbarkeit und SERVFAIL beweisen keine Nichtexistenz. Wer sie in NXDOMAIN verwandelt, kann aus einer reparierbaren Störung eine dauerhafte Mail-Ablehnung, Identitätsstörung oder fehlgeschlagene Discovery machen.

Ein Beleg beantwortet später mehr als eine Frage

DNSSEC fügte authentisierte Verneinung hinzu. RFC 4034 definiert NSEC, das Namen in kanonischer Reihenfolge verbindet und die Typen eines vorhandenen Owners aufführt. RFC 4035 beschreibt die Validierung von NXDOMAIN und NODATA.

Die Signatur hebt die Unterscheidung nicht auf. Eine Lücke zwischen Namen kann Namensabwesenheit beweisen; die Typ-Bitmap eines vorhandenen Owners beweist Typ-Abwesenheit. Kryptografie authentisiert den passenden Beleg, nicht eine weitergehende Behauptung.

RFC 5155 führte NSEC3 und Opt-Out ein. Bei Opt-Out beweist ein überdeckender NSEC3-Record nicht zwingend, dass jeder denkbare Name in seinem Bereich fehlt.

RFC 8020 erlaubt innerhalb definierter Grenzen, NXDOMAIN auch für untergeordnete Namen zu verwenden. Unter einem nicht vorhandenen Knoten kann kein Nachkomme existieren. NODATA hat diese Wirkung nicht: Ein Name ohne A kann andere Typen und Kinder besitzen.

RFC 8198 gestattet validierenden Resolvern, aus gecachten NSEC/NSEC3-Belegen weitere negative Antworten zu synthetisieren. Die Frage muss die Autorität nicht mehr erreichen. Das spart Pakete, kann aber einen neu angelegten Namen im bewiesenen Bereich bis zum Ablauf der relevanten Daten verbergen.

Begrenzte Protokollaussage statt Wahrheitshoheit

Der Zonenbetreiber wählt Inhalt und Zeitwerte. Der autoritative Server baut die Antwort. Der Resolver klassifiziert, validiert, begrenzt und vergisst. Die Anwendung entscheidet über die Folgen. Diese Rollen besitzen reale Hebel, aber keine gemeinsame Hoheit über Tatsachen außerhalb des DNS.

DNSSEC belegt Herkunft und Integrität in der DNS-Kette. Es belegt kein juristisches Recht, kein Verschwinden einer Organisation und keine Berechtigung einer Löschung. Ein Cache darf eine gültige Verneinung verstärken, aber nicht verewigen.

Der historische Fortschritt war bewusst eng: DNS benannte den Gegenstand, unterschied die Art der Abwesenheit, trug den Zonenbeleg weiter und erzwang sein Ablaufdatum. NXDOMAIN und NODATA verhinderten, dass eingesparte Anfragen zu gelöschter Wirklichkeit wurden.

Quellen und Grenzen

Grundlagen und SOA stammen aus RFC 1034 und RFC 1035, die RRset-Präzisierung aus RFC 2181. Definitionen, Schlüssel, Uhr, Schleifenwarnung und Umsetzungsgeschichte stehen in RFC 2308. Authentisierte Verneinung wird durch RFC 4034, RFC 4035 und RFC 5155 begrenzt; spätere Cut- und Synthese-Regeln durch RFC 8020 und RFC 8198. Moderne Fähigkeiten werden nicht in das Jahr 1987 zurückprojiziert, der historische Anhang nicht als vollständige Messung behandelt.