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) con un punto de entrada fijo en _index._agents y, como recomendación, firmados con DNSSEC. No inventa nada nuevo a nivel de protocolo: reutiliza tipos de registro que ya existen.

Si leíste mi artículo sobre content negotiation para agentes de IA, esto lo complementa en la capa de red: 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

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).

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 introduce nuevos tipos de registro, ni nuevos códigos de operación, ni nuevos códigos de respuesta. Solo define convenciones de nombres y perfiles de uso sobre registros que ya están estandarizados (SVCB, TLSA y, como alternativa, TXT).

La estructura de nombres: _index._agents

DNS-AID usa etiquetas con guion bajo, igual que SPF, DKIM o DNS-SD. En la versión -02 del draft hay un solo nombre fijo, el índice de la organización, y cada agente vive en el nombre que tú elijas:

_index._agents.example.com    punto de entrada conocido (índice de agentes)
agent-name.example.com        registro principal de un agente concreto

El draft llama primary owner al nombre donde está el registro principal del agente. Si además quieres agruparlos bajo _agents.example.com o publicarlos con una etiqueta DNS-SD como _a2a, esas entradas tienen que ser registros SVCB en AliasMode que apunten al principal.

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é agente le sirve. Devuelve un puntero al índice de agentes de la organización; el formato de ese índice queda fuera del draft.

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:

agent-name.example.com. 3600 IN SVCB 1 . (
    alpn="a2a"
    port=443
    ipv4hint=192.0.2.1
    ipv6hint=2001:db8::1
    well-known=agent-card.json
    cap=<capability descriptor locator>
    ...
)

Lee así: el agente agent-name vive en ese mismo nombre (el . como destino significa eso), habla el protocolo a2a, en el puerto 443, aquí tienes sus IPs para que no hagas otra consulta, su agent card está en /.well-known/agent-card.json y cap apunta a su descriptor de capacidades.

Los SvcParams

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

• alpn: el conjunto de protocolos del endpoint, transporte y protocolo de agente juntos (alpn=mcp,h2,h3). El draft exige un registro por protocolo de agente: mcp y a2a no pueden ir en el mismo alpn.
• 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 para describir capacidades de agente y pide a la IANA que las registre:

• cap: locator del descriptor de capacidades del agente o un identificador inline (por ejemplo, una URN).
• cap-sha256: digest SHA-256 (base64url) del descriptor; si no coincide, el cliente tiene que rechazarlo.
• policy: URI a un bundle de políticas (jurisdicción, cumplimiento). Su sintaxis queda para una revisión futura.
• realm: token opaco para scoping multi-tenant, también con la sintaxis pendiente.

Mientras la IANA no les asigne número, el draft anima a experimentar en el rango de uso privado de la RFC 9460, que en el archivo de zona se escribe con el formato numérico keyNNNNN (de key65280 a key65534).

Los tres casos de descubrimiento

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

1. Agente conocido: el agente sabe el nombre y el dominio. Una sola consulta SVCB devuelve IPs, transporte, protocolo de agente y metadatos de capacidad. Es la forma que los clientes tienen que probar primero.
2. Organización conocida: sabe el dominio pero no qué agente le sirve. Consulta _index._agents.example.com, lee el índice, elige un agente y guarda la elección para usar el caso 1 en las siguientes peticiones.
3. Capacidad conocida: no sabe ni la organización ni el agente. Eso ya es una búsqueda y queda fuera de DNS-AID; un directorio externo podría armarse leyendo los _index._agents de muchos dominios.

Seguridad: DNSSEC recomendado, no obligatorio

En la versión -02 el draft dice que DNS-AID se puede desplegar sin DNSSEC, pero que sus garantías de autenticidad dependen de una cadena validada desde la raíz. Los registros DEBERÍAN ir firmados (si usas TLSA, DEBEN), los clientes DEBERÍAN validar DNSSEC y negarse a actuar sobre registros bogus o no verificables, y NO DEBEN relajar la validación porque un registro no traiga claves en mandatory=.

Si un atacante puede falsificar el registro de tu agente, redirige a los agentes hacia un endpoint malicioso. Sin DNSSEC, el modelo de confianza se cae. Y aun con DNSSEC, el draft aclara que un registro auténtico solo prueba quién lo publicó, no que el agente al otro lado sea de fiar.

El draft suma dos registros complementarios:

DANE/TLSA para atar el certificado del endpoint a la cadena DNSSEC, en el nombre _443._tcp.<owner>:

_443._tcp.agent-name.example.com. 1800 IN TLSA 3 1 1 (
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB )

No impone una postura: la que propone por defecto para internet es la permisiva, que fija el certificado si hay TLSA y, si no hay, vuelve a la validación WebPKI de siempre.

Domain Control Validation (DCV) vía TXT para probar que controlas la zona, todavía como mecanismo experimental. El ejemplo del draft:

_agents-challenge.acme.example. 60 IN TXT (
    "token=gjdqocfk4vhiq2bn" "domain=acme.example"
    "bnd-req=svc:api@acme.example" "expiry=2026-05-13T23:00:00Z" )

¿Vale la pena implementarlo hoy?

Mi opinión, 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 _index._agents sería anunciar una puerta que no existe. Además exige que tu proveedor de DNS soporte registros SVCB, y DNSSEC si quieres las garantías de autenticidad; un DNSSEC mal configurado puede tumbarte la resolución del dominio entero.

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 individual que cambia bastante de una versión a la siguiente.

Y si te interesa el estándar, antes que publicar registros conviene 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 aquí 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. Su guía todavía pone como ejemplo _a2a._agents.example.com, el esquema de nombres de la versión -01 del draft. 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 apoyándose en DNSSEC para la autenticidad. Pero es un borrador individual, joven y sin respaldo formal del IETF. Vale la pena entenderlo y seguirle la pista, pero 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.

DNS-AID es una de las piezas de la web que se está construyendo para agentes. Las otras, con lo que ya funciona y lo que sigue en borrador, en la guía de agentes de IA.

DNS-AID resuelve cómo te encuentran. Lo que pasa después, cuando el agente ya llegó a una URL tuya, lo tengo documentado en superficies para agentes.

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.