DNS-PERSIST-01: un nuevo modelo para la validación de desafíos basada en DNS

• DNS-PERSIST-01 de Let's Encrypt es un nuevo modelo de desafío ACME que reemplaza la validación repetitiva del método DNS-01 existente usando registros de autorización persistentes
• Este método demuestra el control de un dominio a largo plazo mediante un registro TXT vinculado a una cuenta ACME específica y a una CA
• Reduce los cambios en DNS y la carga de distribuir credenciales de API, fortaleciendo al mismo tiempo la eficiencia operativa y la seguridad
• Admite funciones de control detalladas como opciones de política (policy=wildcard), momento de expiración (persistUntil) y permiso para múltiples CA
• Se espera su despliegue en staging a finales del primer trimestre de 2026 y su rollout completo en el segundo trimestre, con la expectativa de simplificar la gestión de certificados en entornos grandes y automatizados

---

Limitaciones del método DNS-01

• El desafío DNS-01 tradicional requiere generar un nuevo token y agregar un registro TXT en _acme-challenge. cada vez que se emite un certificado
  • Cada validación necesita una actualización de DNS, lo que provoca demoras de propagación y complejidad en la automatización
• En despliegues a gran escala, las credenciales de API de DNS quedan distribuidas entre varios sistemas, aumentando el riesgo de seguridad
• Algunos suscriptores quieren evitar estos cambios repetitivos en DNS

Estructura y funcionamiento de DNS-PERSIST-01

• El nuevo método introduce el concepto de autorización persistente
  • Solo se configura una vez un registro TXT en _validation-persist. que incluye la CA y el URI de la cuenta ACME
  • Después, el mismo registro puede reutilizarse para emisiones y renovaciones
• Ejemplo:

  _validation-persist.example.com. IN TXT (  
    "letsencrypt.org;"  
    " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
  )  
  

• Con esto, los cambios de DNS se eliminan de la ruta de emisión, mejorando la eficiencia operativa

Equilibrio entre seguridad y operación

• En DNS-01, el principal activo era el permiso de escritura en DNS, pero en DNS-PERSIST-01 la clave pasa a ser la protección de la clave de la cuenta ACME
• Después de la configuración inicial, se puede restringir el acceso de escritura al DNS, reduciendo la superficie de ataque
• Sin embargo, debido a la estructura de autorización persistente, el riesgo aumenta si se filtra la clave de la cuenta, por lo que es necesario reforzar la gestión de seguridad de la cuenta

Funciones de control de alcance y vigencia

• De forma predeterminada, la validación es válida indefinidamente solo para el FQDN verificado
• La opción policy=wildcard permite ampliarla a wildcards y subdominios

  "policy=wildcard"  
  

• El atributo persistUntil permite especificar el momento de expiración (segundos UTC)
  • Se requiere renovación antes del vencimiento y es indispensable contar con un sistema de monitoreo

  "persistUntil=1767225600"  
  

• Para permitir varias CA al mismo tiempo, se deben agregar registros TXT por cada CA en _validation-persist.

Calendario de adopción y estado de implementación

• La votación de CA/Browser Forum SC-088v3 fue aprobada por unanimidad en octubre de 2025, y el grupo de trabajo ACME de la IETF adoptó el borrador
• Ya cuenta con soporte en Pebble (una versión reducida de Boulder), y también está en curso la implementación del cliente lego-cli
• Se prevé staging a finales del primer trimestre de 2026 y despliegue completo en el segundo trimestre
• Este modelo es adecuado para áreas donde el método existente resulta ineficiente, como IoT, multitenancy y entornos de emisión masiva de certificados

Contexto de Let's Encrypt e ISRG

• Let's Encrypt es una autoridad certificadora (CA) gratuita, automatizada y abierta operada por la organización sin fines de lucro ISRG
• En su informe anual de 2025, ISRG dio a conocer sus actividades relacionadas con la seguridad de Internet

[GN⁺]

Comentarios de Hacker News

• Me da mucho gusto ver esta noticia
  Cuando uso bind como servidor de nombres autoritativo, lo configuro para poder restringir el hmac-secret de modo que cada servidor web solo pueda actualizar los registros TXT que le correspondan
  Así, aunque el servidor “bob” se vea comprometido, solo podría emitir certificados para el dominio “bob”
  Un ejemplo de configuración es usar update-policy para limitar cada clave a modificar solo el subdominio _acme-challenge

  • Si estás dispuesto a operar un servidor DNS aparte en lugar de bind, acmedns ofrece una función similar
    Al crear una cuenta nueva se te asigna un subdominio único, y si haces un CNAME del dominio del challenge a ese subdominio, solo esa cuenta podrá actualizar esa zona

