Résumé

  • La RFC 8767 n'annule pas le TTL : elle autorise, après l'échec d'une tentative loyale de rafraîchissement, l'usage temporaire et borné d'une donnée DNS expirée.
  • Le TTL d'origine, la durée maximale de conservation périmée, l'attente du client, le TTL renvoyé, la validité DNSSEC, le signal EDE et les nouvelles tentatives correspondent à des preuves différentes.
  • La contribution de David C. Lawrence s'inscrit dans un mécanisme collectif de l'IETF. Ni l'auteur, ni le résolveur, ni la copie en cache n'acquièrent le pouvoir de la source autoritative.

Le client ne voit qu'une réponse. Pour le résolveur, l'instant est beaucoup plus ambigu : la minuterie ordinaire vient d'atteindre zéro, la source ne fournit rien d'utilisable et une ancienne valeur reste disponible en mémoire. La renvoyer peut éviter une panne. La renvoyer sans expliquer son âge et les tentatives de reprise peut aussi masquer un changement voulu par le titulaire du nom.

La RFC 8767, signée par David C. Lawrence, Warren Kumari et Puneet Sood en mars 2020, donne une forme opérationnelle à ce compromis. Elle ne transforme pas une donnée périmée en donnée actuelle. Elle crée un état d'exception dans lequel la continuité reste subordonnée à la provenance et au retour de l'autorité.

Conserver n'est pas encore répondre

Dans la logique ordinaire du DNS, le TTL indique pendant combien de temps un enregistrement peut être utilisé depuis le cache avant de consulter de nouveau la source. Les RFC 1035 et 2181 font de cette limite un élément de l'intention publiée : au-delà, le résolveur ne peut pas présenter la valeur comme actuelle.

L'implémentation peut néanmoins garder les octets après l'échéance. Ils servent au diagnostic, à la comparaison ou à une procédure de continuité. La présence en mémoire et l'autorisation de répondre doivent rester deux états distincts. C'est précisément l'espace que la RFC 8767 encadre.

Une donnée reçue avec un TTL nul ne bénéficie pas de cette exception. Son producteur a demandé qu'elle ne soit pas réutilisée depuis un cache. Inventer ensuite une durée « périmée » reviendrait à contredire directement cette instruction.

Le premier reçu doit donc exister avant la panne : nom, type, classe, source de la réponse, valeur reçue, TTL initial, heure d'insertion, échéance ordinaire et état de validation. Sans ces éléments, l'expression « dernière bonne réponse » est invérifiable. On ignore quelle réponse a été servie, depuis combien de temps et sur quelle base elle avait été jugée bonne.

La source autoritative conserve la priorité

La possibilité d'utiliser une copie proche ne permet pas de la préférer par confort. La RFC exige un effort récent et de bonne foi pour obtenir des données fraîches. Le résolveur interroge le chemin autoritatif, attend selon son budget de réponse et ne passe à l'ancienne valeur qu'après un échec ou un délai dépassé. Si une tentative toute récente a déjà établi la panne amont, les demandes suivantes peuvent éviter de refaire patienter chaque client.

Cet ordre protège la faculté du propriétaire de modifier le DNS. Une adresse déplacée d'urgence, un service retiré ou une preuve DNS liée à un certificat doivent redevenir visibles dès que la source fonctionne. Répondre systématiquement par le cache avant de solliciter l'autorité ferait de la résilience une substitution permanente.

La « bonne foi » doit laisser des traces : serveurs contactés, transport, heure de départ, durée, résultat, catégorie d'erreur et état de panne récent éventuellement réutilisé. Un silence réseau, un SERVFAIL, une réponse négative autoritative et un échec de validation DNSSEC n'ont pas le même sens.

Surtout, une réponse périmée réussie n'est pas une preuve de reprise. Le client a reçu une valeur, mais le défaut de la source persiste. La RFC 8767 impose de continuer les tentatives. La reprise n'est établie qu'après réception, examen et installation d'une nouvelle réponse autoritative utilisable.

