Résumé

  • RFC 1535 décrivait des clients de résolution qui transformaient un nom non enraciné en une suite ordonnée de candidats. Depuis Machine.Tech.ACES.COM, la saisie UnivHost.University.EDU pouvait produire trois noms suffixés avant le nom absolu vraisemblablement visé.
  • L’enregistrement de EDU.COM et un CNAME générique sous cette branche rendaient le franchissement visible : une réponse à un candidat créé par le logiciel pouvait arrêter la recherche avant UnivHost.University.EDU..
  • La correction bornait la recherche implicite à l’espace administré localement, essayait d’abord comme absolu un nom comportant un point et réservait les autres abréviations aux listes explicites. Le RFC est Informational ; il ne prouve ni parc touché, ni compromission observée, ni comportement actuel.

Une autorité reçue sans demande

Dans le DNS, l’opérateur d’une zone répond pour les noms placés sous la délégation qu’il détient. Cette règle paraît nette lorsqu’on part de la requête effectivement envoyée. Elle devient trompeuse si l’on oublie qui a construit cette requête.

Le cas central du RFC 1535 commence sur une machine nommée Machine.Tech.ACES.COM. L’utilisateur saisit UnivHost.University.EDU sans point terminal. Certains résolveurs issus de BSD BIND pouvaient tenter successivement :

  1. UnivHost.University.EDU.Tech.ACES.COM. ;
  2. UnivHost.University.EDU.ACES.COM. ;
  3. UnivHost.University.EDU.COM. ;
  4. UnivHost.University.EDU..

La troisième question est décisive. Elle se trouve sous EDU.COM., non sous l’université visée et non sous l’organisation locale ACES.COM. L’opérateur de cette branche est parfaitement habilité à répondre à la question reçue. Il n’est simplement pas habilité à décider ce que l’utilisateur voulait dire. Ce pouvoir lui a été prêté par l’ordre de recherche du résolveur.

Le dossier IETF et la notice du RFC Editor datent le document d’octobre 1993 et le classent Informational. Le texte d’archive permet de recouper les exemples ; la page d’errata garde les corrections documentaires distinctes. Aucun de ces éléments ne mesure le nombre de postes concernés ni ne décrit un résolveur contemporain.

Le point final ne certifiait rien

Un nom terminé par un point était interprété comme enraciné : UnivHost.University.EDU. disait au résolveur de partir de la racine DNS, sans lui ajouter une origine locale. La forme sans point terminal restait susceptible d’être relative.

Ce signe n’était ni une signature ni une preuve d’identité. Il n’attestait pas l’opérateur du service, la fraîcheur de la réponse ou la sûreté de la connexion. Il fixait seulement le régime de complétion. Autrement dit, il bornait la liberté du logiciel de fabriquer d’autres noms.

Cette grammaire existait avant le rapport de sécurité. RFC 1034, dont la notice appartient au STD 13, expliquait la résolution de noms relatifs par rapport à une origine ou une liste de recherche, tout en reconnaissant que l’interface offerte à l’utilisateur dépendait de l’implémentation. RFC 1035 et sa fiche fournissent le contexte des messages, des enregistrements et des résolveurs. Ils ne constituent pas un relevé des valeurs par défaut installées en 1993.

Le problème n’était donc pas l’existence d’un nom relatif. À l’intérieur d’un espace connu, écrire printer ou mail.lab peut être raisonnable. Le problème venait d’une procédure implicite qui continuait à retirer des labels sans savoir si elle restait dans le même périmètre administratif.

La syntaxe voyait des suffixes ; l’exploitation voyait des propriétaires

Pour une fonction de chaîne, Tech.ACES.COM, ACES.COM et COM forment une série simple. Chaque étape enlève le label le plus à gauche. Pour l’exploitation, cette série traverse des droits différents.

L’équipe qui administre ACES.COM peut décider que service.Tech.ACES.COM. et service.ACES.COM. sont des interprétations locales prévues. Elle ne possède pas pour autant chaque nom formé sous .COM. Dès que la recherche enlève ACES, elle quitte l’espace dans lequel cette équipe peut promettre une signification.

