Résumé

  • NXDOMAIN affirme que le nom demandé n’existe pas ; NODATA signifie que le nom peut exister sans le type demandé. Le premier se mémorise par nom et classe, le second par nom, type et classe.
  • RFC 2308 fit transporter la durée du refus par le SOA de la zone. Le plus petit du TTL du SOA et de son champ MINIMUM décroît dans chaque réponse mise en cache ; arrivé à zéro, le refus doit être abandonné.
  • Cette durée transmissible évite qu’une réponse négative sans SOA soit rajeunie à chaque étape d’une boucle de redirecteurs et survive indéfiniment.
  • DNSSEC permit plus tard de valider des preuves de non-existence et d’en déduire d’autres réponses dans une plage. Il authentifie une déclaration DNS ; il ne prouve ni un droit institutionnel ni une vérité permanente.

Une absence doit avoir un auteur

La requête qui échoue peut coûter davantage que celle qui réussit. Une liste de recherche ajoute des suffixes à un nom mal saisi ; une application retente une découverte ; des milliers de clients demandent un service qui n’a jamais existé. Sans mémoire du résultat, chaque échec remonte vers les serveurs faisant autorité.

Il serait pourtant dangereux de mémoriser le seul fait qu’aucune donnée utile n’est arrivée. Un délai dépassé ne dit rien de l’existence du nom. SERVFAIL annonce l’incapacité d’un serveur à répondre correctement, non l’absence de l’objet. Une section de réponse vide peut être une délégation. Pour devenir réutilisable, l’absence doit être formulée par une source compétente, limitée à un objet et promise pour une durée finie.

RFC 1034 prévoyait dès 1987 un cache des réponses négatives, mais le rendait facultatif. Une erreur de nom faisant autorité pouvait recevoir un TTL. L’idée suivait le compromis général du DNS : les propriétaires des données indiquent pendant combien de temps une copie locale peut éviter une nouvelle consultation.

Le mécanisme restait incomplet. Comme l’expliquera RFC 2308, un serveur ne pouvait pas redistribuer proprement sa réponse négative mise en cache à un autre résolveur avec la même preuve utile. Le système savait retenir un refus, pas encore préserver son âge lorsqu’il circulait.

Deux négations, deux clés

NXDOMAIN est un code de réponse : le nom visé par la requête effective n’existe pas. En présence d’une chaîne CNAME, le nom nié peut être la dernière cible canonique, et non l’alias de départ. Le cache associe cette conclusion au nom et à la classe. Demander un autre type ne recrée pas un nom que l’autorité vient de déclarer inexistant.

NODATA est plus étroit. Ce n’est pas un code inscrit dans l’en-tête. Le message porte NOERROR, ne contient pas la réponse de type demandé et fournit dans la section d’autorité les éléments permettant de ne pas le confondre avec un renvoi. Le nom peut être réel et posséder, par exemple, des enregistrements MX ou TXT, tout en n’ayant aucun A.

Le cache doit donc indexer NODATA par nom, type et classe. Transformer « pas de A » en « pas de nom » ferait disparaître les autres jeux d’enregistrements. Cette différence de clé est une règle de conservation de l’information, pas une subtilité de vocabulaire.

Le SOA devient l’horloge du refus

Publié en mars 1998, RFC 2308 fut rédigé par Mark Andrews alors affilié au CSIRO, inscrivant ainsi un organisme public de recherche australien dans la filiation documentaire de cette règle d’exploitation du DNS. L’IETF fournit le lieu de normalisation où ce contrat, puis les raffinements DNSSEC, devinrent des spécifications communes. Les rôles institutionnels sont distincts : le CSIRO est lié ici parce qu’il est l’affiliation portée par l’auteur de la spécification décisive ; le processus de l’IETF transforma le texte en contrat commun de l’Internet.

Un serveur faisant autorité qui annonce NXDOMAIN ou NODATA doit joindre le SOA de la zone concernée. Ce record indique la zone habilitée à formuler le refus et transporte sa limite temporelle. Le TTL négatif est le plus petit du TTL propre au SOA et du champ MINIMUM du SOA.

Le résolveur conserve ce SOA avec la réponse. Quand il répond à un autre client, il soustrait le temps déjà passé en cache. À zéro, le négatif ne doit plus être utilisé. Le refus devient ainsi un bail : la zone a récemment affirmé cette absence, pour cette portée ; passé l’échéance, il faut lui redemander.

Cette règle répara aussi l’ambiguïté de MINIMUM. RFC 1035 l’avait défini comme une borne inférieure des TTL exportés. Les logiciels l’avaient ensuite employé comme minimum général, valeur par défaut et durée du cache négatif. RFC 2308 déprécia le premier sens, sépara la valeur par défaut avec $TTL et conserva MINIMUM comme ingrédient de la durée négative.

