El discovery de x402 llega al DNS: auditoria del draft _x402

Hoy, la unica forma universal de que un agente sepa que un endpoint acepta pagos x402 es llamarlo y pagar un round trip por la leccion. Un draft IETF de agosto quiere mover ese discovery al DNS — un registro TXT, una well-known URI, y un algoritmo de resolucion acotado a dos lookups.

El documento es draft-hawkins-x402-dns-discovery-03, "Discovering x402 Payment Capability via DNS and a Well-Known URI", escrito por Walter D. Hawkins y fechado 2026-08-23. Es una individual submission — activa, pero no respaldada por ningun working group del IETF. Y no viaja solo. IANA asigno el underscored node name _x402 el 2026-08-11, la well-known URI x402 esta registrada con estatus provisional, y una spec de extension companion esta en review en el repositorio de la x402 Foundation desde el 2026-07-29, apuntando a specs/extensions/discovery.md.

Leimos el draft, el pull request de la extension, y el censo de deployment publicado en su hilo de review. Esto es una auditoria de que especifica realmente el mecanismo, donde estan sus filos, y que dicen los numeros sobre si alguien ya publica los registros.

El discovery hoy es un directorio o un 402

x402 siempre tuvo un hueco de discovery. El protocolo es reactivo por diseno: un cliente pide un recurso, el servidor responde 402 Payment Required con los payment requirements, el cliente paga y reintenta. Eso funciona una vez que sabes que el recurso existe. No dice nada sobre como un agente encuentra recursos pagables en primer lugar.

La primera respuesta del ecosistema fue el x402 Bazaar — un indice curado servido por un facilitator, consultable por agentes. La segunda fue crawlear: golpear endpoints, coleccionar challenges 402, indexar los requirements. Ambas funcionan, y ambas tienen la misma debilidad estructural. Un directorio es tan completo como sus submissions, y aprender por 402 cuesta un request completo por endpoint, no te dice nada hasta que preguntas, y no te da forma de filtrar por network o scheme antes de gastar el round trip.

La propuesta del draft es la misma en la que convergio la infraestructura de email hace decadas: poner un aviso de capacidad legible por maquinas donde los clientes ya saben mirar. Para el email fueron MX, SPF y DMARC. Para x402 se convierte en un registro TXT _x402 y un manifest /.well-known/x402.

El manifest: /.well-known/x402

El artefacto central es un manifest JSON servido sobre HTTPS en https://<host>/.well-known/x402, siguiendo la convencion de well-known URIs de RFC 8615. Dos campos son requeridos: x402Version, un entero que declara la version mas alta del protocolo que el host soporta, y kind, uno de facilitator, resource-server, o both.

El contenido interesante es condicional. Un host que se declara facilitator debe incluir un objeto facilitator con baseUrl, un objeto endpoints con los paths de supported, verify y settle, un array kinds que refleja lo que reporta el supported endpoint en vivo, y un mapa assets de activos liquidables por network. Esos tres endpoints son toda la superficie operativa de un facilitator — la misma triada que recorrimos en la auditoria del facilitator — asi que un manifest bien formado alcanza para que un buyer stack pase de un nombre de dominio pelado a una configuracion capaz de liquidar, sin relacion previa.

Un resource server publica en cambio un array resources con sus URLs gated por x402. El draft restringe cada URL del manifest — baseUrl y cada entrada de resources — al dominio del propio manifest o sus subdominios. Esa sola regla hace mucho trabajo de seguridad; volveremos a ella.

Dos campos menores merecen nota. updated es un timestamp RFC 3339 recomendado, que da a los indexers una senal barata de frescura. Y attestation carga claims de integridad de ejecucion, con {"type":"none"} como default honesto. Ese campo hoy es un placeholder, pero es el punto de montaje natural para el trabajo de ejecucion verificable que avanza en otras partes del stack de agentes.

El registro TXT es un puntero, no un payload

La mitad DNS es deliberadamente delgada. Un dominio publica un registro TXT en _x402.example.com con pares key=value separados por punto y coma:

; registro TXT en _x402.example.com
"v=x402-1; wk=https://example.com/.well-known/x402; k=facilitator; net=eip155:8453,solana; scheme=exact,upto"

v=x402-1 es requerido y versiona el formato del registro. wk= es requerido y carga la URL HTTPS absoluta del manifest — que debe, de nuevo, vivir en el dominio que publica o un subdominio suyo. Las claves opcionales son pre-filtros gruesos: k= repite el kind, net= lista identificadores de network, scheme= lista nombres de schemes. Un agente que solo liquida en una network puede descartar un host candidato en la capa DNS, antes de hacer un solo request HTTPS.

La gramatica hereda dos lecciones duras de SPF y DMARC. Primero, los registros TXT se transportan como character-strings de 255 octetos; cuando un registro abarca varias, los consumidores deben concatenarlas sin separador y sin insertar whitespace — el clasico bug del registro SPF largo, prevenido en el texto de la spec. Segundo, un dominio debe publicar como maximo un registro con v=x402-1 por owner name, con lo que el comportamiento ante registros en conflicto queda definido por la spec y no librado a heuristicas del cliente.

