DNS-AID: descubrimiento de agentes de IA a través de DNS

¿Qué es DNS-AID?

DNS-AID (DNS for AI Discovery) es una propuesta para que los agentes de IA se descubran entre sí consultando DNS, en lugar de pedir un archivo HTTP como llms.txt. La idea central: publicar dónde y cómo conectarse a un agente dentro de tu propio espacio de nombres DNS, usando registros SVCB (RFC 9460) bajo una etiqueta _agents, firmados con DNSSEC. No inventa nada nuevo a nivel de protocolo: reutiliza tipos de registro que ya existen.

Es la pieza que falta en la capa de red de un ecosistema que ya conoces si leíste mi artículo sobre content negotiation para agentes de IA: mientras llms.txt y la negociación de contenido operan a nivel HTTP, DNS-AID quiere resolver el descubrimiento antes de la primera petición HTTP, en la resolución de nombres.

Antes de seguir: esto es un borrador, no un estándar

Voy a ser directo porque importa: DNS-AID es un Internet-Draft individual (draft-mozleywilliams-dnsop-dnsaid), escrito por Jim Mozley, Nic Williams, Behcet Sarikaya, Roland Schott y Jeffrey Damick. A junio de 2026 va por la versión -02, expira el 28 de noviembre de 2026 y no está endosado por el IETF: no tiene grupo de trabajo asignado ni estatus formal en el proceso de estandarización. Reemplaza a un borrador anterior (draft-mozleywilliams-dnsop-bandaid).

Traducción: es una idea seria y bien escrita, pero todavía especulativa. Puede cambiar de forma radical o quedar en nada. Lo cuento porque entender la propuesta es valioso aunque no la implementes hoy, y porque cualquier blog que te la venda como "el nuevo estándar" no leyó la primera página del draft.

El problema que intenta resolver

Hoy un agente que quiere hablar con un servicio de otra organización tiene que adivinar el endpoint, o depender de un registro centralizado, o rascar HTML. DNS ya resuelve exactamente este tipo de problema para el correo (registros MX) y para servicios genéricos (DNS-SD). DNS-AID aplica el mismo patrón a los agentes:

• Es descentralizado: cada dominio publica sus propios agentes, sin un registro central que controle todo.
• Es cacheable y rápido: la respuesta viaja por la infraestructura DNS que ya existe en todo el planeta.
• Es verificable: con DNSSEC, el cliente sabe que los datos no fueron falsificados en el camino.

Un principio de diseño que el draft repite: no propone cambios a la estructura de los mensajes DNS, ni nuevos códigos de operación, ni nuevos tipos de registro. Solo define convenciones de nombres y perfiles de uso sobre registros que ya están estandarizados (SVCB, HTTPS, TXT, TLSA).

La estructura de nombres: el espacio _agents

DNS-AID usa etiquetas con guion bajo, igual que SPF, DKIM o DNS-SD. El patrón base es:

_<servicio>._agents.<dominio>

Algunos ejemplos del propio draft:

_agents.example.com              zona raíz de descubrimiento de agentes
_index._agents.example.com       punto de entrada conocido (índice de agentes)
_a2a._agents.example.com         descubrimiento de servicios agente-a-agente (A2A)
_mcp._agents.example.com         servicios Model Context Protocol (MCP)
billing._mcp._agents.example.org un agente concreto dentro de MCP
a4k2f9._mcp._agents.example.org  registro por-agente (hoja)

La etiqueta _index es la clave del descubrimiento: es el "punto de entrada conocido" que un agente consulta cuando sabe el dominio pero no qué tipos de agente ofrece.

Los registros SVCB (RFC 9460)

El mecanismo principal son los registros SVCB (Service Binding, tipo 64) y su variante HTTPS (tipo 65), definidos en la RFC 9460 (Proposed Standard desde 2023). Su gracia es entregarle al cliente todas las instrucciones de conexión en una sola consulta: qué protocolo habla el endpoint, en qué puerto, e incluso pistas de IP para ahorrar lookups posteriores.

Hay dos modos:

• AliasMode (prioridad 0): funciona como un CNAME, pero sirve incluso en el ápex de la zona, donde un CNAME no es legal.
• ServiceMode (prioridad 1 o mayor): asocia el endpoint con parámetros de conexión. Es el modo que DNS-AID usa para publicar agentes.

Ejemplo de registro tal cual aparece en el draft:

_a2a._agents.example.com. 3600 IN SVCB 1 ai-index-svc.example.com. (
    alpn="a2a"
    port=443
    ipv4hint=192.0.2.1
    ipv6hint=2001:db8::1
)

Lee así: el servicio A2A del dominio vive en ai-index-svc.example.com, habla el protocolo a2a, en el puerto 443, y aquí tienes sus IPs para que no tengas que hacer otra consulta.

Los SvcParams

Los parámetros (SvcParams) que DNS-AID reutiliza de la RFC 9460:

• alpn: qué protocolo de aplicación soporta el endpoint (a2a, h2, h3...).
• port: el puerto del servicio.
• ipv4hint / ipv6hint: pistas de IP que eliminan una consulta A/AAAA de seguimiento.
• mandatory: lista de parámetros que el cliente tiene que entender para usar el registro; si no los soporta, debe ignorarlo.

Parámetros experimentales para metadatos de IA

Acá está lo nuevo del draft. Propone claves provisionales para describir capacidades de agente:

