Résumé

  • RFC 1480 distinguait une branche déléguée, l’inscription directe d’une machine IP par fiche A et l’inscription directe d’une machine non-IP par relais MX. Le suffixe .US ne révélait ni le mode d’administration ni le chemin de communication.
  • La délégation confiait une portion de l’espace à un gestionnaire désigné et ajoutait des obligations durables : équité, compétence, exactitude, serveurs redondants, service de la communauté et transfert accepté. Une simple fiche dans la base mère ne produisait pas ces pouvoirs.

Trois dossiers pouvaient aboutir au même écran

En juin 1993, RFC 1480 décrivait un domaine national américain organisé par États, localités et branches telles que K12, LIB, FED ou GEN. À l’écran, un nom comme école.K12.État.US et le nom d’une petite entreprise inscrit directement avaient la même ponctuation. L’uniformité était précisément l’intérêt du DNS.

Mais le formulaire reproduit dans le document demandait au requérant de choisir entre plusieurs situations. Une délégation remettait une branche à une organisation qui exploitait ses serveurs. Une inscription directe ajoutait les données dans la base principale. Et cette seconde famille séparait encore les machines IP des machines non-IP.

Ces choix ne correspondaient pas à trois qualités d’un même objet. Ils déterminaient qui pouvait modifier les données, quel type de ressource répondait, quel réseau portait le service et à qui revenait l’obligation de réparer.

La fiche directe ne découpait pas l’arbre

Pour une machine IP, RFC 1480 associait l’inscription directe à une fiche A. L’administrateur du domaine .US recevait la demande et publiait l’adresse dans la base qu’il administrait. Le demandeur obtenait un nom résoluble, pas la maîtrise implicite d’une zone fille.

RFC 1034 situe ailleurs l’acte de délégation : le responsable de la zone parente doit accepter de transférer le contrôle d’une portion de l’arbre. Tant que cette décision et les données correspondantes n’existent pas, le parent reste le dépositaire du contenu.

La grammaire de RFC 1035 permet de ne pas confondre les témoins. A livre une adresse Internet. NS désigne un serveur censé faire autorité pour une zone commençant au nom propriétaire. Une réponse A exacte peut donc être publiée sans que le titulaire du nom dispose du moindre pouvoir sur une branche.

Cette différence devient visible au premier changement. La fiche directe doit être corrigée par celui qui tient la base mère. Le gestionnaire délégué modifie sa propre zone. Voir le même suffixe ne suffit pas pour savoir à quelle porte frapper.

Le courrier pouvait arriver sans que la machine soit sur IP

Le cas le plus révélateur concernait les machines UUCP. RFC 1480 acceptait qu’elles soient à un, deux ou trois bonds d’une machine connectée à Internet. Leur nom DNS pointait par MX vers un relais IP. Pour l’expéditeur, l’adresse conservait une syntaxe Internet ordinaire.

L’abstraction n’effaçait pourtant aucune dépendance. Il fallait qu’un relais accepte administrativement la mission, qu’une procédure technique existe entre lui et la machine non-IP, et que chaque machine intermédiaire connaisse le prochain trajet. Le document précisait même que l’administration .US ne pouvait pas négocier cet accord à la place du demandeur.

RFC 1035 dit que l’échangeur MX est disposé à traiter le courrier du nom propriétaire ; RFC 974 ordonne la sélection des échangeurs. Ni l’un ni l’autre ne transforme le nom propriétaire en adresse IP. Une fiche MX publiée ne prouve pas davantage qu’un appel UUCP a abouti, qu’une file a été vidée ou que le destinataire a lu le message.

Le DNS masquait utilement une frontière aux utilisateurs. L’audit, lui, devait la conserver.

La délégation était une charge publique

La croissance justifiait de distribuer l’administration. Le texte citait K12.TX.US, berkeley.ca.us et LIB.MN.US comme exemples de branches susceptibles d’être déléguées. Une personne ou une équipe centrale ne pouvait pas traiter indéfiniment toutes les demandes.

RFC 1480 n’accordait toutefois pas le rôle au premier opérateur capable d’écrire deux fiches NS. Le gestionnaire devait être désigné, servir équitablement les groupes du domaine, éviter les préférences commerciales et ne pas imposer un produit, un protocole ou un système de courrier particulier. Les parties fortement concernées devaient reconnaître qu’il convenait au rôle.

La charge comportait des preuves techniques. La base devait rester exacte et robuste ; les demandes devaient recevoir une réponse en temps utile. Un serveur primaire et un secondaire devaient être joignables par IP et contrôlables par l’administrateur supérieur. Des lieux physiques distincts étaient recommandés pour qu’une panne ou une catastrophe locale n’emporte pas le service entier.

La présence de NS montre une attente d’autorité. Elle ne démontre pas l’indépendance des pannes, l’exactitude des zones, l’impartialité du gestionnaire ni l’accord de la communauté.

Le transfert ne se réduisait pas au remplacement d’un serveur

Changer de gestionnaire exigeait des communications de l’ancienne et de la nouvelle organisation. L’administrateur supérieur devait pouvoir constater leur accord mutuel et la compréhension, par le successeur, des responsabilités assumées. Les avis des personnes affectées complétaient le dossier.

Cette séquence décrivait un changement de dépositaire, non la vente automatique d'un bien. Un nouveau serveur pouvait être opérationnel avant que l’autorité soit reconnue ; un accord institutionnel pouvait exister avant que les données soient correctement servies. Il fallait dater les deux faits.

RFC 1591 formula ensuite la portée générale : les administrateurs de domaines nationaux rendaient un service public, et le gestionnaire désigné agissait comme trustee pour la communauté nationale et l’Internet mondial. Ce texte éclaire la logique de RFC 1480 ; il ne certifie aucun cas particulier.

Un document entretenu n’était pas un relevé de déploiement

RFC 1480 remplaçait RFC 1386, paru six mois auparavant. La succession montre qu’une politique écrite évoluait au rythme du domaine. Elle ne compte ni les délégations réellement ouvertes ni les serveurs effectivement séparés.

La hiérarchie géographique répondait à un problème de gestion et d’unicité. RFC 920 et les RFC DNS antérieures fournissaient le cadre ; RFC 1480 proposait une distribution concrète du travail américain. Sa fiche RFC Editor le classe Informational, et la section sécurité reconnaît que ces questions ne sont pas traitées.

Un erratum vérifié, plusieurs décennies plus tard, insère une barre d’alternative oubliée dans la BNF de l’annexe. Il corrige la phrase formelle, pas l’état historique d’une zone.

Lire un nom commence par identifier son témoin

Une enquête sérieuse ne range pas tout sous « le domaine existait ». Elle note le nom propriétaire, le type de fiche, la zone qui l’a publié, l’existence d’une coupure de délégation, le gestionnaire, les serveurs et l’heure d’observation.

Pour le courrier non-IP, elle ajoute l’accord du relais, les règles hors Internet, les machines intermédiaires, la tentative et l’accusé de réception. Pour une délégation, elle ajoute la sélection du gestionnaire, les engagements d’équité, l’indépendance des serveurs et les actes de transfert.

Le DNS avait rendu ces arrangements lisibles sous une syntaxe commune. RFC 1480 rappelle pourquoi l’historien ne doit pas les rendre indiscernables.

Sources