Une limite qui ne voyage pas n’est pas une limite

L’espace des noms DNS est un arbre, mais le graphe des requêtes peut boucler. Deux serveurs mal configurés peuvent se désigner mutuellement comme redirecteurs ; des délégations défectueuses produisent d’autres cycles.

Si chaque serveur reçoit un négatif sans SOA, le stocke brièvement puis le transmet avec une durée recommencée, la même indication peut circuler sans fin. RFC 2308 déconseille donc de mettre en cache une réponse négative privée de SOA. Un petit TTL local ne suffit pas si chaque relais le remet à neuf.

Le compte à rebours fait du temps une propriété de la preuve, pas de la machine qui l’a reçue. Des caches indépendants peuvent retransmettre le même refus sans lui rendre l’autorité déjà consommée.

Les implémentations avaient déjà rencontré le problème

L’annexe historique de RFC 2308 décrit CHIVES à la fin de 1987. Les chemins de recherche provoquaient de nombreuses requêtes manquées ; dans une période de congestion d’ARPANET, éviter ces reprises améliora nettement le temps de réponse des quelques machines concernées. Ce témoignage n’est pas une mesure générale du trafic Internet.

Le même appendice rapporte le travail sur BIND 4.9.2 ALPHA en 1993 : un TTL négatif de dix minutes, une distinction interne entre NXDOMAIN et NOERROR_NODATA, puis la conservation du SOA afin de rendre le négatif avec son contexte. Le standard n’effaça pas cette histoire en code. Il en transforma les leçons — bonne clé, SOA portable, durée décroissante — en comportement commun.

La performance retarde parfois la réparation

Une réponse négative locale réduit le délai et la charge des serveurs faisant autorité. Mais si l’opérateur crée le nom ou ajoute le type qui manquait, les résolveurs ayant mémorisé l’ancienne absence continuent légitimement à répondre « non » jusqu’à leur échéance.

Les caches n’ont pas tous reçu la réponse au même instant, et certains imposent une durée maximale plus courte. Il n’existe donc pas une seconde mondiale où l’absence disparaît partout. RFC 2308 estime raisonnables des valeurs par défaut d’une à trois heures et juge problématiques celles qui dépassent une journée, bien que le champ numérique puisse exprimer beaucoup plus.

La nature de l’erreur compte également pour les applications. Un NXDOMAIN injecté peut faire rejeter immédiatement un courrier, tandis qu’une mauvaise adresse peut le laisser en file d’attente assez longtemps pour qu’une réparation intervienne. Une panne convertie à tort en non-existence transforme un incident réversible en décision aval parfois irréversible.

De la réponse mémorisée à la plage prouvée

DNSSEC élargit ensuite la surface de preuve. NSEC relie les noms existants dans l’ordre canonique et énumère les types présents. Avec les règles de validation de RFC 4035, un résolveur peut vérifier l’absence d’un nom dans un intervalle ou l’absence d’un type à un nom existant.

NSEC facilite aussi l’énumération d’une zone. RFC 5155 introduisit NSEC3, qui emploie des noms hachés et permet le mode Opt-Out. Une plage NSEC3 Opt-Out ne prouve pas l’existence ou l’inexistence de chaque délégation non signée qu’elle couvre ; cette exception doit rester visible dans toute conclusion.

RFC 8020 précisa plus tard qu’un NXDOMAIN sur un nœud coupe aussi le sous-arbre qui devrait se trouver sous lui. Cette propriété ne transforme pas NODATA en coupure : un nom existant sans un type peut avoir d’autres types et des descendants.

RFC 8198 autorisa enfin un résolveur validant à synthétiser un nouveau négatif à partir de preuves NSEC ou NSEC3 déjà en cache. Une seule preuve signée peut ainsi éviter plusieurs consultations exactes. L’économie augmente, tout comme la portée d’une mauvaise durée : un nom créé dans l’intervalle peut rester invisible tant que la preuve négative est valable.

La signature établit l’origine et l’intégrité dans la chaîne DNS. Elle ne décide pas qui mérite un nom, ne prouve pas la disparition d’une organisation et ne change pas un choix destructeur mais correctement signé en vérité institutionnelle.

Sources et limites des preuves

Ces RFC documentent les contrats et certaines expériences citées, pas un recensement complet des déploiements. Les règles DNSSEC, la coupure NXDOMAIN et la synthèse agressive appartiennent à des étapes postérieures et ne doivent pas être projetées dans les résolveurs de 1987 ou de 1998.