DNS-AID: los agentes de IA se buscan y verifican entre sí via DNS

Uno de los problemas que más fricción genera al desplegar arquitecturas multi-agente con MCP no es la integración de herramientas, sino algo más básico: ¿cómo sabe un agente que el otro agente con el que va a comunicarse es quien dice ser? DNS-AID, documentado esta semana por Help Net Security, propone resolver ese problema reutilizando infraestructura que ya existe: el sistema de nombres de dominio.

La idea es elegante en su sencillez. En lugar de construir un registro centralizado nuevo o depender de mecanismos propietarios de cada plataforma, DNS-AID publica metadatos de los agentes —capacidades, endpoints, claves públicas— como registros DNS especiales. Cualquier agente que quiera localizar o verificar a otro simplemente hace una consulta DNS estándar. La autenticación se apoya en DNSSEC, que ya tiene décadas de rodaje en entornos de producción.

Por qué esto importa en el contexto MCP

Con MCP consolidado como estándar de Anthropic para que los LLMs llamen herramientas externas, la proliferación de MCP servers ha sido notable. Hoy es habitual configurar varios servidores en `claude_desktop_config.json` o dentro de Claude Code para cubrir distintas necesidades: bases de datos, APIs internas, servicios de terceros. Pero cuando esos servidores necesitan coordinarse entre sí —o cuando un subagente tiene que localizar dinámicamente otro subagente especializado— no existe un mecanismo estándar de descubrimiento.

DNS-AID apunta exactamente ahí. Sus tres funciones principales son:

• Descubrimiento: un agente puede consultar qué otros agentes están disponibles en un dominio determinado y qué capacidades ofrecen.
• Verificación de identidad: mediante registros firmados con DNSSEC, el agente que recibe una petición puede confirmar que el emisor es legítimo antes de ejecutar nada.
• Revocación: si un agente queda comprometido, basta con eliminar o modificar su registro DNS para que deje de ser descubierto o verificado por el resto.

Este último punto no es menor. Uno de los vectores de ataque más documentados en arquitecturas multi-agente es la suplantación: un agente malicioso que se hace pasar por un servicio legítimo para inyectar instrucciones o exfiltrar datos. Tener un mecanismo de revocación que no requiere coordinación centralizada en tiempo real reduce significativamente esa superficie.

Para quién es útil ahora mismo

En su estado actual, DNS-AID es más relevante para equipos que ya operan arquitecturas multi-agente en entornos corporativos propios, donde controlan el DNS interno. Si tu organización usa Claude Code con subagentes personalizados para delegar tareas —análisis de datos, generación de código, consultas a sistemas legacy— y esos subagentes necesitan descubrirse entre sí de forma dinámica, esta propuesta ofrece una base técnica sólida sin introducir dependencias nuevas.

Para entornos más pequeños o configuraciones personales con Claude Desktop, el beneficio inmediato es menor: la configuración manual de `claude_desktop_config.json` sigue siendo suficiente cuando el número de servidores es manejable. Pero a medida que los catálogos de MCP servers crecen —y el marketplace de plugins de Claude Code suma entradas cada semana— la pregunta de cómo gestionar ese inventario de forma segura y escalable va a ser cada vez más urgente.

Reutilizar lo que funciona, en lugar de reinventarlo

Lo que hace interesante a DNS-AID desde un punto de vista de arquitectura no es que sea novedoso, sino precisamente lo contrario: se apoya en protocolos con décadas de prueba en producción, auditados, con implementaciones maduras en prácticamente cualquier stack tecnológico. DNSSEC no es perfecto —su adopción ha sido históricamente desigual— pero es un estándar abierto con herramientas conocidas y comportamiento predecible.

El riesgo principal que vemos es el de siempre con propuestas de este tipo: que cada plataforma termine adoptando su propio esquema de metadatos DNS, fragmentando el estándar antes de que llegue a consolidarse. Para que DNS-AID funcione como infraestructura común del ecosistema de agentes, necesitaría respaldo explícito de Anthropic u otros actores con capacidad de establecer convenciones. Sin eso, es una propuesta técnicamente solvente que puede quedarse en nicho.

Dicho esto, que alguien esté pensando en descubrimiento y verificación de agentes usando infraestructura probada en lugar de servicios nuevos y opacos es, al menos, la dirección correcta.