2. Regeln

Wenn ein iterativer Caching-DNS-Resolver eine NXDOMAIN-Antwort erhält, sollte er sie in seinem Cache speichern (SHOULD), und anschließend sollten alle Namen und Ressourcendatensatzgruppen (RRsets) an oder unterhalb dieses Knotens als unerreichbar gelten (SHOULD). Nachfolgende Anfragen für solche Namen sollten eine NXDOMAIN-Antwort auslösen (SHOULD).

Wenn ein Resolver jedoch Daten unterhalb des NXDOMAIN-Schnitts zwischengespeichert hat, kann er sie weiterhin als Antwort senden (MAY) — bis die TTL dieser zwischengespeicherten Daten abläuft —, da dies zusätzliche Verarbeitung beim Empfang einer Anfrage vermeiden kann. Abschnitt 6 enthält weitere Informationen dazu.

Eine weitere Ausnahme besteht darin, dass ein validierender Resolver entscheiden kann, das Verhalten des "NXDOMAIN-Schnitts" (beschrieben im ersten Absatz dieses Abschnitts) nur dann zu implementieren (MAY), wenn die NXDOMAIN-Antwort mit DNSSEC validiert wurde. Die Begründung findet sich in Abschnitt 7.

Die Tatsache, dass ein Teilbaum nicht existiert, gilt nicht für immer: [RFC2308], Abschnitt 3, beschreibt bereits die Zeitspanne, während der eine NXDOMAIN-Antwort zwischengespeichert werden darf (die "negative TTL").

Stammt die NXDOMAIN-Antwort aufgrund einer zwischengespeicherten Nichtexistenz aus einer DNSSEC-signierten Zone, so wird sie von NSEC- oder NSEC3-Datensätzen begleitet, die die Nichtexistenz des Namens authentifizieren. Für einen Nachkommennamen des ursprünglichen NXDOMAIN-Namens beweist dieselbe Menge von NSEC- oder NSEC3-Datensätzen die Nichtexistenz des Nachkommennamens. Der iterative Caching-Resolver muss diese NSEC- oder NSEC3-Datensätze in der Antwort auf die auslösende Anfrage zurückgeben (MUST), wenn die Anfrage das DNSSEC-OK-Bit (DO) gesetzt hatte.

Warnung: Wenn eine Kette von CNAME (oder DNAME) vorliegt, ist der nicht existierende Name der letzte der Kette ([RFC6604]) und nicht der QNAME. Das im Cache gespeicherte NXDOMAIN gilt für den abgelehnten Namen, nicht immer für den QNAME.

Als Beispiel für die Konsequenz dieser Regeln betrachten wir zwei aufeinanderfolgende Anfragen an einen Resolver mit einer nicht existierenden Domain 'foo.example': Die erste gilt 'foo.example' (was zu einem NXDOMAIN führt) und die zweite 'bar.foo.example' (was ebenfalls zu einem NXDOMAIN führt). Viele Resolver leiten heute beide Anfragen weiter. Nach den Regeln in diesem Dokument ("NXDOMAIN-Schnitt") würde ein Resolver jedoch die erste NXDOMAIN-Antwort als Zeichen der Nichtexistenz zwischenspeichern und dann sofort eine NXDOMAIN-Antwort für die zweite Anfrage zurückgeben, ohne sie an einen autoritativen Server zu übermitteln.

Ist die erste Anfrage für 'bar.foo.example' und die zweite für 'baz.foo.example', so sagt die erste NXDOMAIN-Antwort nichts über 'baz.foo.example' aus; daher wird die zweite Anfrage so übermittelt, wie es vor der Verwendung der "NXDOMAIN-Schnitt"-Optimierung der Fall war (siehe Anhang A).