Résumé

  • RFC 3425 a retiré définitivement l’opcode DNS 1, IQUERY, et demandé aux serveurs de répondre Not Implemented ; ce refus portait sur l’opération, pas sur l’existence d’un nom.
  • La résolution inverse a continué avec des enregistrements PTR explicites dans un espace délégué. NOTIMP, NXDOMAIN, NODATA et une validation DNSSEC ne répondent pas à la même question.

Un arrêt avant toute recherche

Un ancien outil envoie l’opcode 1. Le serveur répond NOTIMP. Si l’interface affiche aussitôt « nom inverse absent », elle invente une conclusion : le serveur a rejeté une méthode, il n’a pas nécessairement interrogé un owner name.

Publié en novembre 2002, RFC 3425 a rendu IQUERY entièrement obsolète, remplacé la section 6.4 de RFC 1035 et recommandé Not Implemented à sa réception. Cette réponse peut donc être la preuve d’un comportement conforme. Elle n’est ni NXDOMAIN, ni NODATA, ni un constat sur un PTR.

Le refus a un objet précis : l’opération demandée n’appartient plus au service normal.

L’ancienne question retournait une base locale

Dans RFC 1035, le client plaçait une valeur de Resource Record dans la section réponse et demandait au serveur de fournir les triplets type, nom et classe correspondants. Il ne formait pas un nom sous in-addr.arpa.

Pour répondre de façon générale, il fallait parcourir les données ou entretenir un second index par valeur. RFC 1035 signalait déjà la charge. RFC 3425 ajoutait le risque d’une réponse énorme : chercher tous les domaines délégués vers le nameserver d’un grand opérateur pouvait produire des dizaines de milliers de triplets.

Une petite requête pouvait ainsi déclencher une énumération coûteuse, exposer des blocs de noms et traverser du code ancien peu exercé. Le problème n’était pas seulement la performance ; il concernait aussi la portée de ce que le serveur local était autorisé à dire.

Aucun chemin vers l’autorité pertinente

Une résolution DNS ordinaire suit les délégations d’un nom. IQUERY demandait ce que le serveur contacté possédait dans sa propre base. Si la valeur pertinente vivait ailleurs, la requête n’offrait pas de direction naturelle pour atteindre cette autre autorité.

Deux serveurs pouvaient renvoyer des ensembles différents sans se contredire : ils n’avaient pas les mêmes données. Un serveur pouvait refuser IQUERY tout en hébergeant des RRsets utiles. Le résultat ne pouvait donc pas signifier « tous les noms associés à cette valeur dans le DNS ».

Cette limite sépare l’inversion d’une base d’une recherche dans un espace de noms délégué.

PTR a donné une adresse à la question inverse

La solution largement employée consistait à publier la relation comme donnée DNS. Pour IPv4, on construit un owner name sous in-addr.arpa et on demande son PTR. RFC 1033, RFC 1034 et RFC 1035 décrivent le cadre ; RFC 2317 montre que les blocs plus petits qu’un /24 exigent eux aussi une délégation explicite.

PTR ne promet ni exhaustivité ni identité. Il rend toutefois la requête routable : owner name précis, chaîne de délégation, autorité, TTL et éventuellement état DNSSEC. Une absence peut être exprimée par les mécanismes négatifs du DNS au lieu d’être déduite d’une opération abandonnée.

Les erreurs ne sont pas interchangeables

NOTIMP concerne la prise en charge d’une opération. NXDOMAIN concerne l’existence d’un owner name. NODATA indique qu’un nom existe sans le type demandé. Un délai dépassé indique seulement qu’aucune réponse acceptable n’est arrivée dans la fenêtre d’observation.

RFC 8020 a précisé l’usage d’un NXDOMAIN faisant autorité ; il n’a pas converti NOTIMP en NXDOMAIN. RFC 8499 fournit un vocabulaire qui aide à conserver ces états.

Après un refus IQUERY, l’action utile est une nouvelle requête PTR correctement formée. Après NXDOMAIN, il faut conserver l’autorité et le contexte de cache négatif. Une panne de validation ne doit pas être recodée en absence ordinaire.

Le numéro retiré reste occupé par son histoire

RFC 3425 a inscrit l’opcode 1 comme « IQUERY (obsolete) » et demandé sa retraite permanente. Le registre IANA des paramètres DNS et RFC 6895 maintiennent cette trace.

Retiré ne signifie pas libre. Une réaffectation rendrait les vieux paquets ambigus. La réservation protège la lecture historique et interdit une collision future. Elle ne prouve pas, en revanche, que tout code ancien a disparu : registre, binaire, configuration et observation réseau restent des couches distinctes.

Une signature exige une donnée explicite

RFC 3425 notait que sécuriser les réponses IQUERY par DNSSEC serait extrêmement difficile sans signature à la volée. Une inversion synthétique et potentiellement massive n’est pas un RRset préexistant à un owner name.

RFC 4033, RFC 4034 et RFC 4035 définissent la validation de données DNS explicites et de certaines preuves négatives. Un PTR validé peut attester l’assertion signée de la zone. Il n’atteste pas automatiquement l’attribution de l’adresse, le contrôle de la machine, la cohérence aller-retour, l’accessibilité ou l’identité applicative.

Un NOTIMP IQUERY ne devient pas une preuve négative DNSSEC parce qu’il est transporté dans un message DNS.

La valeur d’un refus bien qualifié

RFC 3425 n’a pas supprimé la résolution inverse. Il a fermé une voie coûteuse et sans autorité globale, tout en laissant l’espace PTR explicite répondre à une question mieux définie.

La leçon durable tient dans le sujet du reçu. Une opération est refusée ; un nom est inexistant ; un type manque ; un RRset est validé ; une application réussit. Si ces propositions restent séparées, le refus est informatif. Si elles deviennent toutes « introuvable », l’exploitation fabrique une absence que le protocole n’a jamais observée.

Sources et limites

Le dossier primaire comprend RFC Editor HTML, le texte, la fiche RFC Editor, la fiche Datatracker, son historique, ses références et la recherche d’errata. Le contexte DNS vient de RFC 1033, RFC 1034, RFC 1035, RFC 2317, RFC 6895, RFC 8499, RFC 4033, RFC 4034, RFC 4035, RFC 8020 et du registre IANA. La distinction entre symbole et fonctionnement suit les essais de Heng Lu sur les couches de réalité et la primauté du code exécuté.

Ces sources n’établissent ni déploiement actuel, ni serveur vulnérable nommé, ni attaque mesurée, ni exhaustivité PTR, ni identité, disponibilité, autorisation ou résultat applicatif.