The Linux Foundation now hosts DNS-AID (DNS AI Discovery), an open-source project originally created by Infoblox to use the DNS as a decentralized directory for AI agents. The project is defined in an IETF draft first published in October 2025 under the name BANDAID (Brokered Agent Network for DNS AI Discovery) and later refined. The initial draft had four signatories from Infoblox, Deutsche Telekom, and the IEEE; a fifth, from Amazon, joined the May 27, 2026 version. Although not an official member of the Linux Foundation project, Amazon contributes to the reference implementation, whose GitHub repository has been open since January and is maintained by three Infoblox employees.

DNS-AID defines a model for using DNS namespaces and records—primarily SVCB—to exchange metadata and declare agent capabilities. It supports two discovery mechanisms, both designed with a default “zero trust” approach. When both the organization and the specific agent are known, or when only the organization is known, the client can discover agents. After initial discovery, subsequent transactions can leverage cached connectivity information or skills learned to use the first scenario directly.

Discovery occurs either purely via DNS (default) or through an HTTP index. The DNS approach works when the target domain is known, operates on an in-memory list with Python predicates, and includes JWS and DNSSEC verifications. Steps: query the index of agents and protocols; for each agent, query the SVCB record; if a capabilities file URI exists, retrieve that JSON file; otherwise, retrieve capabilities from a TXT record. The alternative method uses a JSON index hosted under .well-known, with a backend directory acting as the source of truth. This suits unknown target domains or when cross-domain signals (security scores, trust, popularity) unavailable via DNS alone are needed.

The reference implementation works with Infoblox UDDI and NIOS, and also supports Cloudflare, AWS Route 53, Google Cloud DNS, IBM Cloud DNS, and any RFC 2136-compliant server. Integration with agentic frameworks is possible through a Python library or via the Model Context Protocol (MCP) for agent publication, search, and DNSSEC/DANE validation.

DNS-AID sets itself apart from similar initiatives. GoDaddy’s ANS is centralized; Google’s A2A + UDP approach relies on discovery only through Google; the ICANN-planned `.agent` gTLD incurs domain fees; and alternatives like `ai.txt` and `llm.txt` lack integrity verification.

The reference implementation has incrementally added several features: A2A card management, diagnostic MCP API and server, a capability verification chain (JSON document → A2A card → HTTP index → TXT record), compilation of JSON policy documents into RPZ, access control integration with Infoblox Threat Defense (mapping blocked domains to security policies), default Streamable HTTP on the MCP client SDK instead of JSON-RPC POST, and finalization of OpenTelemetry integration.

La Fondation Linux héberge désormais DNS-AID.

Ce projet vise à exploiter le DNS en tant qu’annuaire décentralisé pour les agents IA. L’entreprise américaine Infoblox en est à l’origine.

DNS-AID (DNS AI Discovery) fait l’objet d’un brouillon IETF. Dans la première version, publiée en octobre 2025, il s’appelait encore BANDAID (Brokered Agent Network for DNS AI Discovery). Les bases étaient toutefois posées : il s’agissait de définir un modèle d’utilisation des espaces de noms et des enregistrements DNS – SVCB, en premier lieu – pour l’échange de métadonnées et la déclaration de capacités.

Ce premier draft avait 4 signataires, d’Infoblox, de Deutsche Telekom et de l’IEEE. Dans la dernière version, datée du 27 mai 2026, s’en est ajouté un cinquième, d’Amazon.

Deux mécanismes de découverte, du « zero trust par défaut »

Quoique non officiellement membre du projet hébergé par la Fondation Linux, Amazon contribue au développement de l’implémentation de référence de DNS-AID. Son dépôt GitHub est ouvert depuis janvier. Les trois mainteneurs désignés travaillent chez Infoblox.

Cette implémentation suit deux scénarios de découverte : un où on connaît à la fois l’organisation et l’agent fournissant une capacité donnée ; l’autre où on ne connaît que l’organisation.

Dans l’un ou l’autre cas, une fois qu’un client a pris connaissance des agents, toutes les transactions peuvent exploiter le premier scénario, grâce à la mise en cache des informations de connectivité ou à leur apprentissage via une skill.

La découverte se fait soit purement par DNS (par défaut), soit par l’intermédiaire d’un index HTTP.

L’approche DNS fonctionne lorsqu’on connaît le domaine cible. Elle a l’avantage de fonctionner avec une liste en mémoire (à laquelle on applique des prédicats Python). Et de faire intervenir des vérifications JWS et DNSSEC. Ses grandes étapes :

Consultation de l’index des agents et des protocoles associés

Pour chaque agent, consultation de l’enregistrement SVCB

Si un URI de fichier de capacités est présent, récupérer ce fichier (JSON)

Sinon, récupérer les capacités dans un enregistrement texte

La deuxième option utilise un index en JSON localisé dans le répertoire .well-known. La source de vérité est alors un annuaire en back-end. Elle convient lorsqu’on ne connaît pas le domaine cible. Ou qu’on souhaite exploiter des signaux interdomaines (scores de sécurité, de confiance, de popularité…) que le DNS seul ne peut fournir.

Hormis Infoblox UDDI et NIOS, DNS-AID peut exploiter CloudFlare, AWS Route 53, Google Cloud DNS, IBM Cloud DNS… et tout serveur conforme RFC 2136.

L’intégration avec les frameworks agentiques peut se faire via la bibliothèque Python ou via MCP (publication et recherche d’agents, validation DNSSEC et DANE).

DNS-AID n’est pas seul sur le créneau

Décentralisé, DNS-AID se distingue ainsi d’initiatives comme ANS de GoDaddy. Par rapport au couple A2A + UDP de Google, il a l’avantage d’une découverte « universelle » (pas seulement via Google). Et il n’implique pas de frais de domaine, au contraire du gTLD .agent que prépare l’ICANN. Quant aux options ai.txt et llm.txt, elles n’offrent pas de vérification d’intégrité.

Quelques fonctionnalités intégrées sur l’implémentation de référence, dans l’ordre chronologique d’ajout :

Gestion des cartes A2A

API et serveur MCP de diagnostic

Mise en place de la chaîne de vérification des capacités (document JSON -> carte A2A -> index HTTP -> enregistrement TXT)

Compilation de documents de politiques JSON en RPZ

Intégration avec Infoblox Threat Defense pour le contrôle d’accès au niveau DNS (intégration de domaines bloqués dans des listes nommées et association de ces listes à des politiques de sécurité)

Streamable HTTP par défaut sur le client MCP du SDK (au lieu du POST JSON-RPC)

Finalisation de l’intégration OpenTelemetry

Illustration générée par IA

The post DNS-AID à la Fondation Linux : qu’est-ce que ce projet d’« annuaire agentique » ? appeared first on Silicon.fr.