Résumé

  • RFC 8767 autorise un résolveur récursif à restituer une donnée expirée lorsque sa tentative sérieuse de rafraîchissement auprès des autorités échoue ; ce choix appartient au résolveur, pas à l'éditeur de la zone.
  • La décision reste défendable seulement si l'on distingue le TTL d'origine, l'âge maximal de péremption, le petit TTL remis dans la réponse, la validité DNSSEC, la cause de l'échec et la preuve du retour à la normale.

Le retrait paraît terminé. Une équipe de sécurité a supprimé d'une zone l'adresse d'un service compromis. Le TTL annoncé auparavant arrive à son terme. Pourtant, un utilisateur reçoit encore l'ancienne adresse. Ce n'est pas nécessairement une autorité secondaire en retard : son résolveur récursif avait conservé l'enregistrement et, incapable de joindre les serveurs faisant autorité, a choisi de le servir périmé.

La scène est illustrative. Elle ne décrit ni un incident réel ni le comportement par défaut d'un produit. Elle révèle une tension plus utile : une mesure conçue pour préserver la disponibilité peut prolonger un état que l'éditeur ne souhaite plus publier.

RFC 8767 organise cette possibilité sous le nom de Serve Stale. Le mécanisme n'efface pas l'expiration. Il donne au résolveur une latitude locale, bornée, lorsqu'il ne peut pas rafraîchir la donnée. Autrement dit, le TTL cesse d'être l'unique horloge visible, mais il ne perd pas sa signification.

Après l'expiration, l'autorité change de main

Avant l'échéance, le cache réutilise une donnée dans le cadre ordinaire fixé par son TTL. À l'échéance, la source devrait être consultée de nouveau. Si cette consultation échoue, RFC 8767 permet au résolveur de traiter temporairement la copie conservée comme si elle n'était pas expirée.

Le mot important est « temporairement ». L'éditeur de la zone n'a pas rallongé son TTL. C'est l'opérateur du résolveur qui ouvre une exception de continuité. Cette séparation permet d'attribuer les responsabilités : l'éditeur répond de l'état autoritatif et de son accessibilité ; le résolveur répond de la durée, du périmètre et de la traçabilité de l'exception.

Deux limites sont souvent confondues. Le plafond du TTL de cache réduit éventuellement un TTL reçu jugé excessif. RFC 8767 recommande un ordre de grandeur de quelques jours à quelques semaines, avec sept jours comme valeur indicative. Le délai maximal de donnée périmée commence ailleurs : il fixe combien de temps, après l'expiration calculée, une copie peut encore être retenue pour Serve Stale. Le texte évoque une valeur configurable et explique qu'une fenêtre d'un à trois jours peut couvrir beaucoup d'incidents. Il ne décrète pas une politique universelle.

Une preuve exploitable doit donc conserver l'heure d'insertion, le TTL original, l'heure exacte d'expiration, l'âge au moment de la réponse, la limite maximale configurée et le TTL placé dans la réponse au client. Sinon, un simple « TTL 30 » peut être lu à tort comme une fraîcheur de trente secondes alors qu'il ne s'agit que du délai court associé à une réponse déjà périmée.

Quatre temporisateurs, quatre arbitrages

RFC 8767 ne cherche pas à imposer un algorithme unique. Sa méthode d'exemple distingue quatre temporisateurs car ils protègent des intérêts différents.

Le délai de réponse au client borne l'attente avant qu'une réponse périmée ne soit préférée à l'échec ; la valeur indicative est de 1,8 seconde. Le délai de résolution borne le travail itératif total et se situe couramment entre dix et trente secondes. Le délai de nouvelle vérification évite de frapper sans cesse une autorité déjà défaillante ; trente secondes sont recommandées dans l'exemple. Enfin, le délai maximal de péremption fixe la limite absolue au-delà de laquelle la copie ne peut plus servir.

Réduire ces quatre paramètres à un seul bouton « stale » rend le choix illisible. Un délai client très court améliore la réactivité, mais risque de préférer l'ancien lorsque l'autorité est seulement lente. Une vérification trop espacée limite la charge pendant une attaque, mais retarde la détection du rétablissement. Une longue rétention traverse une panne grave, mais conserve davantage d'états abandonnés.

