¡Nuevo método de Let's Encrypt! DNS-PERSIST-01 explicado

En febrero de 2026, Let’s Encrypt anunció el método DNS-PERSIST-01, un nuevo desafío ACME que permite validar dominios mediante un registro TXT fijo en el DNS, eliminando la necesidad de actualizar ese registro en cada renovación de certificado.

En 30 segundos

Let’s Encrypt presentó DNS-PERSIST-01 en febrero de 2026 como alternativa al clásico DNS-01.
El método usa un registro TXT persistente en _validation-persist.tudominio.com vinculado a una cuenta ACME específica.
Una vez creado ese registro, la CA puede emitir y renovar certificados (incluso wildcards) sin que vos toqués el DNS de nuevo.
Está pensado para despliegues grandes: multi-tenant, IoT, operaciones por lote donde mover credenciales de DNS es un problema real.
Todavía es un borrador IETF, aunque Let’s Encrypt ya lo tiene en implementación activa.

Let’s Encrypt es una autoridad de certificación gratuita y automatizada operada por el Internet Security Research Group (ISRG), creada con el respaldo de organizaciones como Mozilla y la EFF. Permite a los propietarios de sitios web obtener certificados TLS/SSL sin costo para habilitar conexiones HTTPS.

¿Qué es DNS-PERSIST-01 y por qué Let’s Encrypt lo necesitaba?

DNS-PERSIST-01 es un nuevo tipo de desafío del protocolo ACME que le permite a una autoridad certificadora verificar el control sobre un dominio a través de un registro TXT permanente, en lugar del registro efímero que usa DNS-01. La diferencia conceptual parece pequeña, pero en producción cambia bastante las cosas.

El registro se coloca bajo _validation-persist.tudominio.com y contiene la identificación de la CA junto con el URI de tu cuenta ACME. Una vez configurado, eso queda ahí. La CA consulta ese registro cada vez que necesita validar, sin pedirte que lo cambies.

Problemas del método DNS-01 tradicional

Si alguna vez automatizaste la renovación de un certificado wildcard, sabés exactamente de qué hablo. Con DNS-01, cada vez que se renueva el certificado, el cliente ACME tiene que generar un token nuevo, meterlo como registro TXT en tu DNS, esperar a que propague, y recién entonces la CA valida. Todo ese ciclo, cada vez, para cada dominio.

Los problemas concretos que esto genera en entornos reales:

Propagación DNS: dependés de los TTL y de que los servidores autoritativos actualicen a tiempo. En algunos proveedores, eso puede tardar minutos o directamente fallar de forma intermitente.
Credenciales de API distribuidas: para que el cliente ACME pueda crear y borrar registros TXT, necesita acceso a la API de tu proveedor DNS. Eso implica gestionar y distribuir esas credenciales, con todo el riesgo que trae.
Operaciones por lote: si tenés 500 dominios y los certificados vencen en distintas fechas (y más con el movimiento hacia certificados de 45 días), estás haciendo cambios de DNS continuamente.
Entornos multi-tenant: plataformas SaaS donde cada cliente tiene su dominio, y vos tenés que correr validaciones DNS para todos ellos. La carga operativa escala mal.

Ponele que tenés una plataforma con 300 clientes y cada uno con su dominio propio. Cada renovación implica modificar registros DNS de terceros, manejar errores de propagación, y rezar para que los TTL no te jueguen en contra a las 2 de la mañana cuando corra el cron.

¿Cómo funciona el nuevo desafío DNS-PERSIST-01?

El flujo es bastante más limpio. Según el anuncio oficial de Let’s Encrypt, el proceso básico es este:

Paso 1: Creás un registro TXT en _validation-persist.tudominio.com con el valor que identifica la CA y tu cuenta ACME.
Paso 2: La CA consulta ese registro y verifica que el account URI coincide con la cuenta que está solicitando el certificado.
Paso 3: La validación queda aprobada. Para renovaciones futuras, la CA vuelve a consultar el mismo registro, sin pedirte nada más.

