Anhang A. Warum können wir nicht einfach den Eigentümernamen des zurückgegebenen SOA verwenden? (Appendix A. Why can't we just use the owner name of the returned SOA?)

In diesem Dokument leiten wir die Nichtexistenz einer Domain nur für NXDOMAIN-Antworten ab, bei denen der abgelehnte Name die exakte Domain war. Wenn ein Resolver eine Anfrage an die Nameserver der TLD example sendet und nach dem Mail-Exchange-Eintrag (MX) für www.foobar.example fragt und anschließend ein NXDOMAIN erhält, kann er nur die Tatsache registrieren, dass www.foobar.example (und alles darunter) nicht existiert. Dies gilt unabhängig davon, ob der begleitende SOA-Eintrag nur für die Domain example ist oder nicht. Man kann nicht daraus schließen, dass foobar.example nicht existiert. Der begleitende SOA-Eintrag zeigt den Apex der Zone an, nicht den nächstgelegenen existierenden Domainnamen. Daher ist die Verwendung des Eigentümernamens des SOA-Eintrags in der Autoritätssektion zur Ableitung von "NXDOMAIN-Cuts" derzeit definitiv nicht in Ordnung.

In this document, we deduce the nonexistence of a domain only for NXDOMAIN answers where the denied name was the exact domain. If a resolver sends a query to the name servers of the TLD example, asking for the mail exchange (MX) record for www.foobar.example, and subsequently receives a NXDOMAIN, it can only register the fact that www.foobar.example (and everything underneath) does not exist. This is true regardless of whether or not the accompanying SOA record is for the domain example only. One cannot infer that foobar.example is nonexistent. The accompanying SOA record indicates the apex of the zone, not the closest existing domain name. So, using the owner name of the SOA record in the authority section to deduce "NXDOMAIN cuts" is currently definitely not OK.

Das Ableiten der Nichtexistenz eines Knotens aus dem SOA in der NXDOMAIN-Antwort kann sicherlich bei "Random Qnames"-Angriffen helfen, aber dies liegt außerhalb des Umfangs dieses Dokuments. Es würde erfordern, die im ersten Absatz dieses Abschnitts genannten Probleme anzugehen. Eine mögliche Lösung besteht darin, beim Empfang eines NXDOMAIN mit einem SOA, das mehr als ein Label höher im Baum liegt, Anfragen für die Domains zu senden, die zwischen dem QNAME und dem Eigentümernamen des SOA liegen. (Ein Resolver, der DNSSEC-Validierung oder QNAME-Minimierung durchführt, muss dies ohnehin tun.)

Deducing the nonexistence of a node from the SOA in the NXDOMAIN reply may certainly help with random qnames attacks, but this is out-of-scope for this document. It would require addressing the problems mentioned in the first paragraph of this section. A possible solution is, when receiving a NXDOMAIN with a SOA that is more than one label up in the tree, to send requests for the domains that are between the QNAME and the owner name of the SOA. (A resolver that does DNSSEC validation or QNAME minimization will need to do it anyway.)