• Creo que esta función resuelve una gran molestia operativa en la práctica
  Aun así, me preocupa la exposición de identificadores de cuentas administrativas
  Los nombres de usuario no se protegen igual que las credenciales, pero pueden darle a un atacante pistas sobre a quién apuntar
  Es muy probable que servicios como Shodan terminen indexando esos ID y ofreciendo búsquedas inversas

  • El accounturi de los registros CAA ya expone identificadores de cuenta, así que hasta cierto punto esto ya es público
    De hecho, creo que sería mejor que el formato de los registros CAA y persist coincidiera
  • Estaría bien darles a los usuarios un ID aleatorio tipo UUID en lugar de la cuenta real para usarlo en accounturi
  • Como es la misma cuenta que crea el cliente ACME, no creo que el riesgo de búsqueda inversa sea tan grande

• Me sorprende que no se exija DNSSEC
  Antes pensaba que DNSSEC era una molestia, pero ahora hay muchos registros que determinan la confianza raíz como CAA, CERT, SSHFP y TXT, así que quedan expuestos a ataques MITM
  Sobre todo porque incluso muchas grandes empresas no aplican DNSSEC correctamente, al menos debería indicarse como recomendación

  • El borrador del RFC también recomienda usar DNSSEC como “SHOULD” (enlace)
  • DNS siempre ha sido un punto único de falla para la emisión de certificados TLS
    Si un atacante controla el DNS, puede falsificar certificados usando HTTP-01, TLS-ALPN-01 o DNS-01
  • En lo personal, me parece que TLSA es un mejor enfoque que DNSSEC, pero es una lástima que casi no tenga soporte en navegadores

• Gracias a esto, parece que será mucho más fácil emitir certificados para servidores LAN que no están expuestos a internet
  De ahora en adelante, parece probable que la mayoría de las interfaces de administración generen automáticamente la cadena que hay que pegar en el registro DNS para obtener de inmediato un certificado de Let's Encrypt

  • Yo también lo intenté en un entorno parecido, pero la configuración de headscale magic DNS resultó más complicada de lo que esperaba, así que al final volví a renovaciones manuales

• Si usas certbot, puedes seguir el estado del soporte para esta función en este issue de GitHub

• Antes era escéptico con los certificados de corta duración, pero cambié de opinión al ver los certificados para direcciones IP y la validación HTTP-01
  Ahora ya no guardo los certificados en disco, y un hilo en segundo plano revisa cada 24 horas si hay uno nuevo
  Así se puede construir una solución self-hosted donde el usuario despliega software en una VM y queda operativa en 5 minutos
  Si lo combinas con un servicio como checkip.amazonaws.com, se puede automatizar por completo el despliegue

  • Eso sí, los límites de emisión de Let's Encrypt no son negociables, así que si pides demasiado seguido corres el riesgo de tener que esperar
  • Si no guardas nada del certificado, la disponibilidad pasa a depender del uptime de LE, así que hace falta guardar al menos lo mínimo

• Por fin parece que será más fácil automatizar certificados para servicios web solo internos
  Se siente como si por fin hubieran resuelto el mayor problema operativo que había hasta ahora, así que me da mucho gusto

• Lo que falta aquí es la verificación de propiedad de la cuenta ACME
  La mayoría de las herramientas de automatización crean la cuenta, así que normalmente el usuario no la maneja directamente, pero ahora habrá que entregar al proveedor ACME credenciales que prueben la propiedad de esa cuenta
  Si Let's Encrypt no puede crear tokens limitados por dominio, quizá haya que usar una cuenta separada para cada dominio

  • Pero las cuentas ACME ya tienen credenciales de autenticación y además verifican la propiedad del dominio mediante desafíos DNS o HTTP, así que
    si esas credenciales o ese endpoint fueran comprometidos, ya estaríamos ante un problema mucho más grave

• Esto sí es una gran noticia para quienes usan Dynamic DNS
  Por ejemplo, en casos como Namecheap, donde las solicitudes de cambio solo podían hacerse desde una IP fija, ahora bastará con dejarlo configurado una vez para que la renovación sea automática
  Definitivamente pienso probarlo mientras modernizo mi homelab

• Si no estoy entendiendo mal, me surge la duda de si alguien que controle el servidor DNS de mi dominio, o que intercepte el tráfico entre Let's Encrypt y el servidor DNS, podría emitir certificados TLS para mi dominio
  Con DNS-01 pasa lo mismo, pero aquí parece todavía más fácil porque el atacante solo tendría que meter su propia cuenta de LE en la respuesta DNS
  Hasta me pregunto si no sería mejor poner directamente mi certificado público en DNS

  • Si no puedes confiar en tu proveedor de DNS, entonces el problema es la relación misma
    Si alguien puede hacer MITM al tráfico entre LE y el servidor DNS, entonces ya estás en una situación mucho más grave
  • Quien controla el DNS puede emitir certificados con cualquier CA
    Si puedes cambiar el DNS, no hay forma de bloquear la emisión de certificados
  • Si controlas el DNS, también puedes completar desafíos HTTP, así que en la práctica ese dominio ya es tuyo
  • Las CA consultan el DNS desde varios puntos para mitigar este tipo de ataques de red
    Let's Encrypt ya opera así desde hace años, y desde 2024 es obligatorio para todas las CA
    Enlace a la norma del CAB Forum
  • En realidad, este enfoque es el que adopta DANE
    Material relacionado