Annexe A. Pourquoi ne pouvons-nous pas simplement utiliser le nom du propriétaire du SOA retourné ? (Appendix A. Why can't we just use the owner name of the returned SOA?)

Dans ce document, nous déduisons la non-existence d'un domaine uniquement pour les réponses NXDOMAIN où le nom refusé était le domaine exact. Si un résolveur envoie une requête aux serveurs de noms du TLD example, demandant l'enregistrement d'échange de courrier (MX) pour www.foobar.example, et reçoit ensuite un NXDOMAIN, il peut seulement enregistrer le fait que www.foobar.example (et tout ce qui se trouve en dessous) n'existe pas. Cela est vrai, que l'enregistrement SOA accompagnant soit pour le domaine example uniquement ou non. On ne peut pas en déduire que foobar.example est inexistant. L'enregistrement SOA accompagnant indique l'apex de la zone, et non le nom de domaine existant le plus proche. Donc, utiliser le nom du propriétaire de l'enregistrement SOA dans la section autorité pour déduire des "coupures NXDOMAIN" n'est actuellement définitivement pas correct.

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.

Déduire la non-existence d'un nœud à partir du SOA dans la réponse NXDOMAIN peut certainement aider contre les attaques "random qnames", mais cela est hors du périmètre de ce document. Cela nécessiterait de traiter les problèmes mentionnés dans le premier paragraphe de cette section. Une solution possible est, lors de la réception d'un NXDOMAIN avec un SOA qui est plus d'un label au-dessus dans l'arbre, d'envoyer des requêtes pour les domaines qui se trouvent entre le QNAME et le nom du propriétaire du SOA. (Un résolveur qui effectue la validation DNSSEC ou la minimisation QNAME devra le faire de toute façon.)

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