Résumé

  • RFC 8767 maintient le rôle du TTL : à son expiration, la source doit de nouveau être consultée. La donnée ancienne ne devient éligible qu’après l’impossibilité d’obtenir un rafraîchissement faisant autorité.
  • Quatre budgets temporels gouvernent le mécanisme : attente utile du client, travail total de résolution, délai avant une nouvelle tentative et âge stale maximal. Ils ne peuvent pas être audités par un simple état « activé ».
  • Une réponse stale est une projection locale d’un état passé. Le journal doit relier RRset d’origine, échec amont, validité DNSSEC, TTL court de réponse, EDE éventuelle, rafraîchissement poursuivi et résultat applicatif.

Le colis partit vers l’ancien quai

Une plateforme logistique change l’adresse d’un service qui assigne les quais de chargement. L’ancien site reste actif pendant la bascule, puis son adresse est remise à un autre environnement. Le matin d’une panne de connectivité vers les serveurs faisant autorité, un résolveur d’entreprise possède encore l’ancienne réponse A, expirée depuis une heure.

Renvoyer une erreur bloque les entrepôts. Renvoyer l’ancienne adresse peut sauver l’exploitation si la période de recouvrement continue. Il peut aussi diriger des jetons d’accès et des instructions vers un système qui ne fait plus partie du service. Le résolveur ne connaît ni le contrat de migration ni la garde actuelle de l’adresse. Il possède seulement une observation passée et la preuve incomplète qu’il n’a pas réussi à la remplacer.

La bonne question n’est donc pas : « l’ancienne réponse fonctionne-t-elle encore ? » Un paquet réussi ne prouve ni la fraîcheur ni la garde légitime. La question est : quelle exception le résolveur était-il autorisé à produire après quelle tentative de consultation, pour quelle durée, et comment cette exception peut-elle cesser dès qu’un nouvel état faisant autorité apparaît ?

L’expiration déclenche une obligation avant d’ouvrir une exception

RFC 1035 liait le TTL au moment où la source devait être consultée de nouveau et où le RR devait être écarté. RFC 2181 parlait d’une durée de vie maximale. RFC 8767 modifie explicitement cette définition : le RR peut être mis en cache pendant son TTL ; lorsque celui-ci expire, la source doit être consultée ; si la donnée ne peut pas être rafraîchie par une réponse faisant autorité, elle peut être utilisée comme si elle n’était pas expirée selon les conditions du mécanisme.

Le verbe important est « consulter ». Serve-stale n’accorde pas un droit permanent d’ignorer le TTL publié. Il commence après l’échec d’une obligation de rafraîchissement. Servir systématiquement l’ancien objet puis essayer l’amont en arrière-plan transforme une exception de résilience en préférence ordinaire pour le passé.

Un TTL de zéro reste hors du mécanisme. La donnée destinée à la seule transaction en cours ne doit pas être mise en cache et ne peut donc pas devenir un secours ultérieur. Il faut aussi distinguer le plafond du TTL reçu — RFC 8767 recommande un ordre de grandeur de sept jours — du maximum stale, qui commence après l’expiration normale. Le premier limite l’entrée publiée ; le second limite le pouvoir local du résolveur.

Les quatre délais racontent quatre décisions

Le client response timer fixe le temps pendant lequel un rafraîchissement normal peut être tenté avant que la réponse ne perde sa valeur pour le client. L’exemple de RFC 8767 propose environ 1,8 seconde. Une valeur trop courte préfère le cache ancien à une autorité simplement lente ; une valeur trop longue protège la fraîcheur mais dépasse le délai de l’application.

Le query resolution timer limite l’ensemble du travail récursif, couramment dix à trente secondes dans la discussion du RFC. Il continue après l’envoi de la réponse stale. Répondre au client et réparer le cache ont des échéances différentes.

Le failure recheck timer évite qu’une foule de requêtes répète immédiatement un échec connu. L’exemple recommande de ne pas réessayer plus souvent que toutes les trente secondes et rappelle une limite de cinq minutes. RFC 9520 rend obligatoire le cache des échecs de résolution, entre une seconde et cinq minutes, avec backoff recommandé. Ce cache décrit l’impossibilité actuelle de résoudre ; il ne contient pas la vérité du nom.

Le maximum stale timer détermine combien de temps après l’expiration un objet reste candidat au secours. Un à trois jours est la suggestion de l’exemple. Une longue conservation absorbe des pannes étendues, mais prolonge également d’anciennes adresses, délégations ou négations et consomme de la mémoire.

Une politique sérieuse enregistre les quatre valeurs, leur instant de départ et leur résultat. Elle distingue une réponse immédiate fondée sur un échec récent, une réponse après attente du client, une requête amont encore active et un objet qui a finalement dépassé son âge stale. Sans cette chronologie, le mot « résilient » n’est pas vérifiable.

Ce qui remplace l’ancien état

Pour RFC 8767, une réponse faisant autorité, avec AA et un RCODE NOERROR ou NXDOMAIN, doit rafraîchir l’état. Les autres RCODE devraient être traités comme un échec de rafraîchissement et laisser l’ancien état en place.

