Résumé

  • RFC 3403 plaçait les règles DDDS dans des enregistrements NAPTR, mais l’ordre matériel des réponses DNS n’était pas l’ordre d’exécution. ORDER reconstituait les niveaux d’autorité et PREFERENCE ne classait que les alternatives d’un même niveau.
  • Après une correspondance, un client ne pouvait descendre vers un autre ORDER parce qu’un service lui semblait plus familier. Données Additional, DNSSEC et succès du service restaient des preuves séparées.

Un affichage DNS ressemble à une liste. Les enregistrements occupent des lignes successives, et un analyseur de paquets leur attribue naturellement un premier et un dernier. RFC 3403 demandait au client DDDS d’oublier cette apparence. La réponse était un ensemble de règles candidates ; sa séquence normative devait être reconstruite.

Publié en octobre 2002 sur la voie de normalisation, le document définissait DNS comme base de règles DDDS. Une clé était un nom de domaine valide. Le client interrogeait ce nom pour obtenir des NAPTR, type 35, puis interprétait leur structure. RFC 3403 remplaçait RFC 2915 et RFC 2168 comme spécification officielle de l’enregistrement.

Le champ ORDER portait la succession de délégation. Les plus petites valeurs passaient d’abord. Deux enregistrements de même ORDER représentaient la même règle du point de vue de l’autorité, même s’ils proposaient des services différents. Dès qu’une correspondance était trouvée, le client ne devait plus examiner un autre ORDER, sauf l’exception explicite de sélection complexe prévue par l’algorithme DDDS.

Ainsi, le premier enregistrement reçu ne bénéficiait d’aucun privilège. Serveur, cache ou bibliothèque pouvait présenter le RRset dans une autre séquence sans en modifier le sens. Choisir la première combinaison Services connue revenait à substituer un hasard de transport à l’ordre publié par l’administrateur.

PREFERENCE intervenait à l’intérieur d’un niveau. Équivalent de Priority dans l’algorithme, il classait les enregistrements partageant le même ORDER, les valeurs basses étant préférées. Un client pouvait passer à une préférence moins favorable s’il supportait mal un protocole. Il ne pouvait utiliser cette souplesse pour franchir la frontière vers un autre niveau d’autorité.

Le champ n’était pas un poids de répartition. RFC 3403 le disait expressément : il communiquait une qualité ou une préférence entre règles équivalentes. SRV ou plusieurs enregistrements A répondaient au besoin de répartition de charge. Transformer PREFERENCE en tirage aléatoire aurait ajouté une sémantique absente.

Flags et Services recevaient leur signification de la spécification d’application. La base DNS ne décidait pas universellement quels drapeaux étaient terminaux ni quels services étaient valides. Reconnaître un caractère ou un libellé ne suffisait donc pas à prouver que le client comprenait l’application concernée.

REGEXP et REPLACEMENT formaient deux variantes mutuellement exclusives de l’expression de substitution. REGEXP opérait sur la chaîne d’application d’origine. REPLACEMENT contenait un nom pleinement qualifié pour une substitution simple, sans compression DNS. Si les deux champs étaient remplis, l’enregistrement était erroné et devait être ignoré ou provoquer une erreur.

Entre le fichier de zone et la réponse existait encore une transformation. Les barres obliques inverses servaient d’échappement dans le format maître ; il fallait souvent en saisir deux pour qu’une seule parvienne au client. Comparer seulement le texte administré ou seulement les octets reçus pouvait masquer l’endroit où une expression avait changé.

Les champs textuels utilisaient UTF-8. Hors de l’équivalence ASCII, les expressions devaient traiter des points de code et non des octets. Elles ne pouvaient dépendre d’une locale POSIX particulière : une règle changeant de sens selon la configuration linguistique du client n’aurait plus été universelle.

Plusieurs applications DDDS pouvaient partager cette base et entrer en collision. Le RFC proposait trois séparations : zones distinctes, expressions ancrées sur une forme propre à l’application, ou valeurs Flags et Services permettant d’ignorer les règles étrangères. La cohabitation sous un même nom DNS ne fusionnait pas leurs contrats.

La section Additional n’était qu’une accélération. Un serveur pouvait y joindre des RRsets A ou SRV pertinents et de même authenticité que la réponse. L’application pouvait les exploiter, mais devait fonctionner avec un serveur qui ne les fournissait jamais. Leur absence exigeait une requête supplémentaire, pas le rejet du NAPTR.

Le TTL empêchait de recomposer une histoire avec des fragments de dates différentes. Lors d’un repli après échec, le client devait vérifier toutes les règles précédemment obtenues. Si une seule avait expiré, il fallait recommencer l’algorithme. Une chaîne mêlant ancien début et nouvelle fin n’était pas une délégation observée à un instant donné.

Le document déconseillait aussi de remonter vers d’autres chemins après l’échec d’une consultation issue d’une réécriture. Mieux valait signaler l’échec. Un retour opportuniste transformerait une délégation déterminée en exploration et rendrait invisible le niveau d’autorité où le parcours s’était rompu.

DNSSEC pouvait signer et valider NAPTR comme tout enregistrement DNS. Cette preuve portait sur l’authenticité des données DNS. Elle ne prouvait ni la sûreté d’une expression, ni le tri du client, ni la correspondance entre Services et application, ni le fonctionnement du service final. Le RFC avertissait séparément de ne pas remettre aveuglément une expression à un environnement capable d’exécuter du code.

Le registre DNS Parameters de l’IANA conserve NAPTR au type 35 : coordination d’un code, non certificat d’implémentation. Le RFC Editor affiche un erratum éditorial, le 2868, « Held for Document Update ». Il retire le double mot this this dans la description de Services et ne modifie aucune règle d’ordre.

Le reçu d’exécution doit conserver la clé interrogée, le RRset complet, l’état DNSSEC, les TTL, l’ordre reçu, les groupes ORDER triés, les PREFERENCE, Flags, Services, la validité de REGEXP ou REPLACEMENT, l’interprétation UTF-8, la comparaison fichier-zone/réponse, les refus, l’enregistrement sélectionné, les données Additional utilisées, la requête suivante et le résultat du consommateur.

La spécification initiale minimale de Lu Heng éclaire ce partage : normaliser la représentation DNS minimale, laisser chaque application définir son sens. La primauté du code en fonctionnement fournit le test : mélanger l’ordre du RRset, supprimer Additional, changer la locale et faire expirer une dépendance. Le choix doit suivre les champs d’autorité, jamais la présentation.

RFC 3403 a donc encodé un acte ordonné dans un ensemble DNS sans prétendre que le transport l’avait déjà ordonné. Le premier NAPTR affiché était seulement le premier aperçu. La première règle venait du contrat.

Sources