Résumé

  • Une règle MUD exprimée par un nom DNS n’est pas directement exécutable par un pare-feu : le contrôleur doit la convertir en un ensemble d’adresses daté, alors que l’objet peut interroger un autre résolveur, à un autre instant et depuis une autre localisation.
  • Le dossier probant doit relier le fichier du fabricant, le nom fonctionnel, les deux chemins de résolution, les réponses et TTL, la génération de l’ACL, son installation, la décision sur le paquet, l’identité du service et l’état final de l’objet.

Deux réponses DNS peuvent être valides et pourtant incompatibles pour un contrôle d’accès. Le contrôleur interroge depuis un centre de données européen ; le capteur utilise le résolveur annoncé par sa passerelle asiatique. Un CDN adapte sa réponse à chacun. Le premier ensemble devient une ACL, le second devient la destination réelle. Lorsque le paquet est rejeté, l’alerte dit « écart de politique ». Elle ne dit pas encore qui s’est trompé.

La RFC 9726 traite précisément cette zone intermédiaire. Son sujet n’est pas seulement le choix entre noms et adresses. Il est la conversion d’une intention stable en règle locale, temporaire et dépendante d’un point d’observation.

Le fichier MUD décrit une attente, pas un paquet

La RFC 8520 permet à un fabricant de publier une Manufacturer Usage Description. Celle-ci annonce les communications attendues d’un type d’objet. Elle peut autoriser une destination par nom DNS, ce qui évite de figer dans le produit chaque migration d’hébergeur, chaque adresse IPv6 ou chaque variation de CDN.

Le pare-feu, lui, ne reçoit pas ce nom avec le paquet. Il voit des adresses IP et des ports. Le chemin HTTP est chiffré, et l’adresse partagée ne révèle pas le locataire. Le contrôleur MUD doit donc résoudre le nom, construire un ensemble d’adresses puis installer une règle.

Cette opération ajoute une autorité locale que le document du fabricant ne possède pas. Le contrôleur choisit un résolveur, un instant, une politique de cache, une manière de suivre les alias et un rythme de rafraîchissement. Le compilateur choisit une représentation. Le pare-feu confirme qu’il a chargé cette représentation. Aucun de ces reçus ne prouve que l’objet obtiendra le même ensemble au moment de se connecter.

Il faut conserver la séparation. Le fichier MUD authentifié dit ce que le fabricant déclare nécessaire. La réponse DNS dit ce qu'un résolveur a répondu à un instant. L’ACL dit ce que le réseau a décidé d’autoriser. Le journal du paquet dit ce qui a été exécuté. Le résultat applicatif dit si l’objet a réellement accompli sa tâche.

L’exhaustivité compte davantage que l’ordre

Dans le cas historique de répartition décrit par la RFC 1794, un serveur peut permuter un ensemble complet d’adresses. Deux réponses dont seul l’ordre varie restent compatibles avec une ACL couvrant tout l’ensemble.

Le problème apparaît lorsque l’ensemble n’est plus complet. Un service géographique ne renvoie que les cibles proches. Un cache conserve un groupe antérieur. Un intermédiaire tronque ou recompose la réponse. Un alias ajoute un fournisseur dont la sélection évolue. Le contrôleur et l’objet ne disposent alors pas de deux ordres du même ensemble, mais de deux ensembles différents.

L’option de sous-réseau client de la RFC 7871 rend visible une partie du contexte topologique, sans garantir que tous les acteurs la transmettent ou l’interprètent de façon identique. Un résolveur peut l’ignorer, la réduire ou la remplacer. La précision géographique annoncée n’est donc pas une preuve d’équivalence entre les vues.

Le TTL ajoute une horloge. Le contrôleur peut respecter parfaitement le TTL d’une réponse devenue différente de celle que l’objet vient de recevoir. On ne peut pas conclure à une faute de cache simplement parce que l’ensemble est ancien au regard du paquet. Il faut comparer l’heure de requête, l’expiration, le résolveur et le changement autoritatif.

Partager le résolveur, c’est partager une partie du destin

La RFC recommande, lorsque c’est possible, que l’objet et le contrôleur consultent le même résolveur récursif. Ils partagent alors le cache, le choix géographique et la durée de vie du même jeu de données. Dans une passerelle domestique, le résolveur, le contrôleur MUD et le point d’application peuvent redémarrer ensemble ; leur état converge plus naturellement.

Une gestion distante casse cette proximité. Le contrôleur du fabricant peut être dans le cloud, ignorer le résolveur de l’entreprise ou ne pas pouvoir l’interroger. Une politique centrale supposée homogène devient alors une collection de projections locales non observées.

Les options DNS des annonces de routeur IPv6 sont définies par la RFC 8106. La RFC 9462 et la RFC 9463 permettent de découvrir des résolveurs chiffrés désignés par le réseau. Elles offrent une voie utile : protéger la requête locale tout en maintenant une vue commune pour l’objet et le contrôle.

Ce choix n’élimine pas les arbitrages de vie privée. Un résolveur externe chiffré cache les noms aux observateurs locaux, mais les révèle à son opérateur. Un résolveur local non chiffré expose les requêtes sur le réseau d’accès. Un résolveur local chiffré réduit cette exposition, sans rendre le réseau omniscient ni le service infaillible.