• cap: identificador o locator de la capacidad del agente.
• cap-sha256: digest SHA-256 (base64url) para validar la integridad de esa capacidad.
• policy: URI a un bundle de políticas (jurisdicción, manejo de datos).
• realm: token opaco para scoping multi-tenant.

Como todavía no están registradas ante la IANA, las despliegas con el formato numérico keyNNNNN. Un ejemplo completo del draft:

a4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-a4k2f9.example.org.
alpn="h2" port=443 ipv4hint=192.0.2.5
mandatory=alpn,port,key65001,key65002,key65010
key65001="cap=urn:cap:example:mcp:invoice.v1"
key65002="cap-sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0"
key65010="bap=a2a/1,mcp/1"

Ese registro anuncia un agente MCP concreto, con la capacidad invoice.v1, su hash de integridad y los protocolos que arranca.

Los cuatro flujos de descubrimiento

El draft define cuatro situaciones según cuánto sabe el agente de antemano:

1. Servicio y dominio conocidos: consulta SVCB directa. Un solo lookup devuelve todos los parámetros de conexión y los metadatos de capacidad.
2. Dominio conocido, servicio desconocido: el agente consulta _index._agents.example.com para enumerar qué tipos de agente existen, y luego pide el servicio específico.
3. Consulta multi-dominio: el agente pregunta el mismo servicio conocido en varios dominios de confianza en paralelo (por ejemplo img2txt._a2a._agents.org1.com y ...org2.com) y compara para elegir.
4. Registro consolidado: cuando no conoce ni el dominio ni el servicio, consulta un registro de terceros (fuera de DNS) que devuelve una lista curada de agentes con ratings y capacidades agregadas.

Los tres primeros son DNS puro; el cuarto reconoce que a veces hace falta un directorio externo.

Seguridad: DNSSEC es obligatorio

Esta parte el draft no la deja como opcional. Cito la exigencia: una zona autoritativa pública usada para descubrimiento de agentes DEBE usar DNSSEC, y los agentes DEBEN usar resolvers validadores. Es más: un resolver DEBE tratar las respuestas DNSSEC-bogus como fallos y NO DEBE actuar sobre datos de descubrimiento sin firmar o mal firmados.

El motivo es obvio: si un atacante puede falsificar tu registro _a2a._agents, redirige a los agentes hacia un endpoint malicioso. Sin DNSSEC, todo el modelo de confianza se cae.

El draft suma dos registros complementarios:

DANE/TLSA para atar el certificado del endpoint a la cadena DNSSEC:

_443._tcp.svc-a4k2f9.example.net. 1800 IN TLSA 3 1 1 (
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB )

Domain Control Validation (DCV) vía TXT para autorizar enlaces entre servicios:

_agents-challenge 300 IN TXT "bnd-req=svc:crm-sync@vendor.example;
nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z"

Un par de notas de rendimiento del draft: usa las pistas de IP para evitar consultas extra, y mantén las respuestas por debajo de ~1232 bytes para esquivar la fragmentación en IPv6.

¿Vale la pena implementarlo hoy?

Mi opinión honesta, y la razón por la que escribí esto como explicación y no como tutorial de "hazlo ya":

Sáltalo si tienes un sitio de contenido. Si publicas un blog estático o un sitio corporativo, no tienes ningún servicio A2A ni MCP que descubrir. Publicar _a2a._agents sería anunciar una puerta que no existe. Además exige que tu proveedor de DNS soporte registros SVCB y DNSSEC, y un DNSSEC mal configurado puede tumbarte la resolución del dominio entero. Riesgo real, beneficio cero hoy.

Considéralo si expones un agente real. Si tu producto es un servicio de agente (una API A2A, un servidor MCP de cara al público) y quieres que sea descubrible de forma descentralizada y verificable, DNS-AID es la dirección hacia la que apunta esta línea de trabajo. Aun así, trátalo como experimental: implementa, mide, pero no apuestes infraestructura crítica a un borrador que expira en noviembre.

Y si te interesa el estándar, la mejor inversión ahora mismo no es publicar registros, sino entender SVCB/HTTPS de la RFC 9460, que sí es un estándar consolidado y útil por sí solo (HTTP/3, CNAME en el ápex, menos round-trips).

Cómo se verifica

El escáner de isitagentready.com que probablemente te trajo hasta acá comprueba DNS-AID por DNS-over-HTTPS (usa el resolver de Cloudflare por defecto, con fallback al de Google) y marca checks.discoverability.dnsAid.status como pass si encuentra los registros bajo _agents. Es decir: el check falla simplemente porque no publicaste esos registros, no porque algo esté roto.

Conclusión

DNS-AID es una idea elegante: llevar el descubrimiento de agentes a la capa donde DNS ya resuelve este problema desde hace décadas, sin inventar tipos de registro nuevos y exigiendo DNSSEC desde el día uno. Pero es un borrador individual, joven y sin respaldo formal del IETF. Vale la pena entenderlo, vale la pena vigilarlo, y vale la pena implementarlo solo si tienes un servicio de agente de verdad y aceptas el carácter experimental.

Para un blog, el check de "DNS-AID no encontrado" es ruido: no hay nada que descubrir todavía.

Referencias

1. draft-mozleywilliams-dnsop-dnsaid — DNS for AI Discovery — el Internet-Draft original (IETF Datatracker).
2. RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) — el estándar de los registros SVCB/HTTPS.
3. SKILL.md de DNS-AID en isitagentready.com — la guía del escáner que origina la recomendación.