Le résolveur doit avoir récemment tenté un rafraîchissement de bonne foi. Le mécanisme n'autorise pas à servir systématiquement l'ancien puis à vérifier après coup par confort. Même après avoir répondu au client, le résolveur est censé poursuivre la résolution jusqu'à la fin de son propre délai. La réponse périmée est donc un événement au milieu d'une procédure de récupération, non son résultat final.

« Échec du rafraîchissement » n'est pas un diagnostic unique

Une réponse autoritative NOERROR ou NXDOMAIN, avec le bit AA, renouvelle l'état selon RFC 8767. Cette règle est cruciale. Si un éditeur supprime volontairement un nom, le résolveur ne doit pas conserver l'ancienne réponse positive sous prétexte que la continuité lui semble préférable. Il ne sait généralement pas distinguer un retrait voulu d'un NXDOMAIN accidentel.

À l'inverse, une temporisation, une route indisponible, SERVFAIL, REFUSED, une réponse mal formée, une validation DNSSEC en échec ou une délégation défectueuse n'attribuent pas la même cause. Les fusionner sous une étiquette « DNS amont en panne » empêche de savoir qui peut rétablir le service. RFC 2308 borne aussi la mise en cache des indications de serveur défaillant ou injoignable à cinq minutes.

Le journal de décision devrait donc montrer chaque serveur interrogé, son adresse, le transport, les heures, le RCODE, le bit AA, le résultat DNSSEC, les erreurs réseau et l'éventuelle reprise de la délégation. Il devrait aussi conserver RD, CD et DO, le type de réponse et la clé de cache. Deux résolveurs peuvent légitimement répondre différemment au même client parce qu'ils n'ont ni le même historique ni la même politique.

Le TTL remis au client ne rajeunit pas la donnée

Lorsqu'un résolveur sert des enregistrements expirés, RFC 8767 exige un TTL positif et recommande trente secondes. Un TTL nul a produit des incompatibilités ; une valeur trop courte peut déclencher une rafale de nouvelles requêtes et aggraver l'incident. Ces trente secondes ralentissent les redemandes en aval.

Elles ne constituent pas un nouvel engagement de l'autorité. Un résolveur relais peut recevoir cette réponse et la remettre en cache, mais l'observateur ne doit pas confondre le petit TTL visible avec l'âge réel de l'enregistrement. L'identité du résolveur source, l'ancienneté de sa copie et sa dernière tentative de rafraîchissement restent indispensables.

Les erreurs DNS étendues de RFC 8914 apportent un indice. Le code 3 signale une réponse périmée ; le code 19 vise un NXDOMAIN périmé ; le code 22 indique qu'aucune autorité n'est joignable. Ces informations peuvent accompagner un NOERROR et éclairer les journaux.

Mais EDE n'est pas une permission. Il ne modifie pas le traitement du RCODE, peut être retiré ou reformulé par un intermédiaire et n'est pas authentifié sans protection de la transaction ou du canal. Observer le code 3 prouve seulement que l'émetteur a qualifié sa réponse de périmée. Cela ne prouve pas ses horloges internes ni les requêtes qu'il affirme avoir tentées.

DNSSEC conserve sa propre échéance

Un RRset a pu être validé à son entrée dans le cache et ne plus l'être au moment de sa réutilisation. Les dates de début et de fin d'un RRSIG ne se confondent ni avec le TTL ni avec la fenêtre maximale de Serve Stale. Plus la copie survit, plus le risque de franchir la date de validité augmente.

Le bit AD doit refléter l'état cryptographique actuel, pas le souvenir d'une validation réussie. Le dossier de preuve doit garder les dates du RRSIG, l'instant de validation, l'état des ancres de confiance et le traitement de CD/DO. Une adresse correctement signée peut par ailleurs conduire vers un service qui n'est plus sûr : l'authenticité de l'ancien RRset ne garantit pas la légitimité actuelle de sa destination.

Les réponses négatives méritent un traitement spécifique. Un NXDOMAIN périmé peut cacher un nom nouvellement créé. Une ancienne preuve NSEC ou NSEC3 peut retarder un changement de DS ou TLSA. L'usage agressif du cache validé décrit par RFC 8198 est distinct : il synthétise une réponse à partir d'une preuve négative encore admissible. Serve Stale demande si cette preuve peut continuer après son expiration ordinaire lorsque le rafraîchissement échoue.

Sources