Six horloges au lieu d'un « TTL périmé »

Une seule durée ne peut pas résumer la décision. Le TTL d'origine fixe la période de fraîcheur publiée par l'autorité. La RFC suggère en outre de plafonner à sept jours la valeur reçue utilisée dans certains calculs de rétention, afin qu'un TTL exceptionnel ne crée pas un horizon sans fin.

La durée maximale d'usage périmé est une politique locale du résolveur. Elle devrait être configurable ; le texte suggère une valeur de l'ordre de un à trois jours. Une fois cette borne franchie, la réponse n'est plus admissible au mécanisme même si elle existe encore sur disque.

Le budget d'attente du client fonctionne à une autre échelle, souvent en secondes. Il décide combien de temps la source peut tenter de répondre avant que la continuité prenne le relais. Le raccourcir réduit la latence perçue, mais augmente la probabilité qu'une réponse autoritative simplement lente perde la course.

Le TTL renvoyé avec la réponse périmée est encore différent. La RFC exige une valeur positive et recommande trente secondes. Ce nombre limite la réutilisation par le cache suivant ; il ne rajeunit pas la donnée et ne prolonge aucune signature.

DNSSEC ajoute les dates de début et de fin de validité cryptographique. Une valeur peut être expirée au sens du cache alors que sa signature reste valide, ou l'inverse. Enfin, la cadence de nouvelle tentative décide à quelle vitesse la source sera retrouvée sans lui imposer une tempête de requêtes.

Un dossier sérieux conserve donc séparément l'échéance ordinaire, la borne périmée, le temps d'attente, le TTL de réponse, l'intervalle de signature et la prochaine tentative.

Une signature ancienne reste une signature ancienne

La RFC 4035 oblige un résolveur validant à examiner la chaîne DNSSEC et l'intervalle temporel de la signature. Une réponse périmée peut encore obtenir l'état Secure si la preuve reste valide. Cet état atteste une origine cryptographique dans un intervalle donné ; il n'atteste pas que la valeur exprime encore l'intention actuelle du propriétaire.

Avec l'âge, les signatures expirent et les dépendances de validation peuvent changer. La RFC 8767 avertit donc que les échecs DNSSEC deviennent plus probables. Elle décrit aussi un risque sans contrefaçon : un adversaire capable de maintenir les serveurs autoritatifs hors d'atteinte peut prolonger l'usage d'une ancienne valeur pourtant correctement signée à l'origine.

La gravité dépend de l'action consommatrice. Obtenir une page pendant une panne et délivrer un certificat sur la base d'un défi DNS n'ont pas la même réversibilité. La RFC déconseille aux autorités de certification d'utiliser un résolveur périmé pour cette validation. Le gain de disponibilité ne vaut pas autorisation universelle.

Les réponses négatives exigent la même discipline. Un ancien résultat positif peut envoyer les utilisateurs vers une destination retirée ; un ancien NXDOMAIN peut rendre invisible un nom qui vient d'être créé. L'absence est aussi une affirmation datée.

EDE rend l'exception visible sans la réparer

La RFC 8914, également coécrite par Lawrence, définit les erreurs DNS étendues. Le code 3 signifie Stale Answer et le code 19 Stale NXDOMAIN Answer. Un client ou un outil compatible peut alors savoir que le résolveur a utilisé une valeur périmée.

Ce signal ne change pas à lui seul le RCODE. Il n'authentifie rien, n'explique pas la cause de la panne amont, ne rallonge pas une signature et ne garantit pas que l'application l'a lu. De nombreux logiciels continueront à ne regarder que l'adresse ou la réponse négative.

EDE est donc un témoin, pas un remède. Il permet de compter les réponses exceptionnelles et d'appliquer une politique plus stricte à certaines opérations. Le résolveur doit toutefois conserver son propre reçu, même si aucun client ne comprend l'option.

