Résumé

  • La RFC 10037 définit le membre facultatif ttl0_data pour les objets de domaine et de serveur de noms dans RDAP.
  • La valeur publiée est celle qui est provisionnée dans la base du registre, et non la durée restante observée lors d’une requête DNS.

Le chiffre ne répond pas à la question du cache

RDAP pouvait déjà présenter les serveurs de noms, les adresses de glue et les enregistrements DS liés à un domaine. Il lui manquait les TTL associés à ces RRsets. Or ce paramètre exprime une intention d’exploitation : il indique combien de temps un résolveur peut réutiliser un ensemble avant de demander une nouvelle réponse.

La RFC 10037 ajoute un objet ttl0_data. Son membre values associe des mnémoniques de types DNS à des nombres entiers ; des remarques RDAP peuvent compléter l’information. Un serveur reste libre de publier ou non ce membre. S’il le publie, il doit annoncer ttl0 dans rdapConformance.

La limite la plus importante est explicite. Le TTL doit refléter la valeur provisionnée dans la base du registre. Il ne représente pas le compte à rebours d’un cache. Un nombre de 3 600 indique donc qu’une heure est enregistrée pour le RRset concerné ; il ne prouve ni que tous les serveurs faisant autorité servent cette valeur, ni que tous les caches l’ont reçue, ni qu’il reste exactement une heure avant expiration.

Cette séparation améliore le diagnostic. Pendant un incident, l’opérateur peut comparer l’intention du registre, les réponses des serveurs faisant autorité et l’état d’un résolveur récursif. Une divergence oriente l’enquête vers le provisionnement, la publication, la propagation ou le cache. RDAP devient un point de comparaison hors bande, pas un outil de supervision en temps réel.

Une visibilité facultative, une signification encadrée

Le registre conserve le pouvoir de divulgation puisque l’extension est facultative. La norme encadre toutefois le sens des données publiées. Les types doivent être enregistrés auprès de l’IANA et écrits en majuscules. Le TTL s’applique à un RRset, non à chaque enregistrement. Sa valeur JSON est un entier compris entre zéro et 2 147 483 647, sans fraction ni notation exponentielle.

Les bénéficiaires sont les registraires, titulaires, fournisseurs DNS et équipes d’incident qui veulent vérifier une configuration sans accès privilégié au système de provisionnement. Le bénéfice est la lisibilité. La RFC ne certifie pas l’actualité de la base, l’autorisation d’une modification ou la conformité du DNS servi.

L’extensibilité a un coût côté client

Un client conforme doit accepter tout type DNS valide dans values, y compris un type ajouté ultérieurement. Les bibliothèques qui transforment automatiquement le JSON en objets rigides risquent de rejeter une réponse pourtant correcte. La RFC recommande donc de traiter cette partie comme une table extensible et de suivre le registre IANA des types DNS.

La publication RDAP est par ailleurs distincte du provisionnement EPP défini par la RFC 9803. Un registre peut exposer les TTL sans offrir cette extension EPP. Voir une valeur ne révèle donc ni qui l’a choisie, ni quelle règle l’encadre, ni qui peut la modifier. La RFC 10037 laisse précisément ces questions de détermination et d’autorisation hors de son périmètre.

Preuves, scénario contraire et inconnues

Sans cette extension, RDAP continuerait d’exposer les enregistrements DNS associés, mais pas les TTL configurés par le registre. Les opérateurs devraient s’appuyer sur le DNS en service ou sur des canaux propres au registre, sans référence normalisée hors bande. Cette conclusion est un scénario contraire déduit des fonctions décrites par les RFC, non un résultat mesuré.

Les sources primaires n’établissent ni le nombre de registres qui déploient ttl0_data, ni une réduction de la durée des incidents, ni une exposition uniforme selon les objets, ni un changement de comportement des clients. Elles ne prouvent pas non plus l’exactitude d’une mise en œuvre particulière à un instant donné. Ces points restent inconnus et doivent être mesurés séparément.

Sources