Résumé

  • RFC 10029 conserve une question DNS principale et ajoute les autres QTYPE dans une option EDNS. La réponse n’énumère que les types supplémentaires entièrement traités avec le même RCODE et les mêmes indicateurs que la question principale.
  • Un paquet commun ne crée ni instantané atomique ni autorité commune. Tout type demandé mais non listé doit être interrogé séparément ; zone, signataire, TTL, cache et usage applicatif restent des preuves distinctes.

Prenons une requête de délégation. Le client choisit DS comme question principale et ajoute NS. Le serveur parent produit une réponse DS marquée comme faisant autorité. Les données NS présentes du côté parent n’ont pas le même statut. S’il les plaçait sous le même indicateur AA, l’en-tête attribuerait à l’un des deux ensembles une qualité qu’il n’a pas.

La solution de RFC 10029 n’est pas de lisser le conflit. Le serveur laisse NS hors de MQTYPE-Response. Le paquet DS est valable ; la question NS reste ouverte.

C’est le point de gouvernance caché dans une optimisation de protocole : la proximité matérielle des données ne leur confère pas une provenance commune.

RFC 10029, publié sur la voie des normes en juillet 2026, répond au besoin de recevoir plusieurs types liés sans multiplier systématiquement les échanges. A, AAAA et HTTPS forment l’exemple évident. Pourtant, le protocole DNS ordinaire ne peut pas simplement accumuler des questions. RFC 9619 impose une seule question pour l’opcode QUERY et exige FORMERR si QDCOUNT dépasse un.

RFC 10029 maintient donc un triplet principal — nom, classe et type — puis inscrit les types de données supplémentaires dans EDNS. L’extension respecte la frontière existante au lieu de la contourner.

Demander n’est pas recevoir

MQTYPE-Query, code 20, énonce les types supplémentaires souhaités. MQTYPE-Response, code 21, atteste ceux qui ont été traités en entier. Le registre DNS de l’IANA classe aujourd’hui les deux options comme facultatives.

Le choix de deux codes a une fonction de sécurité opérationnelle : un équipement intermédiaire qui recopierait mécaniquement une option de requête ne doit pas pouvoir passer pour un serveur qui a construit une preuve de complétude. Si l’option de réponse manque, si l’option de requête revient par erreur ou si des types sont dupliqués, le client traite le mécanisme comme non pris en charge ou invalide.

Même une liste vide a un sens précis. Elle dit que le serveur a compris l’extension mais n’a achevé aucun type additionnel. Elle ne dit pas que ces types n’existent pas.

Ce mécanisme ne remplace pas ANY. RFC 8482 autorise une réponse minimale à une requête ANY ; le serveur peut notamment choisir un seul RRset. Il ne remplace pas davantage plusieurs questions, interdites par RFC 9619. Sa valeur vient de ce reçu explicite, pas d’une promesse vague de « tout rendre ».

Le type principal fixe la forme commune

Le serveur construit d’abord la réponse principale et arrête son RCODE ainsi que ses indicateurs. Si cette réponse est déjà tronquée, les types additionnels ne sont pas traités. Pour chacun d’eux, le serveur évalue ensuite le résultat qui aurait été produit seul.

Un type supplémentaire n’entre dans le paquet que si son RCODE et ses indicateurs compatibles correspondent à ceux du principal. Une réponse principale NOERROR ne peut donc pas absorber un résultat SERVFAIL. Une réponse faisant autorité ne peut pas accueillir, sous le même AA, un ensemble qui ne l’est pas.

La clarification de RFC 2181 sur le classement des données demeure pertinente, mais un rang commun n’abolit pas l’origine. Les RRsets peuvent être également recevables tout en dépendant de responsables et de preuves différents.

La taille fabrique une absence sans négation

Pour chaque QTYPE ajouté, l’inclusion est entière. Les enregistrements sont placés dans les sections où une requête autonome les aurait produits ; les doublons d’une même section sont éliminés. Si l’ensemble nécessaire ne tient pas dans la limite de taille ou de travail, le type n’est pas inscrit dans MQTYPE-Response.

