Résumé

  • draft-levine-dnsextlang-14 décrit un moyen de publier la structure des RRTYPE dans des enregistrements TXT afin que de nombreux nouveaux types soient pris en charge comme données de configuration. Il s’agit d’un Internet-Draft individuel, pas d’un RFC ni d’un service IANA déployé.
  • Le drapeau X annonce qu’un type exige un traitement particulier. Il permet à un serveur dépourvu de cette fonction de refuser la zone ; il ne fournit ni le code ni la preuve que la fonction existe.
  • DNSSEC authentifie l’origine et l’intégrité d’un RRset selon la politique du validateur. La décision d’exécuter exige encore l’identité des versions, la visibilité des surcharges locales, des vecteurs de test, une conversion aller-retour et une réponse autoritative observée.

Un formulaire de provisionnement vient d’apparaître avec cinq champs nouveaux. Il a été construit à partir d’un TXT signé, récupéré sans erreur. L’équipe pourrait en conclure que le nouveau RRTYPE est « pris en charge ». Pourtant, elle n’a encore vu ni les octets produits par le serveur autoritatif, ni un rechargement de zone, ni le comportement du chemin de signature ou d’AXFR. Elle a prouvé que la description pouvait être lue, pas que le service pouvait l’exécuter.

Le projet répond à un vrai coût. Chaque nouveau RRTYPE peut imposer une modification du format de fichier maître dans les serveurs et les outils qui alimentent ces serveurs. Le langage proposé déplace une partie de ce travail vers une stanza : nom symbolique, numéro, options et succession de champs. Un serveur pourrait convertir une notation lisible en RDATA binaire ; un outil pourrait reconstruire le texte après un transfert de zone ; une application pourrait générer des formulaires et contrôler la syntaxe.

Ce déplacement est puissant précisément parce qu’il rapproche les données du comportement. Le changement n’abolit pas l’implémentation : il confie une partie de l’implémentation à un interpréteur de configuration.

Une définition, deux noms et plusieurs horloges

Le projet place deux TXT identiques dans le DNS : le premier sous le numéro dans RRTYPE.ARPA, le second sous le nom dans RRNAME.ARPA. Un CNAME peut relier les deux. Des préfixes de langue servent aux descriptions humaines, tandis qu’une entrée sans préfixe fournit la valeur par défaut.

Cette symétrie facilite la découverte, mais elle ne résout pas les désaccords. Deux RRset indépendants peuvent se rafraîchir à des instants différents. Un cache peut connaître la nouvelle définition numérique alors qu’un autre conserve l’ancienne définition symbolique. Une version linguistique peut précéder l’alias par défaut. Le texte exige l’identité sans dire quelle copie prime lorsqu’elle manque.

La section annuaire révèle une autre limite du document de travail : la prose cite _LIST.RRTYPE.ARPA, alors que l’exemple emploie _LIST.RRNAME.ARPA. Ce n’est pas une liberté d’architecture ; c’est une incohérence à résoudre avant qu’une implémentation silencieuse ne crée deux conventions.

Le TTL organise le renouvellement mais n’impose pas un changement simultané. RFC 8767 autorise aussi, dans des circonstances définies d’échec de rafraîchissement, la conservation et le service de données périmées. Le projet n’ordonne pas ce mode. Il faut néanmoins que le reçu distingue réponse autoritative courante, cache encore valide et réponse stale.

Enfin, le fichier local optionnel sert au débogage et aux surcharges. Il protège l’autonomie de l’opérateur, mais introduit une autorité supplémentaire. Son empreinte et sa priorité doivent apparaître dans le constat ; sinon deux machines identiques, recevant la même réponse DNS, peuvent exécuter des schémas différents.

DNSSEC ne relit pas le sens

Le chapitre sécurité du projet évoque la modification d’une définition importée par usurpation DNS et cite DNSSEC parmi les défenses. RFC 4033 borne précisément le résultat : authentification de l’origine et intégrité des RRset à partir d’ancres de confiance et d’une chaîne d’authentification.

