Résumé

  • IQUERY inversait l’agencement habituel du DNS : la requête fournissait un resource record dans Answer et attendait que le serveur inscrive les owner names correspondants dans Question.
  • L’autorité du DNS suivait les noms et les délégations de zone, non les valeurs arbitraires de RDATA ; une liste exacte dans le périmètre local pouvait donc rester incomplète à l’échelle du réseau.
  • La recherche exhaustive, les index secondaires, une mise en cache fragile, les réponses massives et l’exposition de données ont rendu cette incertitude coûteuse, tandis que PTR sous IN-ADDR.ARPA transformait l’inversion d’adresse en requête de nom ordinaire et délégable.

Une réponse était fournie avant la question

Dans une requête classique, le client inscrit un QNAME et un QTYPE dans Question. Le serveur ajoute les données demandées dans Answer. IQUERY commençait de l’autre côté. Un message pouvait contenir A IN 10.1.0.52 dans Answer, aucun élément dans Question, et l’opcode 1 dans son en-tête.

RFC 1035 précisait que le nom propriétaire et le TTL du record fourni n’avaient pas de signification. La racine, codée sur un seul octet nul, pouvait servir de nom provisoire. La réponse plaçait zéro, un ou plusieurs triplets QNAME, QTYPE et QCLASS dans Question, puis alignait le record de Answer sur le premier résultat.

La forme était ingénieuse. Le même format de message représentait une fonction dans les deux sens. Une requête standard associait un nom à une ressource ; IQUERY associait une ressource à des noms.

Mais cette réciprocité appartenait au paquet, pas à l’architecture. Un resolver muni d’un nom peut suivre l’arbre, recevoir des referrals et atteindre la zone qui porte l’autorité sur ce nom. Une adresse, une cible MX ou une chaîne contenue dans un autre type de record ne contient aucun chemin équivalent vers toutes les zones susceptibles de la publier.

Le défaut figurait déjà dans le cahier des charges de 1983

RFC 882 expliquait que le système de domaines ne pouvait garantir ni l’exhaustivité ni l’unicité d’une inverse query. Le DNS était organisé selon les domain names, et non selon les host addresses ou les autres resource types. Pour obtenir une garantie, le resolver devait connaître un serveur possédant les données pertinentes ou interroger tous les serveurs du domaine considéré.

Cette réserve ne décrivait pas seulement une faiblesse des machines de l’époque. Elle signalait l’absence d’un itinéraire vers l’autorité. Pour un nom, la délégation permet de découvrir qui répond dans un périmètre défini. Pour une valeur arbitraire, aucun parent n’indique quelle base contient tous les cas et aucune referral ne réduit progressivement l’espace de recherche.

RFC 883 traitait donc les inverse queries en fonction de l’environnement. Une entreprise pouvait choisir un serveur réputé détenir une copie suffisamment large de ses propres zones. Le résultat devenait utile à l’administration ou au diagnostic, sans acquérir une portée universelle.

La nuance sépare exactitude et complétude. Trois noms trouvés peuvent être trois associations parfaitement vraies. Un quatrième peut néanmoins résider dans une zone que le serveur ne charge pas. Dire vrai sur ce que l’on voit ne confère pas un mandat sur ce qui manque.

Le contrat réel tenait dans les connaissances d’une seule machine

RFC 1035 limite explicitement la réponse aux noms correspondant au record que le name server connaît. Aucun serveur ne connaît tout le domain space ; la liste ne peut donc jamais être tenue pour complète. La spécification réserve essentiellement IQUERY à la gestion de base et au débogage, puis interdit d’en faire la méthode normale de conversion d’une adresse en host name.

Une liste vide signifie que la source choisie n’a trouvé aucun match dans son corpus. Elle ne démontre pas une absence globale. Un résultat prouve une relation visible, pas l’unicité. Une longue liste peut rester limitée aux zones autoritatives du serveur, à son cache contingent ou aux types pour lesquels il a construit un index.

Une réponse négative ordinaire possède une frontière plus intelligible. Le nom interrogé conduit à une zone ; l’autorité de cette zone peut répondre sur l’existence de ce nom dans son espace. IQUERY ne définissait pas l’ensemble « tous les records qui contiennent cette valeur ». Pour prouver l’absence, il aurait fallu écarter chaque zone où la valeur pouvait apparaître.