Un compteur de code 3 isolé reste pauvre. Il doit être relié à l'objet de cache, à la tentative de rafraîchissement, à l'âge, au TTL renvoyé, à l'état DNSSEC et au moment où une donnée fraîche a remplacé l'ancienne.

Les implémentations montrent les choix locaux

La RFC 8767 mentionne un premier correctif pour BIND 9.7.0, un usage en production rapporté par Akamai depuis 2011, puis des implémentations dans BIND 9.12 et versions ultérieures, Unbound et Knot Resolver. Cette histoire explique pourquoi le texte parle d'expérience collective plutôt que d'une simple hypothèse de disponibilité.

Elle ne prouve aucune uniformité. La documentation actuelle d'Unbound indique que le comportement de la RFC 8767 est activé par défaut depuis la version 1.23.0. Elle décrit notamment une attente client de 1,8 seconde, une réponse périmée à la place de SERVFAIL, une durée maximale par défaut d'un jour, un TTL renvoyé de trente secondes et la poursuite de la résolution.

Ces chiffres appartiennent à une version et à une configuration. Ils ne sont ni des obligations de l'IETF, ni la description de tous les déploiements. Une mise à niveau ou un réglage local peut les changer.

La preuve vient alors du code en fonctionnement : logiciel, version, paramètres effectifs, transition par requête et réponse observée sur le réseau. Un essai doit couvrir la source saine, le silence, SERVFAIL, l'échec DNSSEC, la récupération avant et après la borne, la modification de la valeur et le TTL nul. Le manuel dit ce qui peut se produire ; la trace dit ce qui s'est produit.

Une carrière documente une contribution, pas un pouvoir

Le profil IETF de David C. Lawrence, connu sous le pseudonyme « tale », répertorie les RFC 3425, 7871, 8767 et 8914. Il le présente actuellement comme coprésident du groupe Adaptive DNS Discovery, représentant de l'IETF auprès du conseil d'administration d'ICANN et relecteur dans plusieurs directorates.

La page actuelle du conseil d'ICANN précise que David Lawrence est représentant non votant de l'IETF depuis le 14 novembre 2024. Sa biographie passe par RPI et Usenet, UUNET, la réécriture de BIND à l'ISC, Nominum, treize ans chez Akamai, un rôle de Trusted Community Representative pour la clé racine DNSSEC en 2010, le conseil de DNS-OARC et celui de CVFiber.

Ces repères situent une longue participation à l'exploitation, aux normes et à la liaison institutionnelle. Ils ne font pas de Lawrence l'inventeur unique du mécanisme, le propriétaire d'un résolveur ni le décideur d'ICANN. La RFC a trois auteurs et résulte d'un travail plus large.

La limite ressemble à celle du cache : une personne peut contribuer à une fonction collective sans recevoir le contrôle des systèmes qui l'appliquent ; une copie peut préserver une fonction sans devenir la source.

Le reçu doit se terminer par une reprise autoritative

Le dossier minimal assemble d'abord l'objet de cache : nom, type, classe, source, TTL, heures d'insertion et d'expiration, empreinte de la valeur et validation DNSSEC. Il ajoute la tentative récente : cibles, transport, durée, réponse ou échec et éventuelle mémoire d'une panne précédente.

Viennent ensuite la politique et la décision : durée maximale, échéance calculée, âge de la donnée, budget du client, TTL renvoyé, code EDE, exception appliquée et prochaine tentative. Aucun champ ne doit être déduit d'un autre.

La dernière partie prouve la reprise : première réponse autoritative utilisable, résultat de validation, empreinte de la nouvelle valeur, installation en cache, retrait de l'état périmé et effet observé. Si la valeur a changé, l'historique doit conserver ce que les clients ont reçu pendant l'interruption.

C'est une manière de protéger le registre de décision plutôt que de sacraliser le gardien temporaire. Le résolveur maintient l'accès, mais ne s'attribue pas le nom. La continuité reste légitime tant que la provenance, l'âge, la limite et le retour vers la source demeurent prouvables.

Sources