Résumé

  • Un HINFO synthétique reçu lors d’une requête ANY peut être conservé en cache et masquer ensuite le HINFO véritable de la zone. RFC 8482 recommandait un autre choix aux opérateurs qui utilisaient réellement ce type.
  • Une réponse non vide et normalement conservable pouvait limiter les nouvelles requêtes plus efficacement qu’un code de refus inconnu, susceptible de provoquer des essais auprès d’autres serveurs.
  • Les réponses minimales restent optionnelles et ne garantissent pas l’inventaire de tous les types disponibles. Leur taille, leur durée de cache et leurs conditions de signature sont des questions distinctes.

La donnée existait toujours ailleurs

Imaginons une application qui demande les informations HINFO d’un nom. La zone possède une fiche décrivant le processeur et le système d’exploitation. Mais le résolveur a précédemment conservé un autre HINFO, reçu en réponse à une requête beaucoup plus large. Tant que ce cache sert la demande, la fiche réelle peut rester hors de vue.

Ce n’est pas une panne inventée pour dramatiser une optimisation. Le RFC 8482, publié en janvier 2019, signale explicitement cette possibilité. Sa proposition de HINFO synthétique pour répondre à ANY peut affecter une demande ultérieure portant spécifiquement sur HINFO.

Le document conseille donc aux opérateurs dont les zones reposent sur l’usage traditionnel de HINFO de choisir la méthode fondée sur un ensemble existant, ou un autre type approprié. Une ressource peu utilisée n’est pas une ressource sans utilisateur.

Ce compromis est plus intéressant qu’un simple récit de réduction de taille. L’idée devait fonctionner avec des clients déjà déployés. Elle empruntait pour cela une structure qu’ils savaient conserver — et héritait des conséquences de cette conservation.

Une fiche conçue pour reconnaître des machines semblables

Le RFC 1035, de novembre 1987, définit HINFO avec deux chaînes de caractères : CPU et OS. Il décrit une source d’informations générales sur un hôte, notamment pour des protocoles comme FTP capables d’adapter certaines procédures à des machines ou systèmes de même type.

Dans la réponse synthétique recommandée par RFC 8482, le champ CPU contient la chaîne RFC8482 et le champ OS une chaîne vide. Le second champ reste présent : une chaîne de longueur nulle n’est ni un champ supprimé ni la découverte que la machine n’aurait pas de système d’exploitation.

Quand le serveur construit expressément cette réponse selon le mécanisme, le numéro du RFC n’est pas une observation matérielle. Il occupe une place dans un format existant afin de produire une réponse petite et exploitable par le cache.

Le destinataire ne doit pourtant pas renverser ce raisonnement. Le texte déconseille de conclure avec certitude, à partir de ces valeurs seules, que n’importe quel HINFO reçu a été synthétisé selon cette spécification. Les données ne constituent pas un indicateur authentifié de politique. Reconnaître une structure ne prouve pas comment elle a été produite.

ANY ne nommait pas tout le domaine

L’ambiguïté commence avant HINFO. Le type de requête 255 était représenté par une étoile dans RFC 1035 ; les implémentations l’appellent communément ANY. Le mot peut donner l’impression d’une commande capable de ramasser tout ce qui existe.

Or le RFC 1034 distingue le nom demandé, le type demandé et la classe. ANY dans QTYPE n’est pas une étoile dans QNAME. Ce n’est pas non plus AXFR, la requête particulière de transfert de zone. Interroger les types associés à un nom ne revient pas à énumérer tous les noms d’une zone.

L’algorithme historique distingue aussi les données de zone du cache. Les enregistrements disponibles dans ce dernier ne sont pas nécessairement tous ceux qu’un serveur faisant autorité pourrait fournir. Le cache ne devient pas un inventaire complet parce qu’on lui pose une question au nom généreux.

La table actuelle des paramètres DNS tenue par IANA décrit le type 255 en termes d’une partie ou de la totalité des enregistrements disponibles auprès du serveur. HINFO demeure le type 13, consacré aux informations d’hôte. Ces inscriptions établissent des identifiants et un sens, pas des statistiques d’usage actuelles.

Refuser pouvait multiplier les interlocuteurs

Les opérateurs avaient plusieurs raisons de limiter une réponse ANY traditionnelle. Le RFC 8482 cite le coût de traitement, la collecte de données de zone et l’attrait de grosses réponses UDP pour la réflexion avec adresses sources usurpées. Réduire la réponse peut diminuer cet attrait sans rendre secrètes les autres données DNS publiques.

Le texte reconnaît aussi des usages légitimes : diagnostic et examen de l’état d’un serveur pour un nom, ou tentative d’obtenir en une requête les ensembles MX, A et AAAA nécessaires à une application. Il avertit cette dernière qu’elle doit prévoir un autre moyen si l’hypothèse d’un retour exhaustif ne se réalise pas.

Une solution envisagée consistait à introduire un nouveau code de réponse pour signaler qu’un serveur ne fournissait pas la réponse traditionnelle. D’après le RFC, les résolveurs confrontés à ce code inconnu essayaient alors les autres serveurs faisant autorité au lieu de supprimer les répétitions de la même demande.

Le refus explicite avait donc une conséquence contraire au but recherché : il pouvait déplacer et multiplier le travail. Cette observation concerne l’approche discutée, non une loi selon laquelle tout code d’erreur ferait toujours recommencer tous les résolveurs.

Une réponse non vide offrait un autre chemin. Elle donnait au client quelque chose qu’il savait déjà mettre en cache. Le mécanisme pouvait ainsi modifier la suite des échanges sans exiger que chaque client apprenne une nouvelle signification de l’échec.

