Résumé

  • Un projet individuel publié en août 2026 propose que les serveurs DNS refusent normalement les requêtes ANY avec NOTIMP, sauf raison locale précise. Ce texte n’est ni un RFC ni une décision consensuelle de l’IETF.
  • La migration devrait se faire par finalité : nommer le consommateur, remplacer sa demande par les types d’enregistrements pertinents, tester sa décision et attribuer une échéance à toute exception. Une erreur DNS étendue explique éventuellement le refus ; elle ne certifie pas la disparition d’une dépendance.

Dans une organisation, les habitudes techniques survivent souvent à leur justification. Une commande inscrite dans une procédure devient un script. Le script entre dans la supervision. La supervision finit par participer à une décision de bascule. Lorsque l’infrastructure retire enfin la commande, elle ne rencontre plus une simple préférence d’administrateur : elle rencontre une dépendance dont personne n’a conservé le contrat.

DNS ANY est un bon révélateur de cette transformation. Son nom suggère une demande générale, presque un inventaire. Pourtant, obtenir une réponse à QTYPE 255 n’a jamais garanti un catalogue complet des données d’un nom. Un serveur faisant autorité, un résolveur récursif et un cache ne possèdent pas le même savoir. Les données disponibles au moment de la question varient. À une coupure de zone, la notion même d’ensemble pertinent dépend de la position du répondant. Le client ne peut pas déduire une connaissance exhaustive d’un mot aussi commode que « ANY ».

Le projet draft-jabley-dnsop-no-longer-support-any-00, daté du 6 août 2026, propose de réduire encore cette ambiguïté. Sa recommandation générale est de répondre avec le code RCODE 4, NOTIMP, à moins qu’une raison locale spécifique ne justifie de conserver l’interprétation historique des RFC 1034 et 1035, ou les réponses minimales autorisées par le RFC 8482. Le texte propose aussi une erreur DNS étendue indiquant que le serveur ne prend pas en charge ces requêtes.

La portée institutionnelle reste limitée. Il s’agit d’un Internet-Draft individuel actif, pas d’un texte adopté par DNSOP ni d’un RFC. Datatracker ne lui attribue pas de filière RFC et constate seulement l’existence du projet. L’intention Standards Track annoncée dans son en-tête exprime une ambition éditoriale, non une approbation collective. Une exploitation sérieuse peut examiner cette proposition sans transformer son futur éventuel en règle présente.

Le problème de sécurité ne définit pas tous les usages

Les grandes réponses DNS se prêtent à la réflexion et à l’amplification. Le RFC 5358 a décrit l’abus des serveurs récursifs ouverts ; le RFC 8482 explique notamment l’intérêt qu’ont pu présenter les réponses ANY volumineuses pour les attaquants. Construire et transmettre davantage de données coûte également du processeur, de la mémoire et de la capacité. Si le message grossit, fragmentation UDP et recours à TCP ajoutent leurs propres contraintes.

Mais ANY n’est pas la seule façon d’obtenir une amplification DNS. Retirer ce comportement ne dispense pas de contrôler l’exposition récursive, les ressources du service faisant autorité ou les autres réponses susceptibles d’être détournées. Le bénéfice d’un refus plus clair doit donc être décrit précisément : il réduit une obligation de réponse ambiguë et une surface utile à certains abus. Il ne constitue pas, à lui seul, une stratégie complète contre le déni de service.

Inversement, reconnaître des usages légitimes ne rend pas le comportement public obligatoire. Un technicien peut apprécier ANY pour une première inspection. Un ancien logiciel peut attendre une forme particulière de réponse. Un outil local peut chercher à examiner un cache. Ces raisons n’ont ni la même valeur ni les mêmes conditions d’accès. La question pertinente n’est pas « existe-t-il un usage utile ? », mais « quel usage, sous quelle autorité, avec quel remplacement et pendant combien de temps ? ».

Pour une vérification de messagerie, le besoin porte probablement sur MX et sur des résolutions complémentaires identifiées. Pour une délégation, il porte sur NS, la coupure de zone et les adresses nécessaires. Pour un protocole de découverte, les types prévus par ce protocole sont préférables à l’espoir qu’une réponse ANY fournisse ce qu’il faut. Pour une inspection de cache, une interface locale autorisée est plus honnête qu’un paquet distant présenté comme inventaire. Le remplacement dépend de la décision recherchée, non de la ressemblance entre commandes.

Faire apparaître la finalité avant de fermer le comportement

Une équipe DNS devrait constituer un registre des usages observés avant d’étendre le nouveau défaut. L’exercice n’exige pas de conserver indéfiniment tous les noms interrogés. Une fenêtre limitée, avec minimisation des données et accès contrôlé, peut suffire à répartir les appels par service receveur, catégorie de source, charge de travail interne connue, périodicité, transport et ordre de grandeur de la réponse. Le but est de produire une file de migration finie, pas un dispositif général de surveillance.

À chaque groupe récurrent, il faut associer une personne ou une équipe capable de répondre à trois questions. Quelle décision consomme le résultat ? Quel échec le consommateur tolère-t-il ? Quelle connaissance lui apporte réellement la réponse actuelle ? La dernière question est essentielle : un logiciel peut fonctionner aujourd’hui seulement parce qu’il rencontre habituellement un serveur accommodant. Sa dépendance est déjà fragile avant le premier NOTIMP.