La vulnérabilité était ainsi une confusion entre proximité textuelle et continuité d’autorité. Deux candidats voisins dans une boucle logicielle pouvaient appartenir à des administrateurs sans relation. Le résolveur ne demandait aucune preuve que le suffixe suivant restait local ; il avançait jusqu’à ce qu’une réponse existe.

Ce mécanisme explique pourquoi une simple métrique de taux de résolution peut être inversée. Une réponse plus rapide ou un échec en moins paraît positif. Si cette réponse vient du premier candidat public non autorisé, la réussite technique est précisément l’événement dangereux.

EDU.COM matérialisait la bifurcation

Le RFC rapportait que EDU.COM avait été enregistré et qu’un CNAME générique sous cette branche pouvait orienter des noms de la forme quelquechose.edu.com vers une même cible. Il donnait notamment l’exemple harvard.edu.com.

Il faut préserver la portée exacte de cette source. Elle décrit une configuration et un risque dans le document de 1993. Elle ne démontre pas que le domaine porte aujourd’hui le même contenu, qu’un mot de passe a effectivement été volé ou qu’un nombre connu de connexions a été détourné.

Ce que l’exemple prouve conceptuellement est plus précis. Une réponse valable dans le DNS pouvait concerner un candidat que l’utilisateur n’avait jamais saisi. Le résolveur pouvait alors arrêter sa série et ne jamais envoyer la question enracinée. « Une réponse a été obtenue » ne signifiait donc pas « le nom voulu a été résolu ».

Même le terme « détournement » doit être décomposé. Il faudrait encore observer l’adresse ou le CNAME retenu, l’établissement du transport, la vérification du certificat ou de la clé, la décision de l’application, une éventuelle autorisation et l’effet final. Le RFC révèle un chemin d’interprétation indésirable ; il ne remplit pas à lui seul tous ces reçus.

L’ordre était le véritable programme

Une liste de recherche ne se résume pas à une collection de suffixes. Elle exécute une politique. Il faut connaître l’éligibilité du nom à la complétion, l’ordre des candidats, les réponses qui font continuer ou arrêter, l’effet du cache et la place du nom enraciné.

Avec le même ensemble de suffixes, changer l’ordre peut changer le propriétaire de la première réponse. Avec le même ordre, accepter n’importe quel enregistrement ou seulement un type attendu peut changer le résultat. Avec les mêmes paquets sur le réseau, une réponse de cache peut masquer la question qui aurait autrement été envoyée.

RFC 1123, identifié par sa notice Host Requirements, traitait les mécanismes d’abréviation comme facultatifs. Il exigeait une convention pour les noms complets et demandait que la transformation du nom fourni en nom complet se fasse exactement une fois, dans le bon contexte. L’administrateur pouvait désactiver les listes de recherche.

Le même texte imposait une contrainte distincte pour ménager les serveurs racine : l’hôte devait pratiquer la mise en cache négative et/ou exiger un nombre minimal de points internes avant d’envoyer une requête non locale. Cette règle bornait le trafic ; elle ne désignait pas l’autorité habilitée à interpréter le nom saisi. Elle complétait donc, sans les remplacer, la limite locale et l’ordre des candidats.

L’expression « exactement une fois » empêche une chaîne de réécritures sans propriétaire. Si l’application complète, puis si la bibliothèque recommence, la requête finale ne révèle plus qui a introduit quel suffixe. La correction n’est pas seulement de réduire les paquets inutiles ; elle consiste à attribuer la décision à un composant identifiable.

BIND 4.9.2 réduisait l’implicite

La correction minimale proposée par RFC 1535 consistait à paramétrer la frontière de l’administration locale. Le résolveur pouvait employer le domaine de la machine tant qu’il restait sous les suffixes que l’organisation administrait effectivement. Il ne devait pas continuer automatiquement dans un espace public.

Le document décrivait aussi le comportement plus étroit de BIND 4.9.2 : limiter la recherche implicite à un petit nombre de formes, et essayer d’abord comme enraciné un nom contenant déjà un point. Les autres alternatives devaient apparaître dans une configuration explicite.

