Annexe A. Pourquoi ne pouvons-nous pas simplement utiliser le nom du propriétaire du SOA retourné ?

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.

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