Mantener el registro como puntero y no como payload es la decision correcta. El TXT de DNS es un lugar hostil para datos estructurados — limites de tamano, caching, tooling de operadores que rompe comillas — y todo protocolo que intento meter policy en TXT termino lamentandolo. Aca el DNS responde exactamente una pregunta, "donde esta tu manifest, y vale la pena siquiera bajarlo", y HTTPS responde todo lo demas.

Dos lookups, acotados

El algoritmo de resolucion es tan corto que se puede enunciar completo. Consultar TXT en _x402.D; si existe un registro con v=x402-1, bajar el manifest desde su URL wk, rechazando cualquier cosa no-HTTPS o fuera de dominio. Los registros no parseables se tratan como ausentes, no como errores. Si no hay registro usable, caer a un GET directo sobre https://D/.well-known/x402. Validar la forma del manifest, ignorar campos desconocidos. Costo total: maximo una consulta DNS y un GET HTTPS.

La parte sutil es elegir D. Para una URL de recurso, el consumidor consulta primero el host exacto, y despues sube por los nombres ancestros, del mas cercano al mas lejano, deteniendose en el primer registro usable. La caminata esta acotada a dos ancestros y nunca debe consultar nombres con menos de dos labels — asi, un lookup por api.data.example.com puede llegar a _x402.example.com pero el algoritmo nunca degenera en consultar TLDs.

La regla de ancestros tiene una segunda mitad facil de pasar por alto e importante de implementar: un manifest obtenido de un nombre ancestro A solo aplica al host H si el manifest referencia explicitamente a H — en facilitator.baseUrl o en una entrada de resources — y las URLs referenciadas solo cuentan cuando su host es A o un subdominio de A. Un manifest bajado de H mismo siempre aplica a H. Sin esa regla, un manifest del dominio padre reclamaria en silencio autoridad de pago sobre cada subdominio, incluidos los delegados a otros operadores. Con ella, la autoridad tiene que reclamarse explicitamente, y el reclamo es verificable por comparacion de strings.

Una regla de precedencia mas importa para quien construye un cliente: el array kinds del manifest es un cache, no un contrato. Antes de usar un facilitator, el consumidor debe consultar el endpoint supported en vivo y tratarlo como autoritativo. Los manifests envejecen; el supported endpoint es la verdad contra la que corre el settlement.

La seccion de seguridad es la spec de verdad

Para un mecanismo tan chico, las security considerations son inusualmente concretas, y se leen como escritas despues de una review adversarial y no antes. El historial del pull request lo confirma: varios commits entraron especificamente para atender hallazgos de validacion de redirects y destinos.

El riesgo principal es server-side request forgery. Un cliente de discovery es, por construccion, un servicio que baja URLs influenciadas por atacantes — el valor wk se lee del DNS, y el DNS es exactamente tan confiable como la zona que lo sirve. El draft exige a los consumidores rechazar, antes de cada fetch, cualquier URL que resuelva a direcciones loopback, link-local o de rangos privados, y re-aplicar ese chequeo en cada salto de redirect. Igualmente exige re-validar la restriccion de dominio en cada salto — un wk dentro de dominio que redirige fuera convertiria el fetch del manifest en un open redirect — y la URL final, no la primera, debe reportarse como fuente del manifest.

Los fetches deben acotarse en tiempo y tamano. El draft cita los numeros de un deployment en produccion como referencia: tope de respuesta de 256 KiB, deadline de 10 segundos, y maximo de 3 saltos de redirect. La comparacion de host names debe ser case-insensitive sobre A-labels e ignorar puntos finales, porque la normalizacion asimetrica entre el camino DNS y el camino HTTPS falla en silencio de la peor manera — registros que existen pero nunca matchean.

Lo que el draft no puede hacer es volver honesto al manifest. Un dominio puede anunciar networks en las que no liquida o recursos que no gatea. La mitigacion es la regla de precedencia de arriba — los datos del supported en vivo ganan — mas un deber que el draft asigna a los indexers: marcar hosts cuyos manifests divergen de sus endpoints en vivo. El tracking de divergencia es el gancho de reputacion aca, y queda librado al ecosistema.

El censo: el discovery va adelante de la calidad de datos

El hilo de review del PR de la extension contiene los numeros mas utiles publicados hasta ahora sobre discovery en x402: un censo de 1,521 hosts. De esos, 982 ya sirven algo en alguno de los paths del manifest — pero solo 81, el 8.2%, cargan datos de pago suficientes para configurar de verdad un cliente. La brecha entre "responde JSON" y "manifest usable" es toda la historia de adopcion hoy. Un punto brillante consistente: los 139 challenges 402 legibles del censo usaban x402Version como entero tipado, lo que sugiere que el campo de version — la parte que V2 estandarizo mas fuerte — tiene consenso real de deployment.