Une validation réussie établit donc que la zone authentifiée a publié ces octets et qu’ils n’ont pas été altérés sans détection. Elle ne démontre pas que la stanza est cohérente, que les deux noms concordent, que le parseur accepte les limites, que l’adaptateur de base de données conserve l’ordre, ni que l’opérateur souhaite l’activation. Une erreur de conception peut porter une signature parfaitement valide.

Publication, authentification et activation sont trois actes. Le publicateur affirme. Le validateur établit la provenance. L’opérateur autorise l’effet sur le service. Employer le seul mot « confiance » pour les trois retire précisément la responsabilité que l’automatisation devrait rendre visible.

X permet de s’arrêter ; il n’installe rien

Le drapeau X indique qu’un RRTYPE exige un traitement supplémentaire du serveur, comme certains comportements de DNAME ou DNSSEC. Son objectif est de permettre une erreur lorsque ce traitement n’est pas implémenté. I et A indiquent les classes visées ; O et E signalent les types obsolètes et expérimentaux.

Ces lettres déclarent une propriété. Elles n’identifient ni module, ni version, ni suite de conformité. Comprendre la forme filaire ne signifie pas savoir produire les effets particuliers du type. Face à un X non satisfait, le résultat honnête est un refus borné, pas un voyant vert « schéma chargé ».

RFC 3597 offre déjà une base sûre : un type inconnu peut être représenté par TYPEnn \# longueur hexadécimal, conservé et transmis de manière transparente. Les types inconnus n’obtiennent pas de traitement de section additionnelle. Le nouveau langage apporte donc une syntaxe humaine, des modèles et une conversion pilotée par table ; il n’invente pas le transport de RDATA inconnu. La notation générique reste un repli lorsque la syntaxe agréable ne peut être activée.

Du texte signé à la réponse autoritative

Le projet reconnaît que des définitions invalides, accidentelles ou hostiles, peuvent déclencher des bogues dans les logiciels qui ne contrôlent pas leur entrée. Il reconnaît aussi que l’expression de types arbitraires peut contourner les restrictions d’un système de provisionnement. Le parseur devient donc une frontière d’exécution et d’autorisation.

Le reçu minimal doit relier douze éléments : état et révision du document ; réponse de l’annuaire ; empreintes des variantes numérique, symbolique et linguistique ; résultat DNSSEC et politique de confiance ; TTL, âge du cache et éventuel stale ; fichier local et priorité ; versions du serveur, du parseur et du stockage ; module correspondant à chaque X ; tests positifs, négatifs et de ressources ; octets de l’aller-retour texte–fil ; chargement d’une zone isolée et requête autoritative ; portée de l’activation, santé et retour arrière.

Ce reçu est une proposition opérationnelle de cet article, non une obligation du draft. Il empêche une preuve de se faire passer pour la suivante. La signature ne remplace pas le test du parseur. Le test ne remplace pas le chargement. Le chargement ne remplace pas la réponse. Une réponse sur une instance ne prouve pas la convergence d’une flotte.

Cette séparation rend aussi la réparation locale. Un désaccord entre les deux noms relève du rapprochement. Un token inconnu relève de l’admission des capacités. Une différence après conversion relève du codec. Un succès en canari suivi d’un échec en production relève du déploiement. Le terme vague « support RRTYPE » masque ces propriétaires.

Garder le commun suffisamment mince

La couche commune a besoin d’une grammaire portable, d’un lien sans ambiguïté entre nom et numéro, d’une sémantique de champ, d’une règle linguistique, d’un processus d’enregistrement et d’invariants d’interopérabilité. Les schémas de base de données, limites de ressources, horaires d’activation, traitements spéciaux et retours arrière peuvent rester près de l’opérateur.

C’est la logique de la spécification initiale minimale de Heng Lu : centraliser seulement ce qui doit être commun, puis laisser les décisions futures à ceux qui portent leurs conséquences. L’adoption volontaire n’est pas un refus du standard ; c’est l’exigence que le code en fonctionnement confirme ce que le registre décrit.

Une surcharge locale visible, un prototype limité ou l’usage de RFC 3597 peuvent coexister avec une définition centrale. Ce qui ne doit pas rester invisible est l’identité de la définition active. Sans empreinte, une mise à jour distante se diffuse selon les caches et l’équipe d’incident ne peut plus reconstruire quel serveur a interprété quels octets.