Résumé

  • Dans une requête RFC 9664, la durée est un souhait ; dans la réponse réussie, LEASE et KEY-LEASE sont la décision effective du serveur faisant autorité.
  • L’expiration borne la publication autoritative, mais ne certifie ni le fonctionnement du service, ni la convergence de la flotte, ni la disparition d’une réponse déjà mise en cache.

Prenons un cas volontairement illustratif. Un appareil demande trente minutes pour les enregistrements qui annoncent son service. La mise à jour DNS est authentifiée, les prérequis RFC 2136 sont satisfaits et le serveur répond sans erreur. Mais il accorde quatre heures. Vingt minutes plus tard, l’appareil s’éteint sans supprimer son inscription et sans la renouveler.

Pendant le reste des quatre heures, la réponse autoritative peut rester conforme au bail tout en dirigeant les clients vers un service absent. Rien, dans ce scénario, n’est une anomalie de format ou une violation de RFC 9664. La tension vient précisément d’un échange valide : le demandeur propose une durée, le serveur en décide une autre, plus courte, identique ou plus longue.

Une écriture, une durée, une réalité : trois preuves

L’option Update Lease est transportée dans le pseudo-enregistrement OPT d’EDNS(0), au sein d’un DNS UPDATE ordinaire. Le protocole de base conserve sa logique atomique : la zone visée, les prérequis et les modifications forment la décision d’admission. Si un prérequis échoue, l’ensemble n’est pas appliqué.

L’admission répond à « cette identité peut-elle effectuer cette modification sur cet état de zone ? ». Le bail répond à « combien de temps le serveur promet-il encore de publier ces enregistrements sans renouvellement ? ». La sonde applicative répond seule à « le service annoncé fonctionne-t-il ? ».

TSIG ou SIG(0) peuvent authentifier la transaction. Une politique de mise à jour peut limiter la clé à certains noms ou types. Ces contrôles sont indispensables, mais ils ne regardent pas si le processus tourne, si le port répond, si la route est utilisable ou si une transaction métier aboutit. Une signature valide ne transforme pas une annonce périmée en service vivant.

Il faut donc conserver le message exact : sections Zone, Prerequisite, Update et Additional Data, identité TSIG ou SIG(0), résultat de politique, forme de l’option, valeurs souhaitées, RCODE et valeurs renvoyées. Une ligne « bail accepté » élimine l’information essentielle : qui a accordé quel temps.

Quatre octets ou huit : la continuité du nom n’est pas celle du service

La forme de quatre octets ne porte qu’un LEASE de 32 bits. Il s’applique à tous les enregistrements de la section Update, y compris KEY. La forme de huit octets ajoute KEY-LEASE : les enregistrements ordinaires suivent le premier délai, les KEY le second.

Cette séparation sert notamment au Service Registration Protocol de RFC 9665. Les enregistrements de découverte peuvent expirer tandis que la KEY réserve encore le nom au même détenteur cryptographique. Le service n’est plus annoncé, mais un autre demandeur ne récupère pas immédiatement le nom. Cette conservation est une protection de continuité nominale, pas une preuve de présence.

La compatibilité peut ramener deux délais à un seul. Un serveur recevant la forme courte doit l’appliquer aux deux catégories. Un demandeur qui avait envoyé huit octets mais reçoit quatre doit faire de même. Seule la réponse observée permet donc de dire si la distinction voulue a survécu.

Une suppression explicite est différente : les enregistrements retirés par la mise à jour le sont durablement. Le bail n’est pas une corbeille temporaire qui les restaurerait plus tard.

Le serveur rend le temps exécutable

Un serveur qui prend en charge l’option doit la renvoyer lorsqu’il accepte une requête qui la contient. Le demandeur calcule ensuite son renouvellement à partir de la durée accordée, vers 80 % du bail plus un aléa de 0 à 5 %. Cette dispersion évite qu’une population de machines ne se réveille au même instant et laisse une marge pour retransmettre.

Le calcul n’est pas la preuve du renouvellement. Il faut l’heure prévue, l’aléa choisi, les tentatives d’envoi, la réponse authentifiée et le nouveau délai accordé. Une tâche planifiée ne signifie pas que le serveur a prolongé l’inscription.

Si la réponse réussit sans l’option, le RFC y voit l’indication d’un serveur non compatible. Le demandeur devrait néanmoins poursuivre les renouvellements comme si sa demande avait été retournée. Ce comportement évite un abandon brutal côté client ; il ne démontre aucun mécanisme d’expiration côté serveur. Le bon état opérationnel est « renouvellement de compatibilité, nettoyage serveur non prouvé ».

RFC 9664 sépare aussi l’inscription du renouvellement. Le premier ajoute une information supposée absente ; le second prolonge un état existant sans le changer. Après une perte d’état du serveur, par exemple un redémarrage, un renouvellement bien construit peut réintroduire les enregistrements. S’il modifie alors la zone, le numéro de série doit évoluer. S’il ne modifie rien, le renouvellement ne doit pas l’incrémenter.

L’autorité a expiré, le cache répond encore

À l’échéance sans renouvellement, le serveur ne doit plus retourner l’enregistrement. Il peut effacer les octets de sa base, mais cette suppression physique n’est pas obligatoire. Le résultat d’une requête et l’état du stockage sont deux preuves différentes.

Le TTL ouvre une autre chronologie. Un résolveur ayant obtenu une réponse juste avant l’échéance du bail peut la réutiliser jusqu’à épuisement de son TTL restant. Le bail stoppe les nouvelles réponses autoritatives ; il ne rappelle pas celles déjà copiées. Inversement, un TTL court ne met pas fin à l’inscription conservée par le serveur.

Il faut donc suivre au moins le terme du bail, le calendrier de renouvellement, la propagation dans le signataire et les secondaires, puis le TTL vu par chaque cache. Si le registraire est un primaire caché, son état correct ne prouve pas celui des serveurs publics ou des sites anycast.

Des bornes locales plutôt qu’un faux chiffre universel

Un bail trop long ressemble à une absence de bail : la donnée périmée subsiste. Un bail trop court multiplie les renouvellements et peut faire disparaître un service sain au premier retard. RFC 9664 recommande comme maxima par défaut 24 heures pour LEASE et sept jours pour KEY-LEASE, ainsi qu’un minimum par défaut d’au moins 30 secondes ; il indique qu’une heure ou davantage convient généralement mieux. L’opérateur peut adapter ces limites.

Ces valeurs ne sont ni une promesse client ni un objectif universel. Elles montrent que l’autorité sur le temps reste locale au serveur. La politique doit être versionnée, observable et reliée aux capacités de récupération. La clé d’authentification doit, elle aussi, avoir un périmètre étroit : l’expiration limite la durée d’une donnée injectée, mais ne corrige pas une clé capable de modifier toute la zone.

Sources