Résumé

  • Publié en août 2026, le RFC 10037 autorise un serveur RDAP à ajouter ttl0_data aux objets domaine et serveur de noms. La valeur décrit le TTL provisionné dans la base du registre, pas le compte à rebours restant après une requête DNS.
  • Cette visibilité ne concentre pas le pouvoir. Politique du registre, configuration acceptée, zone publiée, caches récursifs et résultat applicatif demeurent cinq états à rapprocher séparément.

RDAP devient ici un témoin, non une horloge universelle. Un opérateur prépare un changement de serveurs de noms et abaisse le TTL à 300 secondes. Le portail confirme la demande, puis RDAP renvoie 300. Pourtant un résolveur ayant reçu l’ancien RRset avec 86 400 secondes continue légitimement son propre décompte. Un autre a déjà évincé sa copie. Un troisième, incapable de joindre l’autorité, peut conserver une réponse expirée selon une politique distincte.

Chaque observation est compatible avec la norme. L’erreur serait d’appeler l’une d’elles « l’état DNS » sans préciser son détenteur.

Le RFC 10037 est une norme proposée de l’IETF publiée en août 2026. Dans une réponse RDAP de domaine ou de serveur de noms, ttl0_data.values associe un mnémonique de type DNS, écrit en majuscules et enregistré par l’IANA, à un entier JSON compris entre zéro et 2^31−1. La réponse annonce ttl0 dans rdapConformance.

La restriction essentielle est explicite : le chiffre doit refléter le provisionnement de la base du registre, et non le TTL restant observé dans le DNS vivant. Cette phrase donne au champ sa valeur probante et sa limite.

Le droit de lire ne devient pas le droit d’écrire

L’extension est facultative. Un serveur RDAP peut ne rien publier. Un client ignorant ce membre doit le laisser de côté conformément au mécanisme d’extension du RFC 9083. Lorsqu’il l’implémente, il doit accepter tous les types DNS valides et renouveler sa connaissance de la liste IANA, afin de ne pas rejeter demain un type ajouté après sa version logicielle.

L’enregistrement de ttl0 dans le registre des extensions RDAP de l’IANA fixe un nom commun. Il ne prouve ni adoption, ni activation, ni politique client. Un registre peut publier son propre paramètre sans permettre au bureau d’enregistrement de le modifier.

Le RFC 9803 couvre ce versant d’écriture dans EPP. Le serveur décide des types autorisés et des bornes minimale, par défaut et maximale. Il peut refuser une demande, l’écarter pour la stabilité, changer la valeur hors bande ou la ramener automatiquement au défaut. Le RFC 10037 est complémentaire, mais il n’impose pas cette extension EPP.

La transparence de lecture n’est donc pas une délégation de politique.

Cinq états doivent être nommés

Le premier état est la règle : qui peut choisir un TTL, pour quel RRset, dans quelles limites et pour quelle durée. Le deuxième est la valeur acceptée dans la base du registre, celle que RDAP peut exposer. Le troisième est la zone effectivement produite et servie par chacune des autorités. Le quatrième est la copie détenue par un résolveur donné, avec son âge et ses règles locales. Le cinquième est le résultat attendu : résolution valide, chaîne DNSSEC correcte et service joignable.

Le RFC 2181 rattache le TTL au RRset et exige une valeur identique pour ses membres. Le RFC 1035 en fait l’intervalle ordinaire de conservation avant abandon. Le RFC 9499 rappelle qu’il s’agit d’un maximum : un cache peut raccourcir la durée ou supprimer la donnée plus tôt. Après éviction, il n’existe même plus de « reste » à interroger.

L’expiration ne garantit pas davantage une disparition instantanée. Le RFC 8767 définit une exception bornée pour servir une donnée périmée lorsqu’une actualisation de bonne foi échoue. Cette possibilité ne change pas la valeur enregistrée ; elle ajoute une décision locale après son expiration.

La fenêtre commence avec une publication prouvée

Abaisser un TTL au moment du remplacement des NS ou du DS est trop tard pour les copies déjà mises en cache. Le RFC 9803 recommande d’effectuer la baisse au moins un ancien TTL avant la modification prévue, en ajoutant le délai entre réception de la commande et publication réelle dans le DNS.

Une procédure défendable part donc de l’ancien RRset. Elle fait accepter la baisse, vérifie la valeur administrative, observe chaque serveur faisant autorité, puis démarre l’attente depuis cette preuve de publication. Ensuite seulement vient la modification du contenu. Des observations récursives diversifiées et un test du service complètent le constat. Le retour au TTL normal attend la stabilité et la conservation d’un chemin de retour.

Le bouton du portail ne lance pas le décompte de tous les caches. La réponse RDAP ne le lance pas davantage. Elle permet de dire où le registre en est, ce qui est déjà un progrès considérable.

Un chiffre court répartit aussi des coûts

Le demandeur apprécie un TTL court pour accélérer la bascule et le retour arrière. Le registre supporte davantage de requêtes et doit considérer l’usage abusif, notamment le fast flux. À l’inverse, un TTL très long peut prolonger une délégation frauduleuse lorsqu’un compte de bureau d’enregistrement a été compromis.

Ces tensions expliquent les limites et le pouvoir d’intervention du registre. Le champ RDAP rend une décision visible ; il ne certifie pas qu’elle est proportionnée. Même une réponse transportée de façon sûre ne prouve pas la cohérence de la zone. Le RFC 7481 confie authentification, autorisation, confidentialité et intégrité de RDAP à d’autres couches. Protéger le message ne valide pas le processus qui a produit sa valeur.

La preuve utile est un rapprochement

Le dossier de changement doit relier l’acteur autorisé, la politique applicable, l’ancien TTL, la transaction EPP ou son équivalent, la valeur RDAP horodatée, la version de zone, les réponses de toutes les autorités, plusieurs vues récursives, la validation DNSSEC, le test applicatif et la décision de retour arrière.

Le principe du code effectivement exécuté de Heng Lu déplace l’attention du plan vers ces passages observés. Sa distinction entre contrôle formel et maîtrise pratique des données explique pourquoi le registre ne contrôle plus les copies remises aux résolveurs. Son modèle d’une spécification initiale minimale et de décisions locales décrit bien le compromis : la norme fournit un langage d’observation, chaque opérateur garde la politique et les conséquences.

Le RFC 10037 ne synchronise pas Internet. Il rend enfin explicite l’horloge que le registre est en mesure de montrer.