Résumé

  • Le RFC 8767 permet à un résolveur récursif de servir certaines données DNS après l’expiration de leur TTL si l’actualisation faisant autorité échoue ; une donnée reçue avec un TTL nul ne peut pas bénéficier de ce mécanisme.
  • La continuité gagnée n’est pas gratuite : pendant la panne, les temporisations et la politique du résolveur prennent provisoirement le pas sur la limite de fraîcheur publiée par l’opérateur de zone.
  • Les codes EDE peuvent signaler une réponse stale, mais ils restent diagnostiques. Ils n’authentifient ni la donnée ancienne ni la légitimité de la décision.

Analyse

Le cas difficile n’est pas celui d’une adresse qui reste manifestement correcte. C’est celui où personne ne peut le savoir à temps. Le TTL d’un enregistrement vient d’expirer. Les serveurs faisant autorité ne répondent plus. L’ancienne destination peut encore assurer le service, mais elle peut aussi avoir été désaffectée, réattribuée ou retirée pour des raisons de sécurité. Renvoyer une erreur interrompt l’accès ; renvoyer l’ancienne valeur prolonge un état que l’autorité voulait peut-être abolir.

La conception historique du DNS donne au TTL une fonction de frontière. Le RFC 1035 le présente comme l’intervalle pendant lequel un enregistrement peut rester en cache avant une nouvelle consultation de sa source, puis son élimination. Le RFC 2181 précise qu’il s’agit d’une durée maximale et non d’une obligation de conservation. Dans le fonctionnement ordinaire, l’opérateur de zone publie la durée, tandis que le résolveur cesse de réutiliser l’information lorsqu’elle expire.

Le RFC 8767 aménage une exception. Si le résolveur ne parvient pas à obtenir une actualisation faisant autorité, il peut conserver une donnée au-delà du TTL et l’utiliser comme si elle n’avait pas expiré. Ce droit n’autorise pas à répondre systématiquement avec le cache ancien avant d’essayer le réseau. Une tentative récente et de bonne foi doit avoir échoué, et la recherche de données actuelles doit continuer après l’envoi de la réponse stale, jusqu’à la fin du temps de résolution prévu.

Le TTL nul conserve une signification stricte. Une donnée marquée zéro ne vaut que pour la transaction en cours ; elle ne peut pas être stockée en vue d’un futur repli. À l’inverse, lorsqu’un résolveur renvoie effectivement des enregistrements expirés, il doit leur attribuer un TTL positif. Le RFC recommande 30 secondes, notamment pour éviter les comportements défectueux associés à zéro et pour freiner les requêtes immédiates des caches situés en aval.

Quatre horloges organisent le mécanisme. La temporisation de réponse au client fixe le moment où l’attente d’une donnée fraîche devient plus coûteuse qu’une réponse stale ; la méthode d’exemple propose environ 1,8 seconde. La temporisation de résolution borne l’effort total consacré à obtenir une réponse actuelle. La temporisation de nouvelle vérification limite la fréquence des tentatives vers des autorités défaillantes. Enfin, la durée stale maximale détermine combien de temps une donnée expirée demeure candidate ; le document évoque une plage opérationnelle d’un à trois jours.

Ces valeurs ne sont pas harmonisées par le protocole. Le RFC 8767 qualifie serve-stale d’opération locale au résolveur et laisse les paramètres aux implémentations et aux exploitants. Deux résolveurs conformes peuvent donc donner, au même instant, deux résultats différents pour le même nom : l’un préserve l’ancienne réponse, l’autre échoue. La divergence révèle une politique de risque, pas nécessairement une faute logicielle.

Le type de réponse faisant autorité détermine la sortie. Un NoError ou un NXDomain faisant autorité, avec le bit AA, actualise l’état et doit remplacer l’information précédente. Les autres codes ne décrivent généralement pas ce qui existe désormais au nom interrogé ; ils sont donc traités comme des échecs d’actualisation qui laissent le cache antérieur intact. Un SERVFAIL ne confirme jamais que l’ancienne adresse est juste. Il dit seulement que le résolveur n’a pas obtenu de réponse actuelle exploitable.

Il faut aussi séparer serve-stale du cache des échecs défini par le RFC 9520. Ce dernier oblige le résolveur à mémoriser temporairement un échec de résolution — au moins une seconde et jamais plus de cinq minutes — afin que des requêtes identiques ne déclenchent pas sans cesse le même travail en amont. Ce cache enregistre l’échec. Serve-stale réutilise une ancienne réponse. Le premier maîtrise la tempête de nouvelles tentatives ; le second choisit la donnée présentée au client.

Le RFC 8914 apporte une trace possible de cette décision. Le code Extended DNS Error 3 signifie « Stale Answer » et le code 19 « Stale NXDOMAIN Answer ». Cette information aide l’observation, mais elle ne constitue pas une preuve de confiance. Hors transaction DNS sécurisée, l’EDE n’est pas authentifié ; il ne doit d’ailleurs pas modifier le traitement du protocole. Il explique le chemin suivi sans garantir la validité de son résultat.

Le risque varie enfin selon la donnée. Une ancienne adresse A ou AAAA peut maintenir un service inchangé ou conduire vers un système qui n’aurait plus dû recevoir de trafic. Un ancien CNAME peut restaurer une dépendance retirée. Le RFC 8767 souligne aussi que des signatures expirées peuvent entraîner des échecs DNSSEC et que des preuves NSEC ou NSEC3 conservées peuvent retarder la prise en compte de nouveaux enregistrements TLSA ou DS. Une indisponibilité provoquée des autorités peut en outre prolonger la vie pratique d’informations anciennes.

Ces limites viennent des normes ; elles ne prouvent ni le réglage ni le résultat d’un opérateur nommé. Le dossier factuel n’établit aucun taux d’adoption, aucun gain de disponibilité propre à une flotte et aucun dommage observé. Il établit la chaîne de contrôle : l’autorité publie les données et leur TTL, le résolveur classe l’échec et règle ses temporisations, puis le client supporte le résultat.

Sources