El registro no cambia entre emisiones. Eso es todo el punto.

Lo que sí cambia es que el control queda expresado de forma declarativa en tu DNS: “esta CA, con esta cuenta, tiene autorización para emitir certificados para este dominio”. Es un modelo diferente al de token efímero, y conceptualmente está más cerca de cómo funcionan otros mecanismos de autorización por DNS (como CAA records, aunque con propósito distinto). Sobre eso hablamos en nuestra comparativa de seguridad y privacidad.

Implementación técnica: formato del registro y parámetros

El formato del registro TXT, según la documentación técnica disponible, sigue esta estructura:

"letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"

Eso es el mínimo. Pero hay parámetros opcionales que vale entender bien:

policy=wildcard: restringe la autorización solo a certificados wildcard. Si no lo ponés, aplica a cualquier tipo de certificado del dominio.
persistUntil=: fecha de expiración del registro. Útil para dar autorizaciones temporales sin tener que acordarte de borrar el TXT después (spoiler: nadie se acuerda de borrar los TXT después).

El accounturi es lo que hace que esto tenga sentido desde el punto de vista de seguridad. No es un registro que dice “cualquiera puede emitir certificados acá”. Está atado a una cuenta ACME específica. Si alguien consigue crear ese registro en tu DNS, igual necesita controlar esa cuenta para aprovecharlo.

Diferencias clave entre DNS-01 y DNS-PERSIST-01

Aspecto	DNS-01 tradicional	DNS-PERSIST-01
Registro TXT	Token único por validación, cambia en cada emisión	Registro fijo, se crea una sola vez
Cambios en DNS	Requeridos en cada renovación	No requeridos después del setup inicial
Credenciales de API DNS	Necesarias en runtime para cada operación	Solo para crear/actualizar el registro persistente
Soporte wildcard	Sí (es el método estándar para wildcards)	Sí, con parámetro policy=wildcard
Propagación DNS	Problema en cada renovación	Solo relevante en la configuración inicial
Escala	Carga alta en entornos con muchos dominios	Diseñado para escalar sin carga operativa adicional
Caducidad configurable	No aplica (el token expira solo)	Sí, mediante persistUntil=

let's encrypt dns-persist-01 diagrama explicativo

Casos de uso ideales para DNS-PERSIST-01

No es para todos. Si tenés un sitio personal con un dominio y renovás el certificado una vez al año, DNS-01 con Certbot zafa perfectamente.

Donde DNS-PERSIST-01 gana de forma clara:

Plataformas multi-tenant

Hosting con dominios propios de clientes, SaaS con custom domains, plataformas de e-commerce donde cada tienda tiene su dominio. Acá es donde el modelo de token por validación empieza a doler. Con DNS-PERSIST-01, el cliente configura el registro una sola vez al agregar su dominio, y la plataforma puede renovar certificados sin intervención posterior. Si usás un servicio de hosting en donweb.com o montás tu propia infraestructura multi-tenant, este método simplifica considerablemente el flujo de certificados.

Despliegues IoT y edge

Dispositivos que necesitan certificados válidos pero no tienen capacidad de correr flujos complejos de credenciales DNS en runtime. Con un registro persistente, la renovación puede gestionarse desde un sistema central sin necesidad de pasar credenciales a cada dispositivo.

Operaciones por lote con certificados de vida corta

Let’s Encrypt viene empujando hacia certificados de 45 días (en vez de 90). Más renovaciones por año = más operaciones DNS con el método clásico. Con DNS-PERSIST-01, esa frecuencia no agrega fricción operativa. Relacionado: guía completa de herramientas para IA.

Consideraciones de seguridad y riesgos potenciales

Un registro TXT que persiste en tu DNS y autoriza emisión de certificados es un objetivo interesante para un atacante. Hay que ser honesto con eso.