Il ne faut pas transformer cette règle en slogan selon lequel tout nom pointé serait universellement complet. Certaines organisations utilisaient des abréviations locales composées de plusieurs labels. Elles pouvaient les conserver. Mais leur choix devenait une configuration locale au lieu d’une permission générale donnée au logiciel de parcourir des suffixes publics.

L’explicite peut encore être erroné. Une liste mal ordonnée ou un suffixe qui n’est plus administré demeure dangereux. Son avantage est la responsabilité : on peut relire la configuration, en connaître la source, la versionner, la retirer et déterminer qui l’a approuvée.

La commodité ne devait pas devenir un mandat

Les noms courts répondaient à un besoin réel. Ils économisaient des frappes, préservaient des usages internes et rendaient certains outils tolérables. Une politique sérieuse ne nie pas ce bénéfice.

Elle demande qui reçoit le bénéfice et qui porte l’échec. L’utilisateur local voit immédiatement la commodité. Le coût d’une mauvaise complétion peut être supporté plus tard par une équipe sécurité, un responsable d’application, un autre opérateur DNS ou un utilisateur confronté à un mauvais point de terminaison. Cette dissociation incite à conserver des valeurs par défaut trop larges.

La solution de RFC 1535 déplace le choix vers l’autorité compétente : les abréviations locales restent possibles, mais leurs suffixes sont déclarés ; un nom comportant un point reçoit d’abord sa lecture enracinée ; la recherche implicite ne franchit plus aveuglément la frontière administrative.

Cette logique rejoint, comme grille éditoriale ultérieure, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption de Heng Lu : réduire le contrat partagé, conserver les décisions locales là où elles peuvent être assumées et éviter qu’une commodité ne devienne une règle universelle. Ce rapprochement n’attribue pas cette doctrine aux auteurs du RFC.

Une réponse DNS n’était qu’un reçu

Une réponse autoritative établit qu'un serveur a répondu pour une zone et un nom donnés. Une réponse de cache établit encore moins directement l’état actuel de l’autorité. Ni l’une ni l’autre ne prouve l’intention initiale de l’utilisateur.

La discipline de Running-Code Primacy oblige à regarder le résolveur réellement exécuté, sa configuration et ses sorties, plutôt que le seul statut du document. Celle des couches de réalité sépare la chaîne saisie, la règle de complétion, le candidat, la réponse, le point de terminaison choisi, l’authentification et le résultat applicatif.

Les documents voisins gardent eux aussi leur domaine. RFC 1536 et sa notice cataloguent des erreurs d’implémentation liées au trafic, aux reprises, à la récursion et aux caches. RFC 1537 et sa fiche traitent d’erreurs courantes dans les fichiers de données DNS. Ils éclairent l’effort de diagnostic de l’époque, sans prouver le parcours précis du résolveur de RFC 1535.

Conserver le registre des candidats

Le meilleur artefact d’incident commence par le nom exact saisi, point terminal compris. Il identifie l’application appelante, sa demande de recherche, la bibliothèque de résolution et son époque de processus, la source de configuration, la liste ordonnée, la frontière locale et chaque candidat produit.

Pour chaque requête, il faut garder l’heure, le transport, le code de réponse, l’autorité ou le cache, les données utiles, la chaîne CNAME et la raison de poursuivre ou d’arrêter. Ensuite seulement viennent l’identité canonique du point de terminaison, le résultat du transport, l’authentification et l’effet observé dans l’application.

Ce registre n’a pas à contenir de secrets. Pour une opération sensible, une empreinte bornée de la demande, l’identité de destination et l’issue de l’autorisation suffisent souvent à reconstruire le chemin sans copier un mot de passe.

RFC 1535 ne raconte donc pas seulement une faute ancienne de résolution. Il montre qu’un logiciel qui complète un identifiant exerce un pouvoir d’interprétation. Ce pouvoir doit être local, déterministe, visible et révocable. Une chaîne qui ressemble à un nom complet ne devrait pas devenir, en silence, une compétition entre administrations.

Sources