Le serveur ne doit pas provoquer une troncature uniquement pour satisfaire un type additionnel. On peut donc recevoir TC=0 et pourtant ne pas avoir obtenu tous les types demandés. La complétude du datagramme et celle du besoin applicatif sont deux mesures différentes.

RFC 6891 rappelle que l’enregistrement OPT n’est pas mis en cache et que la taille UDP annoncée ne garantit pas la capacité réelle du chemin. Un pare-feu peut bloquer les fragments ; un équipement intermédiaire peut perturber l’option malgré les exigences de conformité. Le support doit être observé par trajet et par transaction, non transformé en attribut éternel d’un résolveur.

L’omission ne donne pas la cause

Le texte énumère quatre familles possibles : absence dans le cache du résolveur récursif, incompatibilité de RCODE ou d’indicateurs, refus ou limite de travail, limite de taille. L’option ne choisit pas entre elles.

Un HTTPS omis n’est donc pas une preuve de non-existence. Ce n’est ni un NXRRSET, ni une décision de politique, ni une réponse négative complète. RFC 2308 encadre les réponses négatives et leur cache ; RFC 4035 encadre leur validation DNSSEC. Une simple absence de la liste MQTYPE ne transporte pas ces garanties.

Le client doit relancer une requête autonome pour chaque type encore nécessaire. Ce retour au chemin classique est le mécanisme de correction. Le supprimer pour préserver un indicateur de performance transforme une optimisation facultative en perte silencieuse d’information.

Une enveloppe, plusieurs histoires

RFC 10029 avertit que les enregistrements peuvent provenir de zones différentes et que les preuves d’inexistence peuvent être signées par des acteurs différents. Les TTL ne sont pas alignés par le regroupement. Le cache peut avoir appris A hier, AAAA il y a une minute et HTTPS à l’instant. Leur livraison simultanée ne remonte pas leurs horloges à une origine commune.

La terminologie de RFC 9499 permet de conserver ces distinctions : serveur faisant autorité, résolveur récursif, cache, RRset et preuve ne sont pas des synonymes d’un « lookup » global. Les journaux doivent descendre jusqu’au RRset.

Même lorsque HTTPS est bien livré, l’application n’a pas encore choisi. RFC 9460 laisse au client l’évaluation des paramètres obligatoires, des priorités, des adresses et de la connexion. Le reçu DNS ne prouve ni compréhension ni usage.

Le registre de complétude

Pour chaque tentative, conserver le nom et la classe, le QTYPE principal, la liste ordonnée des types ajoutés, le trajet vers le résolveur, la taille EDNS annoncée, la présence exacte de l’option de réponse, la liste achevée, le RCODE, AA, AD et TC. L’écart entre liste demandée et liste achevée devient un objet de suivi, pas une ligne perdue dans un journal.

Pour chaque type rendu, enregistrer les RRsets et preuves nécessaires, la zone d’origine, le statut d’autorité, le signataire, le résultat DNSSEC, le TTL, l’origine cache ou réseau et l’heure d’observation. Rattacher ensuite les requêtes autonomes, le choix applicatif et le résultat de connexion au même identifiant de décision.

Quatre états restent séparés : paquet reçu, type complètement répondu, RRset validé, besoin applicatif satisfait.

La primauté du code exécuté formulée par Heng Lu interdit de confondre la publication d’une norme avec son adoption. Sa spécification initiale minimale et l’adoption volontaire donnent une architecture adaptée : format commun étroit, validation déterministe, limites locales, compatibilité explicite et sortie par la requête ordinaire. Son principe de réalité plutôt que plaidoyer impose enfin le vocabulaire juste : l’IANA décrit une possibilité enregistrée ; seuls les paquets, les listes complètes, les validations et les résultats décrivent le fonctionnement.

L’enveloppe peut être commune. L’autorité ne l’est pas.