El diseño mitiga el riesgo principal al vincular el registro a un accounturi específico. No alcanza con crear el registro en el DNS: sin controlar la cuenta ACME correspondiente, esa autorización no sirve. Eso sí: si alguien compromete tu cuenta ACME y además puede leer o mantener el registro DNS, tiene un vector de emisión de certificados bastante limpio.

Actualizás las credenciales de tu cuenta ACME, pensás que cerraste el acceso no autorizado, pero el registro persistente sigue ahí apuntando a esa cuenta (o a la nueva si la rotaste), y si no lo auditás activamente, podés tener autorizaciones huérfanas sin saberlo. El parámetro persistUntil= existe exactamente para esto: establecer un TTL de autorización que te fuerce a renovar la configuración periódicamente, no solo el certificado.

¿El soporte y auditoría de registros TXT en la mayoría de los equipos? Mejor no preguntar.

El futuro de la automatización de certificados con ACME

DNS-PERSIST-01 no está solo. Forma parte de una tendencia más amplia en el ecosistema ACME: automatización total del ciclo de vida de certificados, sin intervención manual, sin fricción, y con períodos de validez más cortos para reducir el impacto de un certificado comprometido. Lo explicamos a fondo en comparativa detallada entre Microsoft y GitHub.

El método está definido como borrador IETF, lo que significa que el protocolo todavía puede cambiar antes de su formalización, aunque Let’s Encrypt ya lo tiene en implementación activa según Linux Today. Otros clientes ACME y otras CAs eventualmente van a sumarse si el borrador progresa y se aprueba como estándar.

La dirección es clara: los certificados de 90 días ya empezaron a quedarse cortos para algunos flujos, y los de 45 días van a requerir automatización robusta o vas a estar gestionando renovaciones de forma continua, lo que con DNS-01 tradicional escala muy mal.

Qué está confirmado y qué no

Confirmado

Let’s Encrypt anunció DNS-PERSIST-01 en febrero de 2026.
El registro se coloca en _validation-persist.dominio.com y es persistente entre renovaciones.
El formato incluye identificador de CA, accounturi, y parámetros opcionales policy y persistUntil.
Soporta certificados wildcard mediante el parámetro policy=wildcard.
Let’s Encrypt lo tiene en implementación activa.

Todavía no confirmado / pendiente

Adopción por parte de otras CAs. El borrador IETF está en proceso; que otras autoridades certificadoras lo soporten depende de ese proceso y de sus propios timelines.
Soporte en clientes ACME populares. Certbot, acme.sh y similares van a necesitar actualizaciones para manejar este flujo. Al momento del anuncio, el soporte en clientes era parcial o experimental.
Fecha de aprobación del borrador IETF como RFC formal.

Errores comunes al trabajar con DNS-PERSIST-01

Confundir el dominio del registro con el del certificado

El registro va en _validation-persist.tudominio.com, no en _acme-challenge.tudominio.com como en DNS-01. Es un error fácil de cometer si venís de configurar DNS-01 y lo hacés de memoria. Si el registro está en el lugar incorrecto, la CA no lo va a encontrar y la validación va a fallar sin un mensaje de error muy claro.

Olvidarse de vincular el accounturi correcto

Si usás múltiples cuentas ACME (staging vs. producción, distintos entornos), el accounturi tiene que coincidir exactamente con la cuenta que está solicitando el certificado. Un registro con el accounturi de la cuenta de staging no va a validar en producción. Parece obvio, pero cuando migrás configuraciones entre entornos se presta a confusión.

No establecer persistUntil en autorizaciones que deberían ser temporales

Si le das acceso a un sistema externo para emitir certificados de un dominio tuyo, y no ponés fecha de expiración, ese acceso queda indefinidamente hasta que alguien lo borre a mano. Nadie borra registros TXT a mano. Ponele siempre un persistUntil a las autorizaciones que no son para uso propio permanente.

Asumir que reemplaza DNS-01 en todos los casos

