La Linux Foundation a officiellement lancé DNS-AID, un projet open source conçu pour résoudre l’un des problèmes les moins visibles mais les plus concrets du web agentique : comment des agents IA peuvent se trouver, se vérifier et communiquer entre eux sans dépendre de registres centralisés ni de configurations manuelles. Le projet, initialement développé par Infoblox, repose sur une idée d’une simplicité presque déconcertante — utiliser l’infrastructure DNS existante comme annuaire global pour les agents.
Le soutien est déjà solide : Cloudflare, CSC, Equinix, GoDaddy, Indeed, l’Internet Systems Consortium et WWT figurent parmi les premiers contributeurs. Tous partagent le constat que l’essor des agents autonomes exige une couche d’infrastructure commune, ouverte et neutre — faute de quoi, chaque plateforme développera son propre répertoire propriétaire, et l’interopérabilité sera la première victime.
Le DNS comme fondation pour le web agentique
Le parallèle avec l’histoire d’Internet est difficile à éviter. Quand le DNS a été créé dans les années 80, il a résolu un problème précis : transformer un nom de domaine lisible en adresse IP utilisable. Cette couche d’abstraction simple a ensuite permis à tout le reste de se construire dessus. DNS-AID part du même principe, appliqué aux agents IA.
Aujourd’hui, un agent qui veut en contacter un autre ne dispose d’aucune convention commune pour le trouver. Il s’appuie sur des URLs codées en dur, des registres privés ou des configurations manuelles — autant d’approches qui fonctionnent à petite échelle mais s’effondrent dès que des milliers d’agents doivent interagir entre différentes organisations, clouds et domaines. L’Internet Systems Consortium souligne que DNS-AID s’appuie sur des registres déjà standardisés (SVCB et HTTPS) pour publier des métadonnées sur les services disponibles. Ce n’est pas une réinvention de l’infrastructure Internet, c’est une extension de ce qui existe déjà.
Ce que fait concrètement DNS-AID
Le projet propose trois fonctions : publier des agents IA et serveurs MCP dans le DNS, permettre leur découverte par d’autres agents, et faciliter la vérification de leur identité. L’implémentation de référence inclut un SDK Python, une interface en ligne de commande et un serveur MCP prêt à l’emploi.
| Composant DNS-AID | Rôle |
|---|---|
| DNS comme annuaire | Publier et localiser des agents sur l’infrastructure mondiale existante |
| Vérification d’identité | Confirmer qu’un agent ou serveur appartient bien au domaine déclaré |
| Support MCP | Découverte standardisée des serveurs Model Context Protocol |
| SDK Python | Intégration pour développeurs et plateformes existantes |
| CLI | Usage en terminal et automatisation des opérations |
| Gouvernance Linux Foundation | Neutralité vendeur, évolution communautaire, adoption industrielle |
Le fait que la gouvernance soit assurée par la Linux Foundation n’est pas un détail symbolique. Beaucoup de standards Internet ont décollé non parce qu’ils étaient techniquement supérieurs, mais parce qu’ils bénéficiaient d’une neutralité perçue. Pour des entreprises qui hésitent entre plusieurs plateformes d’agents, cette neutralité peut être décisive.
Sécurité et identité : le vrai enjeu
L’aspect sécurité est probablement l’argument le plus fort en faveur de DNS-AID. Quand des agents deviennent des intermédiaires habituels entre applications, données et actions, les attaquants vont chercher à les usurper, empoisonner leurs réponses ou publier de faux agents dans des registres compromis. C’est le même problème que le phishing sur le web humain — mais avec des conséquences potentiellement plus larges, car un agent peut prendre des décisions autonomes.
Le phénomène du shadow AI complique encore le tableau. Des équipes métier déploient des agents sans supervision IT ou cybersécurité, créant des angles morts dans la gouvernance des systèmes. Une couche de découverte standardisée rend ces agents plus visibles — pas automatiquement plus sûrs, mais au moins identifiables. Le risque de compromission par crédentiels détournés reste entier, mais DNS-AID donne un cadre pour savoir ce qui tourne.
Indeed insiste sur la notion d’AgentCards et d’attestations vérifiables par tiers, qui construisent une confiance contextuelle basée sur l’identité de l’agent, de l’organisation qui l’opère et de l’environnement dans lequel il agit. Ce n’est pas l’élimination des risques, mais des bases vérifiables pour les gérer.
MCP et le risque de fragmentation
Le Model Context Protocol (MCP) s’est imposé comme standard de connexion entre modèles IA, outils, données et systèmes externes. Mais à mesure que le nombre de serveurs MCP augmente, la question de leur découverte devient pressante. Comment un agent sait-il qu’un serveur MCP de facturation existe dans son organisation ? Comment vérifie-t-il qu’il s’agit bien du bon serveur et pas d’un proxy malveillant ?
DNS-AID ne remplace pas MCP, il lui ajoute une couche de découverte. Un agent peut interroger le DNS pour trouver les serveurs MCP disponibles dans un domaine, vérifier leur authenticité et s’y connecter sans configuration manuelle. Dans des environnements multicloud ou hybrides, où différentes équipes gèrent des agents dans des domaines séparés, c’est une différence opérationnelle réelle.
Le risque de fragmentation est sérieux. Si chaque grande plateforme développe son propre registre d’agents avec ses règles de confiance et ses mécanismes de vérification propriétaires, le web agentique naissant reproduira exactement les problèmes d’interopérabilité qu’il a fallu vingt ans à régler sur le web classique.
Ce que l’adoption dira de la suite
DNS-AID est ouvert aux contributions sur GitHub. La vraie question n’est pas technique — le projet est solide — mais d’adoption. Est-ce que les fournisseurs DNS, les plateformes cloud, les éditeurs d’agents et les projets MCP vont se coordonner autour de ce standard, ou continuer à construire chacun leur propre répertoire ?
L’histoire des protocoles Internet suggère que les standards ouverts gagnent quand ils arrivent au bon moment, avec les bons sponsors et une implémentation de référence fonctionnelle. DNS-AID coche les deux premières cases. La troisième dépendra des équipes qui construisent des agents aujourd’hui : adopter ce cadre maintenant, ou attendre que quelqu’un d’autre le fasse à leur place.
Questions fréquentes
Qu’est-ce que DNS-AID ?
DNS-AID est un projet open source géré par la Linux Foundation qui utilise l’infrastructure DNS pour publier, découvrir et vérifier des agents IA et des serveurs MCP, sans dépendre de registres centralisés ni de configurations manuelles.
Pourquoi utiliser le DNS plutôt qu’un registre central dédié aux agents ?
Le DNS est une infrastructure mondiale, distribuée et neutre, déjà déployée partout. L’utiliser évite de créer une dépendance envers un fournisseur unique et s’appuie sur des mécanismes de confiance déjà en place, comme les certificats et les politiques DNSSEC.
DNS-AID est-il lié à MCP ?
Oui. DNS-AID inclut un support natif pour la découverte des serveurs MCP. Il joue le rôle d’annuaire : un agent peut interroger le DNS pour trouver les serveurs MCP disponibles dans un domaine et vérifier leur authenticité avant de s’y connecter.
Quelles entreprises soutiennent DNS-AID ?
Cloudflare, CSC, Equinix, GoDaddy, Indeed, l’Internet Systems Consortium et WWT soutiennent le projet. La gouvernance est assurée par la Linux Foundation pour garantir la neutralité vis-à-vis des fournisseurs.
DNS-AID résout-il tous les problèmes de sécurité des agents IA ?
Non. DNS-AID fournit une base pour la découverte et la vérification d’identité, mais ne remplace pas les contrôles d’autorisation, l’authentification forte ou les politiques de sécurité propres à chaque déploiement. C’est une couche parmi d’autres.
Source : Linux Foundation