Trois méthodes laissaient un choix local

Le RFC 8482, document sur la voie de normalisation qui met à jour RFC 1034 et RFC 1035, décrit des comportements optionnels. Les cas concernés dans cette section portent sur un nom existant, la classe IN et QTYPE=ANY. Les autres règles habituelles continuent de s’appliquer sauf modification expressément décrite.

La première méthode sélectionne un ensemble d’enregistrements disponible, ou un petit sous-ensemble des ensembles disponibles au nom demandé. Elle ne signale pas au client que d’autres ensembles ont été omis. Ne pas voir TXT dans une telle réponse ne démontre pas l’absence de TXT.

La deuxième méthode peut synthétiser HINFO lorsque le nom concerné ne porte pas de CNAME. Elle recommande une seule fiche avec les chaînes déjà décrites. Cela ne demande pas de créer un HINFO permanent dans la zone ni d’inventer une existence pour un nom inexistant.

La troisième méthode tente de deviner le besoin : fournir les ensembles CNAME, MX, A et AAAA présents, tout en laissant de côté d’autres types, par exemple TXT ou DNSKEY. Cette approximation peut satisfaire certaines applications, mais produire une réponse plus grande et ne pas correspondre à l’intention réelle du demandeur.

Il n’y avait donc ni abolition générale d’ANY ni obligation universelle de répondre HINFO. Le choix restait chez l’opérateur et l’implémenteur, avec les limites propres à chaque méthode.

Un ensemble entier peut être une sélection partielle

L’expression « un seul ensemble » doit être prise au sérieux. Le RFC 2181, de juillet 1997, définit un RRset par le même nom, la même classe et le même type, avec des données éventuellement différentes. Il ne s’agit pas d’un enregistrement choisi au hasard dans un groupe de plusieurs.

Les règles de transmission exigent l’ensemble associé complet ; si un ensemble requis ne tient pas, les règles de troncature s’appliquent. Sélectionner un RRset parmi plusieurs types et couper un RRset en morceaux sont deux décisions différentes.

Le bit TC concerne lui aussi une situation précise, notamment l’impossibilité de faire tenir un ensemble nécessaire en entier. Son absence ne certifie pas que tous les types disponibles au nom ont été inventoriés. Le RFC 8482 prévient explicitement que la sélection de quelques ensembles n’est pas accompagnée d’un signal d’exhaustivité manquante.

Une application doit donc préciser ce dont elle a besoin. La complétude interne de la réponse fournie est utile, mais plus étroite que la promesse qu’elle pourrait être tentée d’y lire.

La durée du cache engageait la politique suivante

La TTL du HINFO synthétique devait être choisie par l’opérateur. Assez longue, elle pouvait réduire les répétitions fréquentes d’ANY par le même initiateur pour le même nom. Trop longue, elle pouvait compliquer une modification ultérieure de cette politique.

Le RFC ne transforme pas ce compromis en nombre unique. Il prévoit une valeur configurable, selon les considérations ordinaires du choix d’une TTL. RFC 2181 précise par ailleurs que la TTL est une durée maximale, non une durée que chaque cache serait obligé d’épuiser ; les implémentations peuvent la plafonner.

Le serveur ne contrôle donc ni un oubli parfaitement simultané ni une conservation identique partout. Changer sa propre réponse n’efface pas immédiatement les états déjà transmis à d’autres systèmes.

RFC 8482 permet le cache normal de la petite réponse. Son texte sur les initiateurs décrit aussi la possibilité de supprimer des requêtes ANY lorsqu’un HINFO correspondant est déjà en cache, ou d’y répondre normalement à partir du cache. Ce comportement permis ne transforme pas les valeurs HINFO en preuve certaine d’une origine synthétique, contre laquelle le même document met en garde.

Une petite réponse positive n’est pas un constat d’absence

La distinction avec les réponses négatives importe. Le RFC 2308, de mars 1998, traite NXDOMAIN comme une erreur de nom et NODATA comme l’absence du type demandé pour un nom valide, déduite du contenu de la réponse plutôt que d’un code distinct. Le cache négatif a ses propres conditions, dont le rôle des données SOA.

Un HINFO ou un sous-ensemble non vide reçu pour ANY n’est pas, par sa petite taille, une négation de tous les autres types. Un besoin précis appelle une requête précise. La place laissée vide dans l’inventaire du client ne doit pas devenir une affirmation du serveur.

Les transports ne donnent pas davantage une garantie universelle. Le RFC 8482 autorise des politiques différentes, par exemple une réponse traditionnelle sur TCP et minimale sur UDP. C’est une possibilité, pas une obligation ni la promesse qu’un passage à TCP obtiendra partout tout ce qui manque.

Réduire ne dispensait pas de signer

Le bit DO décrit dans le RFC 3225, de décembre 2001, indique la capacité à accepter les enregistrements de sécurité DNSSEC. Il ne prouve pas qu’une validation a déjà réussi et ne mesure pas la complétude d’une réponse ANY.

RFC 8482 maintient les exigences pertinentes de signature. Pour la forme synthétique, si DO vaut un et que le répondeur sait la zone signée, un RRSIG valide doit accompagner les ensembles concernés ; avec DO à zéro, il devrait être omis dans ce cas. Les méthodes utilisant les ensembles disponibles ou une estimation du besoin ont également leurs conditions de signature.

L’authenticité d’un ensemble retourné et l’énumération de tous les autres ensembles restent deux propriétés différentes. Une réponse réduite peut respecter ses obligations cryptographiques sans devenir pour autant la photographie exhaustive que l’application espérait.