DNS-PERSIST-01 no va a estar disponible en todos los clientes ACME desde el día uno. Si migrás todo tu flujo a este método asumiendo soporte universal, podés encontrarte con que tu cliente de renovación automática no sabe qué hacer con él. Revisá el soporte de tu cliente antes de adoptar esto en producción. Para más detalles técnicos, mirá guía sobre gadgets y hardware móvil.

Preguntas Frecuentes

¿DNS-PERSIST-01 reemplaza al DNS-01 tradicional?

No, al menos no en el corto plazo. DNS-01 sigue siendo el método estándar para validación DNS y va a continuar funcionando. DNS-PERSIST-01 es una alternativa pensada para casos de uso específicos donde la frecuencia de cambios DNS es un problema. Los dos métodos van a coexistir.

¿Es seguro usar DNS-PERSIST-01 para certificados wildcard?

Sí, con la configuración adecuada. El parámetro policy=wildcard restringe la autorización solo a ese tipo de certificados, y el accounturi vincula la autorización a una cuenta ACME específica. El riesgo principal es dejar registros persistentes sin fecha de expiración o con cuentas ACME comprometidas, lo que aplica a cualquier mecanismo de validación automatizado.

¿Cuándo voy a poder usarlo con Certbot o acme.sh?

Todavía no hay fechas concretas de soporte en los clientes ACME más populares. Let’s Encrypt tiene la implementación del lado de la CA, pero los clientes necesitan actualizar su lógica para soportar este tipo de desafío. Seguí los changelogs de tu cliente preferido; es probable que aparezca soporte experimental en los próximos meses.

¿Sirve para dominios en cualquier proveedor DNS?

Sí, siempre que puedas crear registros TXT en tu zona DNS. No hay requerimiento sobre el proveedor específico. Lo que cambia respecto a DNS-01 es que no necesitás acceso de escritura frecuente a tu DNS vía API: con crear el registro una vez alcanza para las renovaciones futuras.

Conclusión

DNS-PERSIST-01 resuelve un problema real que cualquiera que haya operado certificados a escala conoce bien: la fricción de tener que modificar el DNS en cada renovación, distribuir credenciales de API, y lidiar con propagación en el momento menos oportuno. El diseño es limpio y el modelo de autorización declarativa tiene sentido.

El punto flaco es que todavía es un borrador IETF y el soporte en clientes ACME va a tardar en llegar. Tomalo con pinzas si estás pensando en adoptarlo mañana en producción. Pero si gestionás plataformas multi-tenant, despliegues de IoT, o cualquier entorno donde los certificados de vida corta vayan a multiplicar tus operaciones DNS, vale la pena seguir de cerca cómo avanza el soporte.

Para el resto, DNS-01 sigue funcionando bien. No hay urgencia en migrar.

¿Cómo configuro DNS-PERSIST-01 con Certbot?

Certbot aún está agregando soporte nativo para DNS-PERSIST-01. Por ahora, podés crear manualmente el registro TXT en _validation-persist.tudominio.com con el formato requerido, y luego usar Certbot en modo manual o con un hook para validación. Una vez que el registro persiste, Certbot puede renovar sin intervención posterior.

¿Qué es más seguro: DNS-01 o DNS-PERSIST-01?

DNS-PERSIST-01 es más seguro en escenarios multi-tenant porque el registro está vinculado a una cuenta ACME específica (accounturi). No necesitás distribuir credenciales de DNS en runtime. Sin embargo, el registro persistente es un objetivo visible para atacantes; usá persistUntil= para establecer expiración de autorización.

¿Debo migrar de DNS-01 a DNS-PERSIST-01?

Solo si tu caso de uso se beneficia: plataformas multi-tenant, IoT, o muchos dominios con renovaciones frecuentes. Para un sitio personal o pequeño, DNS-01 con Certbot funciona perfectamente. DNS-PERSIST-01 está especializado para escala.