1. Introduction et Contexte (Introduction and Background)
Le protocole DNS [RFC1035] définit le code de réponse 3 comme "Erreur de nom" (Name Error), ou "NXDOMAIN" [RFC2308], ce qui signifie que le nom de domaine demandé n'existe pas dans le DNS. Puisque les noms de domaine sont représentés comme un arbre d'étiquettes ([RFC1034], Section 3.1), l'inexistence d'un nœud implique l'inexistence de l'arbre entier enraciné à ce nœud.
L'algorithme de résolution itérative DNS interprète précisément le signal NXDOMAIN de cette manière. S'il rencontre un code de réponse NXDOMAIN provenant d'un serveur faisant autorité, il arrête immédiatement l'itération et renvoie la réponse NXDOMAIN au demandeur.
Cependant, dans la plupart des résolveurs existants connus aujourd'hui, une inexistence mise en cache pour un domaine n'est pas considérée comme une "preuve" qu'il ne peut y avoir aucun domaine enfant en dessous. Cela est dû à une ambiguïté dans la [RFC1034] qui n'a pas réussi à distinguer les noms vides non terminaux (Empty Non-Terminal - ENT) ([RFC7719]) des noms inexistants (Section 3.1). La distinction est devenue particulièrement importante pour le développement de DNSSEC, qui fournit une preuve d'inexistence. La [RFC4035], Section 3.1.3.2, décrit comment les serveurs de noms faisant autorité et conscients de la sécurité font la distinction, mais aucune RFC existante ne décrit le comportement pour les serveurs de noms récursifs.
Ce document spécifie qu'une réponse NXDOMAIN pour un nom de domaine signifie qu'aucun domaine enfant sous le nom demandé n'existe non plus ; de plus, cela signifie que les résolveurs DNS devraient interpréter l'inexistence mise en cache de cette manière. Puisque les noms de domaine sont organisés en arbre, c'est une conséquence simple de la structure arborescente : l'inexistence d'un nœud implique l'inexistence de l'arbre entier enraciné à ce nœud.
1.1. Terminologie (Terminology)
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la [RFC2119].
"QNAME" : défini dans la [RFC1034] et dans la [RFC1035], Section 4.1.2, mais, parce que la [RFC2308] fournit une définition différente, nous répétons l'originale ici : le QNAME est le nom de domaine dans la section question.
"Nom refusé" (Denied name) : le nom de domaine dont l'existence a été refusée par un RCODE de réponse de NXDOMAIN. Dans la plupart des cas, c'est le QNAME mais, à cause de la [RFC6604], ce n'est pas toujours le cas.
D'autres termes sont définis dans la [RFC1034], la [RFC1035], et (comme NXDOMAIN lui-même) dans la plus récente [RFC7719].
L'espace de noms de domaine est conceptuellement défini en termes de structure arborescente. L'implémentation d'un résolveur/cache DNS PEUT (MAY) utiliser un arbre ou d'autres structures de données. Le cache étant un sous-ensemble des données dans l'espace de noms de domaine, il est beaucoup plus facile de raisonner à son sujet en termes de cette structure arborescente et de décrire les choses en ces termes (noms sous/au-dessus, noms descendants, sous-arbres, etc.). En fait, la description de l'algorithme DNS dans la [RFC1034] énonce même une hypothèse selon laquelle le cache est une structure arborescente, de sorte que le précédent est déjà bien établi : voir sa Section 4.3.2, qui dit "L'algorithme suivant suppose que les RR sont organisés en plusieurs structures arborescentes, une pour chaque zone, et une autre pour le cache..." Donc, dans ce document, chaque fois que nous parlons d'un arbre ou d'opérations sur les arbres, nous faisons référence au modèle, pas à l'implémentation réelle.