Oblivious DoH sépare encore l’adresse du client et le contenu de la requête. Cette propriété protège l’utilisateur contre une concentration d’informations ; elle ne fournit pas automatiquement au contrôleur MUD le jeu d’adresses qui a guidé l’objet. Confidentialité et observabilité de l’application restent deux décisions distinctes.

Un nom fonctionnel est une frontière contractuelle

La recommandation la plus durable de la RFC 9726 consiste à utiliser des noms contrôlés par le fabricant et séparés par fonction. Un nom pour les mises à jour, un autre pour la télémétrie, un autre pour l’heure : cette architecture rend les droits compréhensibles et révocables.

Le fabricant peut faire pointer ces noms vers un CDN. Mais il doit alors choisir des noms stables en aval et éviter une personnalisation que le contrôleur ne peut pas reproduire. Une URL renvoyée par un protocole applicatif vers un nom arbitraire échappe à la description préalable. Une redirection vers un autre fournisseur peut être parfaitement valide pour HTTP tout en étant impossible à autoriser dans une ACL prévue la veille.

À l’autre extrême, autoriser un grand domaine d’hébergement partagé résout le problème de stabilité en abandonnant la précision. Le pare-feu voit l’adresse et le port, pas le chemin HTTPS. Il ne peut pas distinguer l’objet du fabricant de milliers d’autres objets servis par la même infrastructure.

Les adresses littérales ne rendent pas le système souverain. Elles enferment le changement dans le firmware, compliquent la coexistence IPv4/IPv6, nuisent à l’identité TLS et rendent une migration d’urgence dépendante d’une mise à jour qui peut précisément ne plus être accessible.

Le DNS inverse ne recrée pas l’intention

Une enquête après coup peut tenter de transformer l’adresse rejetée en nom. L’annexe de la RFC 9726 explique pourquoi ce raccourci échoue. La résolution inverse peut être trop lente pour l’admission d’un paquet, incomplète, indiscrète ou sans rapport avec le nom réellement utilisé. L’hébergement virtuel fait correspondre plusieurs noms à une adresse ; les espaces à joker ne possèdent pas de liste inverse finie.

Le PTR peut fournir un indice. Il ne peut pas prouver la chaîne causale « l’objet a résolu le nom autorisé, a reçu cette adresse, puis s’y est connecté ». Cette chaîne doit être enregistrée au moment de la résolution et de la compilation.

Le faux positif finit par devenir un choix de gouvernance

La RFC 9726 ne traite pas le bruit comme un simple défaut d’interface. Un fichier MUD inexact produit des exceptions factices. Les équipes paient chaque alerte en temps et en attention. Lorsque le bruit se répète, elles désactivent ou ignorent le mécanisme. La prochaine alerte légitime perd alors son témoin.

Le conseil de préférer un fichier « suffisamment bon », parfois légèrement plus permissif, ne signifie pas que l’ouverture est toujours sûre. Il signifie qu’une précision impossible à maintenir détruit la discipline qu’elle prétend imposer. Une exception temporaire doit être limitée à une fonction, une identité de service, une durée et un plan de retour. Une autorisation générale donnée sous pression ne doit pas devenir la nouvelle base.

Avant d’élargir la règle, l’opérateur doit qualifier la divergence. Le nom était-il prévu ? Le résolveur était-il celui désigné ? La réponse était-elle encore dans son TTL ? L’alias a-t-il changé de fournisseur ? L’ACL courante a-t-elle été effectivement installée ? Le serveur a-t-il présenté la bonne identité TLS ? L’objet demandait-il une mise à jour authentique ?

Chaque réponse désigne un responsable différent. Sans cette analyse, « violation par l’objet » devient une catégorie commode qui masque les erreurs du fabricant, du CDN, du contrôleur ou de l’exploitation locale.

L’accès au firmware n’est pas la validation du firmware

La RFC 9019 décrit une architecture de mise à jour où manifeste, autorisation, vérification, installation et récupération ont des rôles propres. La règle réseau ne fait qu’autoriser un trajet. Elle n’authentifie pas l’image, ne décide pas qu’elle convient à ce modèle, ne prouve pas son installation et ne garantit pas que l’objet a redémarré sainement.

Cette distinction empêche deux erreurs symétriques. Bloquer une nouvelle adresse peut priver une flotte d’un correctif critique. Autoriser aveuglément toute destination présentée comme « mise à jour » peut exposer la même flotte. La continuité exige une exception contrôlée et une preuve cryptographique et opérationnelle du contenu.

Le dossier final doit donc relier le fichier MUD et sa révision, le nom fonctionnel, la découverte du résolveur, les réponses exactes, les TTL, la génération de l’ACL, l’accusé d’installation, le paquet, l’identité du serveur, le manifeste, le résultat d’installation et la santé de l’objet.

La doctrine de spécification minimale de Lu Heng attribue au standard ce qui doit interopérer : une façon commune d’exprimer l’usage prévu. Elle laisse au réseau la décision locale sur les résolveurs, les exceptions et le risque métier. La discipline des couches de réalité empêche le nom, la réponse, la règle et le résultat de se confondre. La primauté du code en fonctionnement donne plus de poids au journal du résolveur, au hachage de configuration et à l’état observé de l’objet qu’à un fichier déclaré « conforme ».

La RFC 9726 ne demande donc pas au DNS de devenir un pare-feu. Elle demande aux opérateurs d’avouer le moment où ils transforment une réponse en pouvoir de filtrage.

Sources