Une recherche n’est donc pas forte uniquement parce que ses lignes sont justes. Il faut connaître l’univers inspecté, la personne qui le contrôle, le moment de l’observation et la méthode permettant d’identifier les partitions omises. Sans cette provenance, la mise en page d’une liste peut donner une illusion d’exhaustivité.

Inverser les accès revenait à entretenir une seconde base

Un name server range naturellement ses données sous les owner names, puisque les requêtes courantes commencent par QNAME. Une recherche rapide selon le contenu de RDATA exige un accès distinct.

RFC 883 envisageait des tables d’inversion séparées pour chaque zone et chaque clé prise en charge. Une modification de zone entraînait leur remise à jour. RFC 1035 opposait deux solutions : parcourir toute la base à chaque demande, ou maintenir une base auxiliaire indexée par les valeurs de la base principale. Le parcours paie le coût à la requête ; l’index le paie en mémoire, en synchronisation et en complexité permanente.

La comparaison n’était pas uniforme. Une RDATA peut être une adresse, un domain name, une chaîne ou une structure propre au type. RFC 1035 recommandait, lorsque cela était possible, des comparaisons insensibles à la casse, tout en reconnaissant qu’un serveur pouvait conserver des octets dont il ignorait le statut textuel. « Trouver cette valeur » n’était pas une seule opération sémantique.

Les incitations étaient également mal distribuées. Un demandeur distant envoyait une petite valeur. L’opérateur payait l’index, le scan, l’assemblage et la transmission. La requête ne démontrait ni son intérêt pour la zone ni une limite naturelle au nombre de réponses.

Publier individuellement des records DNS n’équivaut pas à promettre un service analytique sur tous les axes de leur contenu. IQUERY attachait pourtant cette fonction supplémentaire au serveur qui détenait déjà les données opérationnelles.

Le cache répétait la vue sans élargir son autorité

Le DNS passe à l’échelle grâce à des réponses réutilisables jusqu’à l’expiration de leur TTL. Les résultats IQUERY ne s’inséraient pas proprement dans ce mécanisme. RFC 1035 avertissait qu’ils ne pouvaient pas être mis en cache comme les réponses ordinaires.

Un hôte multihomed peut posséder plusieurs records d’adresse du même type. Retrouver son nom à partir d’une seule adresse ne livre pas forcément tout son RRset. Si le cache range le record extrait comme une réponse ordinaire attachée au QNAME reconstruit, il risque de transformer une relation partielle en ensemble complet apparent.

Le cache efface aussi facilement le corpus de départ. Une réponse issue des seules zones d’un serveur, enrichie peut-être de son cache, circule ensuite sans rappeler précisément ce qui n’a pas été interrogé. La diffuser davantage réduit le coût de répétition ; elle ne prouve toujours rien sur les zones absentes.

Dans une query normale, le lookup key, la délégation, l’autorité, le cache key et le TTL s’alignent autour du nom. IQUERY réutilisait l’enveloppe tout en rompant cet alignement. Chaque optimisation devait transporter une réserve encombrante : résultat valable uniquement pour ce que cette machine savait à cet instant.

PTR a donné un nom à la clé inverse

La solution durable pour les adresses n’a pas consisté à perfectionner une fouille mondiale par valeur. RFC 1034 décrit le domaine spécial IN-ADDR.ARPA. Les octets de l’adresse IPv4 y apparaissent dans l’ordre inverse, et un record PTR placé sous ce owner name pointe vers un domain name.

À partir de 10.1.0.52, le resolver fabrique un nom prévisible dans l’arbre inverse et lance une query standard. Les branches de cet arbre sont délégables. Les serveurs faisant autorité sont repérables, le RRset possède un TTL ordinaire, et un résultat négatif s’interprète dans une zone déterminée.

L’indirection est précisément ce qui répare l’autorité. PTR ne garantit pas que toute adresse aura un record, qu’une adresse n’aura qu’un nom ni que le nom retourné authentifiera un appareil. Il place seulement la déclaration inverse sous un nom dont le DNS sait localiser le responsable.

IQUERY demandait au système de découvrir un index inconnu à partir d’une valeur. PTR demande au responsable de l’espace inverse de publier une relation explicite à un nom connu. La recherche ouverte devient une récupération déléguée.

Une opération peu utile au client honnête mais assez utile à l’attaquant