Ainsi, un SERVFAIL transitoire ne détruit pas la dernière réponse utilisable. À l’inverse, un nouveau NXDOMAIN faisant autorité peut mettre fin à une ancienne réponse positive. Le résolveur ne sait pas si la suppression est volontaire ou accidentelle. Il n’a pas le mandat d’opposer sa mémoire à une négation actuelle.

REFUSED est plus ambigu : retrait volontaire, ACL erronée, serveur qui n’est plus compétent. Le RFC permet à l’implémentation de décider si un REFUSED provenant de toutes les autorités doit empêcher l’usage stale. Cette différence doit figurer dans la matrice de version ; elle ne se déduit pas du nom de l’option.

L’échec mis en cache par RFC 9520 doit rester un objet distinct. Il supprime temporairement des requêtes amont identiques. Il ne prouve ni existence, ni absence, ni valeur. Un tableau de bord qui affiche seulement « cache hit » confond une donnée et la preuve qu’aucune donnée utile n’a pu être obtenue.

Le TTL court de réponse appartient au résolveur

Une réponse contenant des RR expirés doit leur donner un TTL supérieur à zéro ; trente secondes sont recommandées. Ce TTL n’est pas une nouvelle durée de vie délivrée par la zone. Il limite la copie downstream de la projection stale choisie par le résolveur et réduit les nouvelles requêtes immédiates.

Il faut conserver le TTL original, l’insertion, l’expiration ordinaire, l’âge stale, le TTL de réponse et la cause du fallback. Sinon un TTL=30 frais et un TTL=30 construit à partir d’une donnée vieille de plusieurs heures deviennent indiscernables.

RFC 8914 ajoute l’EDE 3 pour une réponse stale et l’EDE 19 pour un NXDOMAIN stale. L’EDE 7 décrit une signature expirée. Ces codes améliorent le diagnostic, mais ne changent pas le traitement du RCODE. Ils n’obligent pas un stub à refuser la donnée, à afficher un avertissement ou à changer de résolveur. Une EDE est une pièce du dossier, pas un consentement du client.

Une absence ancienne peut bloquer une présence nouvelle

L’ancien A conserve une destination. L’ancien NXDOMAIN conserve une absence. Ce dernier peut neutraliser une action de reprise précisément au moment où elle est publiée.

Un opérateur peut créer un nom d’urgence, publier un nouveau DS ou TLSA, ou réparer une délégation. Si le résolveur conserve un NXDOMAIN, un NSEC ou un NSEC3 expiré et ne peut joindre l’autorité, l’ancien espace négatif continue de s’exécuter. L’utilisateur ne voit pas forcément une panne : il reçoit une négation propre et rapide.

La politique d’éligibilité doit donc tenir compte de la fonction de la donnée. Une adresse de contenu, un contrôle de certificat, une délégation et un mécanisme de révocation ne portent pas le même coût de vieillissement. Si l’implémentation ne sait pas exprimer une exception assez précise, la surface activée doit être réduite.

Le temps DNSSEC reste indépendant

RFC 4035 exige que l’heure courante du validateur soit comprise entre l’inception et l’expiration du RRSIG. Le maximum stale ne prolonge pas cette période. Un RRset peut rester stocké alors que sa preuve cryptographique a changé d’état.

Il faut compter séparément stale avec signature encore valide, stale avec signature expirée, échec de validation et éventuelle exception non sécurisée. Une seule métrique « DNSSEC actif » ne révèle pas ce qui a été rendu au client.

L’indisponibilité peut aussi être provoquée. Un attaquant capable de maintenir les autorités hors d’atteinte peut prolonger une ancienne adresse ou une ancienne négation. RFC 8767 évoque le cas d’adresses abandonnées qui restent utiles à une fraude de validation de domaine. Le mécanisme ne crée pas l’abandon ; il choisit combien de temps l’ancienne liaison reste opérationnelle pendant l’échec.

Les produits n’exécutent pas la même phrase

La documentation BIND actuelle sépare la rétention stale, son retour, le TTL de réponse, l’âge maximal, le rythme de refresh et le contrôle runtime rndc serve-stale. Elle documente trente secondes pour le TTL de réponse et un jour pour le maximum stale lorsque le mécanisme est actif. Son option de délai client est désactivée par défaut et la version documentée n’accepte que zéro lorsqu’elle est activée : retour immédiat, et non attente de 1,8 seconde déduite du nom.

Unbound expose la famille serve-expired-*, avec âge, TTL de réponse, attente client et reset après échec. Sa documentation actuelle distingue le mode immédiat du comportement qui essaie d’abord le rafraîchissement. Les valeurs et transitions de version appartiennent au produit.

La preuve est donc un canary par release : autorité rapide, lente, muette, SERVFAIL, REFUSED, nouveau NXDOMAIN ; positif et négatif ; RRSIG valide puis expiré ; TTL zéro ; pression cache ; redémarrage ; override runtime. On observe l’attente, les paquets amont, la réponse, l’EDE, le refresh poursuivi, le remplacement et la connexion applicative.

Sources