--- title: "DNS-AID: descubrimiento de agentes de IA a través de DNS" excerpt: "DNS-AID es un borrador del IETF para que los agentes de IA se descubran vía DNS, reutilizando registros SVCB (RFC 9460) y DNSSEC. Te explico qué es, cómo funciona y si conviene hoy, leído del draft original." date: "2026-06-14T13:00:00.000Z" category: "Inteligencia Artificial" author: name: "angel cruz" picture: "https://angelcruzdevcdn.nyc3.cdn.digitaloceanspaces.com/images/me/angel-cruz.png" seo_title: "DNS-AID: descubrir agentes de IA por DNS (SVCB + DNSSEC)" seo_description: "Qué es DNS-AID, el borrador del IETF para descubrir agentes de IA vía DNS con registros SVCB (RFC 9460) y DNSSEC. Estructura _agents, flujos de descubrimiento y si conviene hoy." tech_article: article_section: "AI Agents" keywords: "dns-aid, descubrimiento de agentes, svcb, rfc 9460, dnssec, dns for ai discovery" --- ## ¿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](https://www.rfc-editor.org/rfc/rfc9460)) 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](/post/content-negotiation-agentes-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: ```txt _._agents. ``` Algunos ejemplos del propio draft: ```txt _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: ```txt _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: ```txt 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: ```txt _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: ```txt _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](https://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](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/) — el Internet-Draft original (IETF Datatracker). 2. [RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://www.rfc-editor.org/rfc/rfc9460) — el estándar de los registros SVCB/HTTPS. 3. [SKILL.md de DNS-AID en isitagentready.com](https://isitagentready.com/.well-known/agent-skills/dns-aid/SKILL.md) — la guía del escáner que origina la recomendación. --- ## Sitemap Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md) Canónico HTML: [https://www.angelcruz.dev/post/dns-aid-descubrimiento-agentes-ia-dns](https://www.angelcruz.dev/post/dns-aid-descubrimiento-agentes-ia-dns)