En 2002, RFC 3425 a déclaré IQUERY entièrement obsolète. Le mécanisme n’avait pas été largement implémenté et les opérateurs désactivaient souvent les versions anciennes qui le proposaient. Le texte cite le code rarement exercé, les bugs, la charge et l’exposition de blocs de noms.

Certaines valeurs pouvaient produire des listes immenses. Chercher tous les domaines délégués vers le nameserver d’un grand fournisseur pouvait rendre des dizaines de milliers de triplets et plusieurs mégaoctets. Une demande compacte déclenchait ainsi un calcul et un transfert disproportionnés, exploitables pour épuiser des ressources.

Les inverse MX queries permettaient aussi de regrouper les nombreux noms partageant une infrastructure de messagerie. Le fait que chaque record soit public n’implique pas que l’opérateur accepte de fournir un catalogue regroupé selon n’importe quelle valeur. L’opération abaissait brutalement le coût de collecte.

Le client légitime souhaitait une réponse complète et ne pouvait l’obtenir. L’auteur d’un abus n’avait pas ce besoin : consommer du CPU ou de la bande passante, déclencher une grande réponse ou extraire un ensemble local suffisait. La faiblesse épistémique du mécanisme ne le protégeait donc pas contre l’abus.

Un opcode retiré garde sa signification

RFC 3425 n’a pas recyclé l’opcode 1. Le document a rendu obsolète la section correspondante de RFC 1035, demandé aux serveurs de répondre Not Implemented et réservé définitivement la valeur.

Ce choix évite qu’un ancien logiciel interprète une nouvelle opération selon la vieille sémantique. La retraite permanente conserve un sens unique dans l’histoire du protocole tout en supprimant l’attente de service. Un numéro inutilisé peut constituer une protection de compatibilité.

Le RFC observait qu’aucun client connu n’utilisait IQUERY pour un service significatif et que PTR sous IN-ADDR.ARPA assurait depuis longtemps le reverse mapping commun. Le retrait s’appuyait ainsi sur l’absence de dépendance vivante et sur l’existence d’une solution conforme à la structure du DNS.

DNSSEC rendait la difficulté de preuve encore plus visible. RFC 3425 juge extrêmement difficile de sécuriser les réponses IQUERY sans signature à la volée. Une zone signée peut authentifier des RRsets nommés et des preuves négatives organisées par noms. Une recherche arbitraire doit également prétendre qu’aucun match n’a été omis d’un univers que l’opération ne délimite pas.

Le serveur demeurait un témoin, pas le namespace

Un serveur DNS peut être un participant réel, posséder l’autorité sur plusieurs zones et conserver des données exactes. Ces qualités lui permettent de témoigner pour un périmètre précis. La faculté de fouiller sa copie ne lui donne pas autorité sur tous les noms extérieurs qui partagent une valeur.

Les notes de Lu Heng distinguent participation et autorisation, ainsi que l’administration d’un registre et le pouvoir sur les réalités enregistrées. IQUERY offre une miniature technique de cette séparation. Voir une donnée autorise une description de cette donnée ; cela n’autorise pas une conclusion sur les absences invisibles.

La correction n’a pas exigé un catalogue central plus vaste. Le DNS a maintenu une couche commune minimale : noms, délégations, types, TTL et records inverses explicitement publiés. Chaque acteur affirme dans une zone bornée ; chaque resolver suit des règles interopérables sans transformer un intermédiaire en observateur omniscient.

Limites des preuves

Les cinq RFC établissent la forme d’IQUERY, ses limites déclarées, le mécanisme PTR et la décision normative de retrait. Ils ne mesurent ni le trafic opcode 1 actuel, ni toutes les implémentations historiques, ni les usages privés qui pourraient subsister.

NOTIMP est le comportement attendu, pas la preuve qu’un paquet n’a jamais été analysé. Un timeout peut provenir d’un filtrage ou d’une panne. Une réponse positive prouve un traitement local, non une vue complète du DNS.

PTR ne constitue pas davantage une identité certifiée. Les données forward et reverse peuvent diverger, manquer ou être multiples. L’avantage étudié ici est la localisation d’une autorité pour une déclaration, pas la vérité automatique de toute déclaration publiée.

IQUERY indiquait le sens d’une question sans indiquer le sens de l’autorité. Un bit suffisait à inverser le message ; il ne pouvait pas inverser les délégations du système distribué. En exigeant que les relations inverses redeviennent des noms, le DNS a préféré une asymétrie vérifiable à une symétrie séduisante.

Sources