1. Einführung und Hintergrund
Das DNS-Protokoll [RFC1035] definiert den Antwortcode 3 als "Name Error" (Namensfehler) bzw. "NXDOMAIN" [RFC2308], was bedeutet, dass der abgefragte Domainname im DNS nicht existiert. Da Domainnamen als Baum von Labels dargestellt werden ([RFC1034], Abschnitt 3.1), impliziert die Nichtexistenz eines Knotens die Nichtexistenz des gesamten Teilbaums, der an diesem Knoten wurzelt.
Der iterative Auflösungsalgorithmus des DNS interpretiert das NXDOMAIN-Signal genau auf diese Weise. Trifft er auf einen NXDOMAIN-Antwortcode von einem autoritativen Server, bricht er die Iteration sofort ab und gibt die NXDOMAIN-Antwort an den Anfragenden zurück.
Bei den meisten heute bekannten Resolvern wird eine zwischengespeicherte Nichtexistenz einer Domain jedoch nicht als "Beweis" dafür angesehen, dass darunter keine untergeordneten Domains existieren können. Ursache ist eine Mehrdeutigkeit in [RFC1034], die nicht klar zwischen Namen leerer Nicht-Endknoten (Empty Non-Terminal, ENT) ([RFC7719]) und nicht existierenden Namen unterschied (Abschnitt 3.1). Diese Unterscheidung wurde für die Entwicklung von DNSSEC, das einen Nichtexistenzbeweis liefert, besonders wichtig. [RFC4035], Abschnitt 3.1.3.2, beschreibt, wie sicherheitsbewusste autoritative Namensserver diese Unterscheidung treffen, aber kein bestehendes RFC beschreibt das Verhalten für rekursive Namensserver.
Dieses Dokument legt fest, dass eine NXDOMAIN-Antwort für einen Domainnamen bedeutet, dass auch keine untergeordneten Domains unterhalb des abgefragten Namens existieren; darüber hinaus bedeutet es, dass DNS-Resolver eine zwischengespeicherte Nichtexistenz auf diese Weise interpretieren sollten. Da Domainnamen in einem Baum organisiert sind, ist dies eine einfache Konsequenz der Baumstruktur: Die Nichtexistenz eines Knotens impliziert die Nichtexistenz des gesamten Teilbaums, der an diesem Knoten wurzelt.
1.1. Terminologie
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in [RFC2119] beschrieben.
"QNAME": definiert in [RFC1034] und in [RFC1035], Abschnitt 4.1.2; da [RFC2308] jedoch eine andere Definition liefert, wiederholen wir hier die ursprüngliche: Der QNAME ist der Domainname im Frageabschnitt (question section).
"Denied name" (abgelehnter Name): der Domainname, dessen Existenz durch einen Antwort-RCODE von NXDOMAIN abgelehnt wurde. In den meisten Fällen ist er der QNAME, aber wegen [RFC6604] ist das nicht immer der Fall.
Weitere Begriffe sind in [RFC1034], [RFC1035] und (wie NXDOMAIN selbst) im neueren [RFC7719] definiert.
Der Domainnamensraum ist konzeptionell als Baumstruktur definiert. Die Implementierung eines DNS-Resolvers/Caches kann einen Baum oder andere Datenstrukturen verwenden (MAY). Da der Cache eine Teilmenge der Daten im Domainnamensraum ist, ist es viel einfacher, ihn anhand dieser Baumstruktur zu betrachten und die Dinge mit diesen Begriffen zu beschreiben (Namen darunter/darüber, Nachkommennamen, Teilbäume usw.). Tatsächlich setzt die DNS-Algorithmusbeschreibung in [RFC1034] sogar voraus, dass der Cache eine Baumstruktur ist, sodass der Präzedenzfall bereits gut etabliert ist: siehe deren Abschnitt 4.3.2, der besagt: "The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache..." In diesem Dokument beziehen wir uns also jedes Mal, wenn wir von einem Baum oder von Baumoperationen sprechen, auf das Modell, nicht auf die tatsächliche Implementierung.