Résumé

  • NXDOMAIN porte sur l’existence du nom effectif ; NODATA indique qu’un nom peut exister sans le type demandé. Le premier se mémorise par nom et classe, le second par nom, type et classe.
  • La RFC 2308 a rendu le refus transmissible sans le rendre éternel. Le SOA de la zone accompagne la réponse et fournit une durée négative égale au plus petit de son TTL et de MINIMUM; à zéro, le cache doit renoncer à cette preuve.
  • DNSSEC, la coupure NXDOMAIN et la synthèse agressive ont ensuite élargi les questions auxquelles une seule preuve peut répondre. Ils renforcent donc l’exigence de portée et de durée, sans donner au DNS une autorité juridique sur ce qui « existe ».

Un vide n’identifie pas ce qui manque

Une requête cherche l’adresse IPv4 de service.example; la section Answer ne contient aucun enregistrement A. Plusieurs mondes restent compatibles avec ce paquet. Le nom peut être inexistant. Il peut porter un MX, un TXT ou un AAAA mais aucun A. La réponse peut être une délégation. Le serveur peut aussi être en panne, inaccessible ou incapable de répondre momentanément.

Mettre en cache le mot « absent » sans en préciser l’objet déforme le DNS. Si une absence de type devient une absence de nom, un MX parfaitement valide disparaît aux yeux du résolveur. Si une véritable NXDOMAIN est réduite au seul type A, le résolveur continuera inutilement à demander AAAA, TXT ou SRV pour un nom que l’autorité vient de déclarer inexistant.

NXDOMAIN est le code Name Error. Après résolution d’une éventuelle chaîne CNAME, il vise le nom de requête effectif et sa classe. NODATA n’a pas de RCODE propre : le résolveur le déduit d’un NOERROR, de l’absence de donnée pertinente et d’une section d’autorité permettant d’écarter la simple délégation.

La RFC 2308 inscrit cette différence dans les clés du cache. NXDOMAIN se range sous <QNAME, QCLASS>; NODATA sous <QNAME, QTYPE, QCLASS>. Le détail paraît minuscule, mais il décide si un cache économise une requête ou efface une donnée existante.

Le CNAME déplace le sujet de la preuve

Le nom saisi n’est pas toujours le nom nié. Un alias peut exister et conduire à une cible canonique absente. Dans ce cas, la NXDOMAIN concerne la dernière cible, non l’alias qui a fourni un CNAME valide.

Une mise en cache paresseuse attacherait la réponse négative au premier libellé visible. Elle transformerait alors une preuve sur la cible en disparition de l’alias. La RFC 2308 définit QNAME avec soin précisément parce qu’une preuve distribuée doit garder son sujet lorsqu’elle traverse une chaîne.

NODATA exige la même discipline : l’absence du type demandé à la cible ne supprime ni les autres types, ni les informations propres à l’alias, ni les descendants éventuels.

Faire voyager le refus

La RFC 1034 envisageait déjà en 1987 la mise en cache des réponses négatives. Elle restait facultative. Son intérêt était évident : les listes de recherche, fautes répétées et logiciels automatiques pouvaient provoquer le même échec des centaines de fois, sans qu’une réponse positive soit disponible à mémoriser.

Mais le dispositif initial ne permettait pas de retransmettre proprement une négation déjà mise en cache avec sa preuve et le temps qui lui restait. Un serveur pouvait se souvenir d’un « non » sans donner à un autre résolveur une façon sûre de réutiliser le même constat.

En mars 1998, la RFC 2308 a comblé ce manque. Tout résolveur qui utilise un cache doit aussi traiter les réponses négatives. Une autorité qui annonce NXDOMAIN ou NODATA place le SOA de la zone englobante dans la section Authority. Le SOA situe l’énoncé et transporte sa limite temporelle.

La durée négative est le minimum entre le TTL du SOA et le champ MINIMUM. Le résolveur conserve le SOA avec le résultat. Lorsqu’il répond depuis son cache, le TTL a déjà diminué du temps écoulé. À zéro, l’ancienne négation n’est plus utilisable : il faut réinterroger.

La signature de la RFC 2308 indique l’affiliation de Mark Andrews au CSIRO. C’est une provenance d’auteur, pas le sujet institutionnel du texte. La norme commune et ses évolutions ultérieures ont été élaborées dans le cadre documentaire de l’IETF.

Une limite qui se réinitialise n’est pas une limite

L’espace des noms est arborescent, mais les transferts de requêtes forment un graphe. Deux serveurs mal configurés peuvent se choisir mutuellement comme forwarders. Si la négation ne transporte pas un compte à rebours commun, chacun peut la recevoir, lui attribuer un nouveau délai et la renvoyer.

Une réponse censée être brève pourrait ainsi tourner indéfiniment. La RFC 2308 déconseille donc de mettre en cache une réponse négative dépourvue de SOA. Le SOA ne sert pas à embellir l’erreur : il empêche chaque intermédiaire de réinventer sa durée.

Cette clarification a aussi réparé le sens d’un champ ancien. La RFC 1035 associait MINIMUM à une borne inférieure des TTL. La pratique l’avait chargé de trois rôles : minimum, valeur par défaut et durée négative. La RFC 2308 a abandonné le premier usage, confié la valeur par défaut de fichier de zone à $TTL, et gardé MINIMUM comme entrée du calcul négatif. Le standard a suivi ce que le code avait rendu nécessaire, puis en a réduit l’ambiguïté.

