2. Règles (Rules)

Lorsqu'un résolveur DNS à cache itératif reçoit une réponse NXDOMAIN, il DEVRAIT (SHOULD) la stocker dans son cache et ensuite tous les noms et ensembles d'enregistrements de ressources (RRsets) au niveau ou en dessous de ce nœud DEVRAIENT (SHOULD) être considérés comme inaccessibles. Les requêtes ultérieures pour de tels noms DEVRAIENT (SHOULD) susciter une réponse NXDOMAIN.

Mais, si un résolveur a mis en cache des données sous la coupure NXDOMAIN, il PEUT (MAY) continuer à les envoyer comme réponse (jusqu'à ce que le TTL de ces données mises en cache expire), car cela peut éviter un traitement supplémentaire lorsqu'une requête est reçue. La section 6 fournit plus d'informations à ce sujet.

Une autre exception est qu'un résolveur validant PEUT (MAY) décider de mettre en œuvre le comportement de "coupure NXDOMAIN" (décrit dans le premier paragraphe de cette section) uniquement lorsque la réponse NXDOMAIN a été validée avec DNSSEC. Voir la section 7 pour la justification.

Le fait qu'un sous-arbre n'existe pas n'est pas éternel : la [RFC2308], Section 3, décrit déjà la durée pendant laquelle une réponse NXDOMAIN peut être mise en cache (le "TTL négatif").

Si la réponse NXDOMAIN due à une inexistence mise en cache provient d'une zone signée DNSSEC, alors elle aura des enregistrements NSEC ou NSEC3 accompagnateurs qui authentifient l'inexistence du nom. Pour un nom descendant du nom NXDOMAIN original, le même ensemble d'enregistrements NSEC ou NSEC3 prouve l'inexistence du nom descendant. Le résolveur itératif à cache DOIT (MUST) renvoyer ces enregistrements NSEC ou NSEC3 dans la réponse à la requête déclenchante si la requête avait le bit DNSSEC OK (DO) défini.

Attention : s'il y a une chaîne de CNAME (ou DNAME), le nom qui n'existe pas est le dernier de la chaîne ([RFC6604]) et non le QNAME. Le NXDOMAIN stocké dans le cache est pour le nom refusé, pas toujours pour le QNAME.

Comme exemple de la conséquence de ces règles, considérez deux requêtes successives à un résolveur avec un domaine inexistant 'foo.example' : la première est pour 'foo.example' (qui résulte en un NXDOMAIN) et la seconde pour 'bar.foo.example' (qui résulte également en un NXDOMAIN). De nombreux résolveurs aujourd'hui transmettront les deux requêtes. Cependant, en suivant les règles de ce document ("coupure NXDOMAIN"), un résolveur mettrait en cache la première réponse NXDOMAIN, comme un signe d'inexistence, et renverrait ensuite immédiatement une réponse NXDOMAIN pour la seconde requête, sans la transmettre à un serveur faisant autorité.

Si la première requête est pour 'bar.foo.example' et la seconde pour 'baz.foo.example', alors la première réponse NXDOMAIN ne dira rien sur 'baz.foo.example' ; par conséquent, la seconde requête sera transmise comme elle l'était avant l'utilisation de l'optimisation "coupure NXDOMAIN" (voir Annexe A).