Résumé

  • RFC 3405 exigeait qu’un schéma URI ou un espace de noms URN soit déjà enregistré, documenté par une spécification stable et représenté par une autorité reconnue avant toute règle NAPTR dans uri.arpa. ou urn.arpa..
  • Les enregistrements des zones communes devaient avoir des TTL extrêmement longs. Une règle appelée à changer était placée dans une zone déléguée à TTL plus court, derrière un premier indice stable.

Un long TTL est souvent traité comme une contrainte d’exploitation. RFC 3405 en faisait un matériau de conception. Si une entrée mondiale pouvait rester en cache pendant des années, elle ne devait pas porter la politique la plus volatile. Elle devait indiquer durablement où trouver l’autorité capable de modifier cette politique.

Publié en octobre 2002 comme Best Current Practice 65, le texte achevait les cinq parties de DDDS. RFC 3401 présentait l’ensemble, RFC 3402 l’algorithme, RFC 3403 les règles NAPTR dans DNS, RFC 3404 les services de résolution URI et URN, et RFC 3405 les affectations sous uri.arpa. et urn.arpa..

La dernière partie n’était pas un appendice administratif. Elle décidait qui pouvait écrire la première instruction dans un espace DNS mondial, comment cette qualité était prouvée et quelle couche pouvait évoluer rapidement. Une procédure de registre devenait ainsi une propriété exécutable.

Pour un URI, le schéma fournissait la première clé sous uri.arpa.. Pour un URN, la règle urn de cette zone extrayait l’identifiant d’espace de noms et transférait la recherche sous urn.arpa.. Quelques octets placés au point d’entrée pouvaient donc détourner toute une famille d’identifiants.

RFC 3405 refusait que l’enregistrement NAPTR crée lui-même l’autorité qu’il prétendait représenter. Le schéma URI devait avoir été enregistré avec une spécification stable. L’identifiant d’espace URN devait avoir suivi son propre processus. L’indice de résolution venait après la légitimité de l’espace ; il ne la produisait pas rétroactivement.

Cette séquence bloquait le contournement du contrôle d’un nouveau NID et empêchait qu’une règle pour un URI fondé sur DNS délègue vers un acteur autre que le détenteur du nom de domaine intégré. Une expression régulière pouvait être syntaxiquement correcte tout en constituant une capture d’autorité.

La revue vérifiait solidité technique, cohérence avec la spécification et respect du détenteur du nom. Quand le texte du schéma ou du NID était maintenu hors de l’IETF, une création ou modification ultérieure exigeait aussi l’accord du propriétaire ou mainteneur. L’expert et le mainteneur fournissaient deux preuves différentes.

Pour un NID, cette autorité s’étendait à tous les NAPTR associés, même si une règle ne touchait qu’une partie de l’espace. La portée étroite d’une expression ne supprimait pas le contrôle du responsable du namespace.

Le formulaire rendait la chaîne visible : Key, Authority et Records. Key choisissait l’emplacement mondial ; Authority nommait l’entité habilitée ; Records décrivait la délégation exécutable. Ce n’était pas un simple fragment de fichier de zone.

La procédure d’origine passait par des listes ouvertes et deux semaines d’objections. Mais l’objet de l’objection était limité aux effets sur la zone ou DNS. Le mérite du schéma ou du NID déjà accepté devait être discuté dans son propre forum. Chaque couche possédait son lieu de décision.

L’IANA exploitait les zones et les listes. Cette centralisation opérationnelle ne lui attribuait pas toutes les règles : autorités de schéma et de namespace apportaient le droit et la spécification, les réviseurs contrôlaient l’impact commun, l’IANA publiait, puis les opérateurs délégués géraient le changement.

Le passage décisif concernait le temps. Pour diminuer la charge des zones communes, leurs enregistrements devaient garder des TTL très longs, éventuellement de plusieurs années. Une politique changeante ne pouvait habiter directement dans une telle surface de cache.

RFC 3405 recommandait donc une délégation temporelle. Le NAPTR commun restait stable et pointait vers une autre zone DNS, dotée d’un TTL plus court. La première couche optimisait stabilité et faible charge ; la seconde assumait l’agilité opérationnelle.

Un cache pouvait conserver le pointeur tout en rafraîchissant indépendamment les règles aval. Modifier la zone déléguée ne révoquait pas un ancien premier indice ; modifier le premier indice pouvait prendre longtemps à devenir universel. L’audit doit donc attribuer chaque changement à sa couche et à son horloge.

Tous les schémas n’avaient pas besoin de cette seconde zone. Un URI HTTP porte déjà son hôte, que la règle stable peut extraire. D’autres namespaces disposent de décisions plus flexibles et gagnent à déléguer vers une zone courte. L’endroit où apparaît la prochaine clé constitue une géométrie de contrôle.

La règle urn illustrait une gouvernance imbriquée : elle recevait d’abord l’URI générique, extrayait le NID, puis laissait la décision propre au namespace se faire sous urn.arpa.. L’entrée commune n’uniformisait pas les politiques locales.

Deux errata techniques vérifiés sont indispensables. Les errata 2687 et 2688 remplacent \2 par \1 dans deux exemples : chacun ne contient qu’un seul groupe capturant. Les expressions imprimées sont invalides et ne doivent pas être reprises en production.

La règle d’éligibilité a aussi vieilli. RFC 3405 réservait initialement URI.ARPA aux schémas de l’« IETF tree » de RFC 2717. Les arbres de noms ont ensuite disparu. Une tentative de correction par erratum fut rejetée, car un changement normatif exigeait un nouveau RFC.

RFC 8958 effectua cette mise à jour en 2020 : il supprima la condition d’arbre et exigea désormais un schéma enregistré comme permanent selon BCP 35, aujourd’hui RFC 7595. Le nouveau portail conservait le principe essentiel : enregistrer l’espace d’identifiants avant son indice mondial.

Le registre IANA contemporain distingue schémas permanents, provisoires et historiques ; la présence dans le registre ne suffit donc pas pour URI.ARPA. Le registre des espaces URN suit désormais RFC 8141. Enregistrement d’un nom et publication dans la zone commune restent deux événements probatoires.

La page .arpa actuelle de l’IANA conserve uri.arpa sous RFC 3405 et RFC 8958, et urn.arpa sous RFC 3405. Elle prouve l’usage attribué, pas le déploiement d’un NAPTR pour chaque entrée ni le succès d’un résolveur.

Ces zones concentraient naturellement les risques de déni de service et d’usurpation. DNSSEC pouvait authentifier les données publiées ; il ne prouvait ni l’accord du mainteneur, ni la conformité de la zone aval, ni l’authenticité de la ressource finale.

Une trace complète doit réunir statut du schéma ou NID, spécification, autorité, accord, formulaire, dates de revue, objections recevables, acceptation IANA, enregistrement publié, DNSSEC, TTL long, clé déléguée, autorité et TTL aval, changement, cache observé, règle choisie et résultat consommé.

Le principe de spécification initiale minimale de Lu Heng explique les deux vitesses : normaliser le plus petit passage durable et localiser les décisions futures derrière lui. La primauté du code en fonctionnement fournit l’essai : observer les enregistrements réels, appliquer les errata, ne modifier que la zone aval, comparer les deux TTL et vérifier que l’autorité suit le mainteneur reconnu plutôt que l’auteur d’une syntaxe NAPTR valide.

RFC 3405 fit de la stabilité une décision de placement. Le premier indice pouvait rester lent parce qu’il ne prétendait pas être la règle actuelle. Le changement demeurait possible, mais localisé, attribué et doté de sa propre horloge.

Sources