Le déploiement a découvert deux absences

L’annexe historique de la RFC 2308 cite CHIVES à la fin des années 1980. Les chemins de recherche provoquaient de nombreuses requêtes manquées; conserver les erreurs autoritatives améliorait le temps de réponse sur les machines concernées. Elle décrit aussi les travaux BIND du début des années 1990, où NOERROR_NODATA fut distingué de l’erreur de nom avant que le SOA ne soit conservé avec le résultat.

Il ne s’agit ni d’un recensement complet, ni de la biographie d’un inventeur unique. Ces traces montrent plutôt la maturation d’une représentation : le simple vide devient une condition typée; la condition reçoit une clé; la clé reçoit une preuve transmissible et une date de fin. La précision sur les RRsets apportée par la RFC 2181 consolide ce langage.

L’efficacité retarde parfois la création

Une négation exacte au moment T peut devenir obsolète au moment T+1. Si l’exploitant crée un nom alors que des caches détiennent encore NXDOMAIN, ces clients continueront à nier le nom jusqu’à expiration. Si l’exploitant ajoute AAAA après une NODATA sur AAAA, le nom reste visible, mais la nouvelle voie IPv6 peut rester cachée.

Le TTL n’est donc pas une note de confiance. Il échange du trafic autoritatif contre un délai de correction. La RFC 2308 permet aux résolveurs d’imposer un plafond plus court; elle rapporte que des valeurs de une à trois heures fonctionnaient raisonnablement, tandis que des valeurs supérieures à une journée posaient problème.

Les caches ne commencent pas tous leur décompte ensemble. Ils interrogent à des moments différents et appliquent parfois des plafonds différents. Corriger la zone n’efface pas instantanément les observations passées. Un plan de lancement doit connaître les négations reçues avant le changement.

Il faut aussi garder la panne hors du vocabulaire d’existence. Timeout, serveur inaccessible et SERVFAIL ne démontrent pas l’absence d’un nom. Les transformer en NXDOMAIN peut faire prendre aux applications une décision définitive à partir d’un incident transitoire.

La preuve négative s’étend

DNSSEC a rendu certaines absences vérifiables cryptographiquement. La RFC 4034 définit NSEC : chaque enregistrement relie des propriétaires dans l’ordre canonique et énumère les types présents. La RFC 4035 précise comment le validateur établit NXDOMAIN ou NODATA.

La signature ne fusionne pas les deux absences. Un intervalle entre propriétaires peut prouver qu’un nom manque; le bitmap d’un propriétaire existant peut prouver qu’un type manque. L’intégrité de la preuve ne change pas son objet.

La RFC 5155 introduit NSEC3 et les noms hachés. Son mode Opt-Out rappelle qu’une couverture cryptographique n’autorise pas toute inférence : l’enregistrement couvrant ne prouve pas nécessairement l’absence de chaque nom possible.

La RFC 8020 permet ensuite qu’une NXDOMAIN interrompe les recherches sous le nom concerné, dans ses limites. Un descendant ne peut exister sous un nom inexistant. La règle ne vaut pas pour NODATA : un nom sans A peut avoir un MX, des enfants et bien d’autres types.

Enfin, la RFC 8198 autorise un résolveur validant à synthétiser des négations à partir d’un NSEC ou NSEC3 déjà en cache. Une preuve peut répondre à une question jamais envoyée à l’autorité. L’économie augmente, mais une nouvelle donnée située dans l’intervalle peut aussi rester invisible jusqu’à la fin des TTL pertinents.

Une preuve de protocole, pas un titre de propriété

Quatre rôles restent distincts. L’exploitant de zone décide du contenu et des délais. Le serveur autoritatif construit la réponse. Le résolveur la classe, la valide, lui applique une clé et un plafond local, puis l’oublie. L’application décide enfin des conséquences pour le courrier, l’authentification ou la découverte de service.

DNSSEC certifie l’origine et l’intégrité dans la chaîne DNS. Il ne certifie ni la propriété juridique, ni l’inexistence d’une organisation, ni la légitimité d’une suppression. La capacité de publier ou d’amplifier un refus est un pouvoir opérationnel réel, mais borné.

La réussite historique est justement cette modestie. Le DNS a rendu l’absence partageable en indiquant quel objet manque, quelle zone peut en répondre et jusqu’à quand le constat peut être réutilisé. NXDOMAIN et NODATA ont empêché que la mémoire d’un échec ne devienne l’effacement du reste.

Sources et limites

Le cadre initial vient des RFC 1034 et RFC 1035, complétées sur les RRsets par la RFC 2181. La distinction, les clés, le SOA, le compte à rebours et l’annexe de déploiement sont dans la RFC 2308. Les preuves signées relèvent des RFC 4034, RFC 4035 et RFC 5155; la coupure et la synthèse ultérieures des RFC 8020 et RFC 8198. Les mécanismes tardifs ne sont pas attribués aux résolveurs de 1987, et l’annexe historique n’est pas traitée comme une mesure exhaustive.