Appendice A. Perché non possiamo semplicemente usare il nome del proprietario del SOA restituito? (Appendix A. Why can't we just use the owner name of the returned SOA?)

In questo documento, deduciamo l'inesistenza di un dominio solo per le risposte NXDOMAIN in cui il nome negato era il dominio esatto. Se un risolutore invia una query ai server dei nomi del TLD example, chiedendo il record di scambio di posta (MX) per www.foobar.example, e successivamente riceve un NXDOMAIN, può solo registrare il fatto che www.foobar.example (e tutto ciò che si trova sotto) non esiste. Questo è vero indipendentemente dal fatto che il record SOA di accompagnamento sia solo per il dominio example o meno. Non si può dedurre che foobar.example sia inesistente. Il record SOA di accompagnamento indica l'apice della zona, non il nome di dominio esistente più vicino. Quindi, utilizzare il nome del proprietario del record SOA nella sezione autorità per dedurre "tagli NXDOMAIN" non è attualmente decisamente OK.

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.

Dedurre l'inesistenza di un nodo dal SOA nella risposta NXDOMAIN può certamente aiutare con gli attacchi "random qnames", ma questo è fuori scopo per questo documento. Richiederebbe di affrontare i problemi menzionati nel primo paragrafo di questa sezione. Una possibile soluzione è, quando si riceve un NXDOMAIN con un SOA che è più di un'etichetta in alto nell'albero, inviare richieste per i domini che si trovano tra il QNAME e il nome del proprietario del SOA. (Un risolutore che esegue la convalida DNSSEC o la minimizzazione QNAME dovrà farlo comunque.)

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.)