El feedback de operadores en el mismo hilo reporto un lag de visibilidad de 6.9 a 8.8 minutos entre publicar un registro y que resuelva de forma confiable — propagacion DNS mas caching, ordinario pero necesario de saber antes de cablear discovery en un camino sensible a disponibilidad. El autor tambien reconocio cuatro propuestas independientes anteriores de discovery para x402, incluido un draft comunitario previo de _x402 que expiro sin revision en mayo de 2026. Este es el primer intento con registraciones IANA presentadas y una extension de la Foundation en review; la idea circulaba hace rato, pero el papeleo es nuevo.

El estatus, dicho con precision: el documento IETF es un draft individual, la registracion well-known es provisional con el autor como change controller, y el PR #2979 esta abierto, no mergeado. Nada de esto es un estandar ratificado todavia. Vive en la capa de extensiones, que es exactamente donde x402 viene incubando todo lo que no es settlement core — y las extensiones que consiguieron implementaciones antes de la ratificacion son las que quedaron.

Que significa para LLM4Agents

LLM4Agents es un resource server en el vocabulario de este draft — un gateway OpenAI-compatible gated por x402 — y el discovery nos favorece de forma asimetrica. Hoy un agente nuevo encuentra el gateway porque su operador lo configuro. Con _x402.llm4agents.com y un manifest well-known, un agente con USDC buscando capacidad de inferencia puede encontrar, filtrar y configurar el gateway programaticamente: kind, networks, schemes y los endpoints gated, en una consulta DNS y un GET. Cada indice y crawler que implemente el draft se vuelve un canal de distribucion que no tenemos que negociar, que es el complemento descentralizado de estar listados en el Bazaar.

El lado comprador importa igual. Nuestros agentes compran tools y datos de endpoints x402 de terceros, y los pre-filtros net= y scheme= mapean directo al routing: descartar hosts que no pueden liquidar en las networks donde operamos antes de gastarles un request. El censo es una etiqueta de advertencia, eso si — con 8.2% de manifests con datos de pago usables, un resolver que confie en manifests sin confirmar contra endpoints supported en vivo va a autoconfigurarse mal seguido. La regla de precedencia no es higiene opcional; con la calidad de datos actual, es el mecanismo.

El lado de amenaza es la superficie SSRF. Un resolver de discovery dentro de nuestra infraestructura baja URLs originadas en registros DNS que cualquiera puede publicar. Las reglas de rechazo del draft — rangos privados, revalidacion por salto, fetches acotados — describen precisamente el resolver que tendriamos que construir, y construirlo con limites mas laxos que los del deployment citado por la spec (256 KiB, 10 s, 3 saltos) seria negligente.

Como mantenerse en la frontera

Primero, publicar el manifest ya. Un archivo /.well-known/x402 para el gateway es JSON estatico: x402Version, kind: "resource-server", las URLs de recursos gated, un attestation: {"type":"none"} honesto, y un timestamp updated mantenido. Cuesta una tarde y hace visible el gateway para cada indexer temprano, un conjunto hoy tan chico que estar en el 8.2% usable es una ventaja de distribucion.

Segundo, publicar el registro TXT y firmar la zona. v=x402-1; wk=... mas filtros net= y scheme=, un registro por owner name, DNSSEC activo, expiracion de RRSIG monitoreada. Presupuestar el lag de visibilidad de 7–9 minutos en cualquier runbook de rollout.

Tercero, construir el resolver en el buyer stack detras de un flag. Implementar el algoritmo completo — TXT, GET de fallback, caminata de ancestros con la regla de referencia explicita, chequeos SSRF y de dominio por salto, limites de fetch al nivel de la spec — y tratar la configuracion descubierta como datos candidatos que el endpoint supported en vivo debe confirmar antes de que fluya un solo pago.

Cuarto, indexar y puntuar divergencia. El draft pide a los indexers marcar la divergencia manifest-versus-vivo y deja la capa de reputacion sin especificar. Un gateway que crawlea continuamente a sus contrapartes pagables esta posicionado para mantener ese score, y el historial de divergencia es mejor senal de confianza que cualquier listado estatico de directorio.

Quinto, seguir el PR #2979 hasta el merge, no hasta el hype. La extension esta abierta, el draft IETF es individual, la entrada IANA es provisional. La postura correcta es implementado-pero-flageado: publicar los registros, correr el resolver, y tratar la spec como cambiable hasta que la Foundation la mergee. Publicar registros es barato de actualizar; hardcodear la gramatica de hoy en los agentes no.

El patron mayor es familiar en cada capa de este stack: el protocolo de pago se estandarizo primero, y el problema de encontrarse se esta resolviendo despues, en drafts, con calidad de datos de un digito porcentual. No es una critica. Asi se ve una frontera desde adentro, y los operadores que publican registros temprano y construyen resolvers cuidadosos son los que la primera generacion de compradores autonomos va a encontrar de verdad.