Le registre doit ensuite indiquer une destination. Un usage nécessaire reçoit une requête explicite ou une interface adaptée, avec une version de client et un test d’acceptation. Un appel inutile est supprimé, puis surveillé pour détecter une régression. Un diagnostic propre à l’exploitation peut être déplacé vers une surface authentifiée et limitée. Un binaire impossible à modifier devient une exception temporaire, assortie d’un périmètre, d’un propriétaire, d’un contrôle compensatoire et d’une date de retrait.

La catégorie « inconnu » doit rester visible. Une source non attribuée n’est pas un usage innocent par défaut. Elle peut être un scanner, un client oublié, un partenaire ou une dépendance critique. Il n’est pas raisonnable de maintenir tout le service public pour elle ; il n’est pas davantage raisonnable de certifier une migration complète en l’effaçant du tableau. Elle appelle une décision explicite sur le risque résiduel.

Cette méthode permet de déployer par population. Les serveurs publics, les partenaires identifiés et les diagnostics internes ne sont pas obligés de partager la même exception. Un groupe de clients corrigés peut recevoir le refus pendant qu’un petit ensemble maîtrisé conserve un comportement provisoire. Ce qui justifie la différence doit être local, documenté et vérifiable. Une simple case « compatibilité » ne fournit aucune de ces garanties.

Une erreur étendue n’est pas un accusé de migration

NOTIMP rend le choix du serveur intelligible au niveau du protocole : la requête n’est pas mise en œuvre dans ce contexte. Il ne renseigne pas la finalité du client. Un résolveur récursif ou un transfert intermédiaire peut aussi influencer ce que l’application verra. Un client peut réessayer, changer de transport ou produire un message générique. Compter les refus renseigne sur le nouveau comportement ; cela ne remplace pas l’identification des consommateurs.

Le RFC 8914 ajoute avec EDE un mécanisme d’explication. Il ne modifie pas le traitement du RCODE. Plusieurs erreurs étendues peuvent être présentes. Leur transfert ou leur réécriture dépend des implémentations. Le texte supplémentaire facultatif est destiné à l’être humain ; il peut disparaître lorsque la taille du message doit être réduite.

L’erreur proposée par le nouveau projet peut donc aider un opérateur à reconnaître une politique intentionnelle plutôt qu’une panne obscure. Elle ne doit pas devenir un langage de contrôle fondé sur une phrase. Une application ne devrait pas analyser une explication en anglais pour décider quels RRtypes demander. Une équipe ne devrait pas déclarer une dépendance corrigée parce que cette explication traverse son résolveur.

La preuve de migration se trouve ailleurs : dans la version effectivement déployée, la requête de remplacement et la décision fonctionnelle obtenue. Une explication peut améliorer le diagnostic sans garantir le résultat. Confondre ces deux propriétés fabriquerait un indicateur séduisant, facile à satisfaire et institutionnellement trompeur.

Tester le consommateur, pas seulement le serveur

Le test technique élémentaire envoie ANY et vérifie RCODE 4. Le test qui compte reproduit le travail de l’application. Un contrôle de messagerie doit encore obtenir les bons enregistrements, y compris les cas d’absence pertinents. Un diagnostic de délégation doit distinguer une réponse faisant autorité d’un renvoi et traiter les recherches d’adresses nécessaires. Un outil de découverte doit demander tous les types que son protocole exige, sans transformer la migration en rafale indiscriminée de requêtes.

Les réponses partielles méritent autant d’attention que les réponses heureuses. Une troncature, une erreur de validation DNSSEC, un délai TCP ou un cache incomplet peut faire diverger la conclusion du client. Comparer uniquement les codes de retour masque cette divergence. Il faut tester les chemins récursifs et faisant autorité séparément, puis les intermédiaires réellement présents dans le déploiement.

Il faut également attendre les événements qui réveillent une dépendance dormante : expiration du cache, bascule, changement de délégation, renouvellement ou remise en service d’un système rarement utilisé. L’absence immédiate d’incident ne démontre pas que le dernier appel a disparu. Une période d’observation pertinente dépend du cycle de l’usage, pas du rythme de livraison de l’équipe DNS.

Une exception bien gouvernée contient donc un propriétaire, une population, une finalité, un substitut prévu et une échéance. Si l’un manque, l’organisation a déplacé l’incertitude plutôt que fermé l’usage. Le principe est plus exigeant qu’une désactivation uniforme, mais aussi plus durable : il retire la commodité sans oublier la décision qui s’était cachée derrière elle.

Sources

  1. Fiche actuelle du projet
  2. Historique du projet
  3. Révision 00 en HTML
  4. Révision 00 en texte
  5. Source XML de la révision 00
  6. Charte de DNSOP
  7. Documents de DNSOP
  8. RFC 1034 : concepts du DNS
  9. RFC 1035 : spécification du DNS
  10. RFC 6895 : paramètres DNS et IANA
  11. RFC 8482 : réponses minimales à ANY
  12. RFC 8914 : erreurs DNS étendues
  13. RFC 5358 : abus des serveurs récursifs
  14. RFC 9364 : sécurité et exploitation du DNS
  15. RFC 9499 : terminologie DNS
  16. RFC 7766 : transport DNS sur TCP
  17. Registre IANA des paramètres DNS
  18. Registre des codes EDE
  19. Lu Heng : spécification initiale minimale et décision locale
  20. Lu Heng : le miroir de la politique