dns-persist-01: estado y árbol de decisión para certificados TLS

⚡TL;DR

• dns-persist-01 vincula un TXT duradero a una autoridad de certificación y a una cuenta ACME. Desde el borrador -02, la cuenta figura en él como un URI con hash.
• Dejas el TXT en su sitio. La autoridad solo puede basarse en una lectura durante 10 días: después, vuelve a leer el mismo TXT antes de emitir un certificado.
• Al 11 de octubre de 2026, la issue #64, que Let's Encrypt esperaba, queda resuelta con el borrador -02, pero no hay ninguna fecha anunciada. Google Trust Services está en producción con el formato del borrador -01: publica el formato que documente tu CA.

Un TXT que permanece publicado puede reducir las escrituras DNS necesarias para validar dominios. Ese es el interés de dns-persist-01 para los equipos que deben renovar sus certificados TLS con más frecuencia. No elimina las nuevas comprobaciones de la autoridad de certificación (CA) ni la instalación del certificado renovado.

El tema abarca varias realidades: un método admitido por los Baseline Requirements (BR), una propuesta de challenge ACME y programas en distintas fases de integración. Para decidir, parte de tu cadena real de emisión. Que un cliente esté preparado no hace compatible a su servidor.

¿Cuál es el estado de dns-persist-01 al 11 de octubre de 2026?

Estado al 11 de octubre de 2026

Los BR TLS v2.3.0 permiten la validación DNS persistente en el §3.2.2.4.22. Datatracker muestra draft-ietf-acme-dns-persist-02, publicado el 20 de septiembre de 2026. Es un documento de trabajo del grupo ACME del IETF: su sintaxis TXT todavía puede cambiar.

Las comunicaciones de Let's Encrypt consultadas no anuncian ni fecha de despliegue ni soporte del borrador -02. Google Trust Services anuncia el soporte de dns-persist-01 desde el 28 de septiembre de 2026, sobre la base del borrador -01.

El 25 de junio de 2026, Aaron Gable había fijado una condición: "We will not be deploying dns-persist-01 until [...] is resolved." El fragmento omitido se refiere a la issue #64, que solicitaba incluir en la prueba información calculada por el cliente. Esta reserva afectaba a la seguridad del protocolo, no a un simple retraso de empaquetado. La issue se cerró el 23 de septiembre de 2026 con este comentario: "Resolved in PR #67 and published in draft-ietf-acme-dns-persist-02". Por tanto, la issue a la que apuntaba el mensaje de Aaron Gable está resuelta en el lado del IETF. Aun así, al 11 de octubre de 2026, las comunicaciones de Let's Encrypt consultadas no anuncian ninguna fecha de despliegue.

La página de tipos de challenge de Let's Encrypt sigue sin incluir dns-persist-01 entre los métodos activos. El borrador -01 debía caducar el 25 de septiembre de 2026; el borrador -02 lo sustituyó el 20 de septiembre. El challenge conserva su nombre: -02 designa la versión del documento, no un nuevo challenge. Este cambio de versión no es una fecha de lanzamiento ni una anulación de los BR.

Google Trust Services (GTS) publicó el 28 de septiembre de 2026 una página dedicada a dns-persist-01. Indica: "Google Trust Services now supports the dns-persist-01 challenge type". La misma página precisa la versión que sigue: "Defined in the IETF Internet-Draft draft-ietf-acme-dns-persist-01". Su ejemplo coloca una URL de cuenta en claro en accounturi, lo que corresponde al formato -01. El borrador actual exige un URI con hash, y los dos formatos son incompatibles. Por tanto, un TXT solo es válido para la CA y el formato que esta documenta.

En SwissSign, las fuentes han evolucionado. La publicación del 9 de marzo de 2026 anunciaba una puesta en producción durante el verano. La CP/CPS TLS versión 3.0 del 24 de agosto de 2026, todavía vigente al 11 de octubre de 2026, describe el método 22 solo para Managed PKI. Su historial sitúa esta incorporación el 17 de agosto. Esto documenta una práctica de la CA dentro de ese ámbito; no demuestra que cualquier cliente ACME pueda negociar dns-persist-01 con ese servicio.

Qué no cubre este artículo

Este análisis te ayuda a decidir si tiene sentido realizar una evaluación para tu conjunto de certificados TLS. No sustituye al calendario completo de certificados de 47 días ni a la guía para automatizar la renovación de certificados TLS. Esos temas también abarcan la planificación, el despliegue y la supervisión de certificados.

Tampoco es una guía sobre CAA o DNSSEC: más abajo se distinguen sus funciones, con recursos específicos. Por último, no es un procedimiento de despliegue de dns-persist-01. Publicar un TXT no basta para que una CA acepte el challenge ni para resolver todas las renovaciones.

¿Qué valida el TXT persistente y durante cuánto tiempo?

El TXT representa una autorización de validación de dominio vinculada a un emisor y a una cuenta. El tiempo que permanece publicado es distinto de la vigencia de la prueba obtenida por la CA.

_validation-persist.[ADN]: nombre DNS, emisor y cuenta autorizada

El método figura en los BR §3.2.2.4.22, registro DNS TXT con valor persistente. ADN significa Authorization Domain Name, el nombre de dominio utilizado para obtener la autorización relativa al nombre solicitado. No designa siempre el dominio raíz. Para un servicio bajo app.captaindns.com, no des por hecho que la CA consultará necesariamente un TXT bajo captaindns.com.

El nombre consultado sigue la forma _validation-persist.[ADN]. Su valor utiliza la sintaxis issue-value del RFC 8659, sección 4.2: issuer-domain-name; accounturi=URI_HASH. Esta notación describe los campos; no es un valor que debas publicar. issuer-domain-name identifica al emisor según su CP/CPS, y accounturi designa la cuenta autorizada ante él. Un nombre de CA que se parezca a su marca no sustituye al identificador que declara.

El borrador -02 cambia la forma de accounturi (§4.1). El parámetro debe ser un URI con hash de la forma <accountHashPrefix><hash-alg>/<valor base64url>. La CA publica el prefijo en los metadatos de su directorio ACME. SHA-256 es obligatorio tanto para el cliente como para la CA. El hash abarca cuatro elementos: la longitud del dominio, el dominio donde se publica el TXT (sin _validation-persist), la huella SHA-256 (RFC 7638) de la clave pública de la cuenta ACME en formato JSON (JWK) y la URL de la cuenta. Tras una rotación de clave, la CA debe aceptar un hash calculado con la clave actual o con una clave anterior que haya conservado.

El hash aporta dos protecciones. En primer lugar, el canal que te transmite la URL de la cuenta puede estar comprometido y sustituirla por la de otra cuenta. El TXT generado es entonces inutilizable, porque el hash también depende de la clave de la cuenta legítima. En segundo lugar, una misma cuenta genera un valor distinto para cada dominio. Así, quien observe el DNS ya no puede relacionar los dominios de una cuenta solo con leer los TXT. El hash no oculta la cuenta a la CA: esta recalcula el valor y así encuentra la URL de la cuenta (§7.2.3). El cliente también puede sustituir el dominio por *. En ese caso aparece el mismo valor en cada TXT, y esos dominios vuelven a poder relacionarse.

La forma del borrador -01, una URL de cuenta en claro sin vínculo criptográfico, "is no longer accepted" según el registro de cambios del -02. Por tanto, ya no es conforme al borrador actual. Sin embargo, es la que documenta Google Trust Services al 11 de octubre de 2026.

El parámetro opcional persistUntil añade una fecha de caducidad expresada en segundos Unix. Pasada esa fecha, el registro ya no puede servir para una nueva validación. Sin este parámetro, el TXT no tiene una caducidad propia de esta sintaxis. El proyecto ACME sigue siendo un documento de trabajo: anota la versión del borrador y el formato de TXT asociados a cada evaluación.

La cuenta merece tanta atención como el DNS. Con hash o en claro, accounturi siempre designa una cuenta concreta. Cuando un proveedor deja tu organización, mantener el TXT de su cuenta en la zona equivale a conservar una autorización que quizá ya no quieras. Prevé su retirada, los plazos de caché y la gestión de las pruebas ya obtenidas. Eliminar el TXT no revoca los certificados ya emitidos.

Un TXT duradero y una prueba de la CA reutilizable durante un máximo de 10 días

El límite de reutilización de los datos de validación es de 10 días como máximo para este método, desde que se utiliza. No espera a 2029. Cuando una CA ya no puede reutilizar su prueba, debe volver a validar el dominio antes de basarse de nuevo en este método para emitir.

Coexisten cuatro plazos: la presencia del TXT, su posible caducidad persistUntil, la vigencia de la prueba de la CA y la validez del certificado. Un TXT publicado durante un año puede servir para varias comprobaciones sucesivas. Eso nunca permite reutilizar la primera prueba durante un año. A la inversa, el límite de diez días no obliga al titular a sustituir el TXT cada diez días.

Ese es el cambio operativo buscado: la CA puede volver a leer un registro estable mientras el cliente sigue solicitando y desplegando certificados. Reduces las modificaciones de la zona ligadas a la validación sin eliminar el trabajo de renovación.

DV, OV, EV y wildcard: ¿cuál es el alcance?

En los certificados TLS DV, OV y EV, este método valida el nombre. No verifica la identidad de la empresa ni sustituye ninguna comprobación organizativa exigida para OV o EV. La aceptación de un tipo de certificado sigue siendo una decisión de la CA, sujeta a las reglas del perfil correspondiente.

Los BR admiten el método persistente para validar nombres wildcard sin eliminar las restricciones propias de los perfiles de certificados. En el borrador ACME, policy=wildcard es opcional, en el sentido normativo de MAY. La publicación técnica de Let's Encrypt describe esta ampliación de alcance; no constituye una oferta disponible. Al 11 de octubre de 2026, Let's Encrypt no incluye dns-persist-01 entre sus challenges activos, tampoco para wildcard. Google Trust Services documenta policy=wildcard para cubrir el dominio, sus subdominios y el wildcard; esta constatación solo vale para esa CA. La CP/CPS de SwissSign consultada reserva la validación wildcard a otros métodos.

Para las IP, el §3.2.2.5.8 prevé _ip-validation-persist bajo el nombre de la zona inversa correspondiente; esta disposición de los BR no demuestra su disponibilidad en ACME.

S/MIME sigue siendo un punto poco claro en los documentos comparados aquí: su mención en la publicación de SwissSign no permite concluir que el challenge esté soportado. La firma de código y los VMC quedan fuera del alcance.

DNS-01, dns-account-01 y CAA: tres distinciones esenciales

Estos mecanismos responden a necesidades distintas, aunque utilicen el DNS o un identificador de cuenta ACME.

DNS-01 utiliza _acme-challenge, no el TXT persistente

DNS-01 exige un valor ligado al challenge bajo _acme-challenge. El registro contribuye a una prueba puntual; no constituye la autorización persistente descrita aquí. Su funcionamiento se define en el RFC 8555, sección 8.4.

Con dns-persist-01 cambian el nombre consultado y el contenido esperado. Dejar un antiguo token DNS-01 en la zona no lo convierte en un TXT persistente. Una delegación CNAME de _acme-challenge tampoco realiza esa conversión. Para un entorno ya automatizado, DNS-01 mantiene su utilidad mientras el par cliente/CA lo soporte.

dns-account-01 corresponde a otro método de los BR

dns-account-01 separa los nombres de validación según la cuenta ACME. Esto facilita la coexistencia de varios clientes o proveedores sin que compartan exactamente el mismo nombre de challenge. El valor sigue ligado a una validación, a diferencia de la autorización duradera de dns-persist-01.

Los BR lo referencian en el §3.2.2.4.21, con un procedimiento vinculado al borrador 00. El Datatracker del proyecto dns-account-label sigue mostrando la versión -03 al 11 de octubre de 2026. Una referencia normativa en los BR, el avance en el IETF y el soporte de una CA son tres datos distintos. Calificarlo simplemente de borrador ocultaría el primero.

accounturi en CAA no tiene la misma función

CAA expresa una política de emisión: determina qué autoridades pueden emitir y puede restringir ese permiso a una cuenta. La extensión accounturi se define en el RFC 8657. Compartir nombre con el parámetro del TXT persistente no la convierte en la misma prueba.

Una política CAA compatible no demuestra por sí sola el control del dominio. A la inversa, un TXT persistente válido no exime a la CA de verificar CAA. La función de los registros CAA sigue siendo, por tanto, complementaria al método de validación elegido.

¿Por qué los certificados de 47 días cambian la situación?

Las renovaciones más frecuentes encarecen las intervenciones DNS repetidas, sobre todo cuando cada cambio requiere aprobación humana.

En 2029, certificados de 47 días y 10 días de reutilización de DCV

A partir del 15 de marzo de 2029, el máximo previsto para los certificados TLS públicos será de 47 días, con diez días de reutilización de los datos de validación de dominio. El calendario de certificados TLS de 47 días detalla las etapas intermedias. Este calendario general no aplaza el límite de diez días ya asociado al método persistente.

El interés depende de tus restricciones. Un equipo cuyo DNS exige cambios manuales puede evitar intervenciones recurrentes si su CA acepta una autorización duradera. Un equipo al que DNS-01 ya le funciona con permisos restringidos tendrá que valorar otros factores. En ambos casos, el certificado debe llegar al servicio correcto antes de caducar.

Delegación CNAME y acme-dns: qué recomiendan los BR

Los BR §3.2.2.4.7 se refieren específicamente al caso en que una CA, o una entidad afiliada, opera una zona que recibe delegaciones CNAME de validación. Este servicio se parece al modelo acme-dns. El texto indica SHOULD NOT para su operación y SHOULD para orientar a los usuarios hacia el §3.2.2.4.22. La incorporación procede de la propuesta SC-088v3.

Son recomendaciones normativas fuertes, no una prohibición absoluta de toda delegación CNAME. Se dirigen a la CA o a su afiliada que opera el servicio. No constituyen una orden de eliminar inmediatamente tu instancia acme-dns, y menos aún de migrar a un challenge no disponible en Let's Encrypt. Pregunta qué método acepta tu autoridad antes de modificar un sistema que funciona.

Clientes ACME: ¿qué pruebas de soporte hay al 11 de octubre de 2026?

Las pruebas disponibles van desde una versión publicada hasta una solicitud de funcionalidad abierta. La matriz siguiente describe ese estado documental, comprobado el 11 de octubre de 2026; no clasifica a las autoridades capaces de emitir. Distingue el borrador -01 (URL de cuenta en claro) del borrador -02 (URI con hash).

Cliente	Versión o estado del cambio	Fuente primaria exacta	Fecha del análisis	Alcance y límite del lado de la CA
lego	Implementación presente desde v5.0.0, con adaptación al borrador -01; notas de v5.5.0, v5.5.1 y v5.5.2 sin mención del borrador -02	Versión v5.0.0, incluido el cambio #2991, y versiones de lego	11/10/2026	Prueba para el formato -01 en lego ≥ v5.0.0; ninguna prueba de soporte del -02. Comprueba el formato que espera la CA. No se deduce disponibilidad en LE.
acme.sh	La versión 3.1.4 anuncia dns-persist-01; modo documentado; 3.1.5 y 3.1.6 sin mención del borrador -02, y 3.1.6 indica "No functional change since 3.1.5"	Versión 3.1.4, wiki del modo DNS persistente y versiones de acme.sh	11/10/2026	Versión que acredita soporte, sin pretender establecer la primera versión compatible; ninguna prueba de soporte del -02. Los ejemplos del wiki no prueban una disponibilidad actual en LE.
Certbot	PR #10633 cerrada el 3 de agosto de 2026, sin fusionar; solicitud #10549 abierta; PR #10794 (en modo draft), #10799 y #10800 (plugin y documentación) abiertas, sin fusionar	PR #10633, issue #10549, PR #10794, PR #10799 y PR #10800	11/10/2026	Ninguna de estas PR se ha entregado en una versión publicada. El borrador al que apuntan no está establecido aquí. No se deduce ningún procedimiento utilizable.
cert-manager	Solicitud #8373 abierta	Issue #8373	11/10/2026	Una solicitud no demuestra una implementación publicada ni compatibilidad con una CA.
win-acme	Solicitud #2849 abierta	Issue #2849	11/10/2026	El trimestre citado en el título de la issue no es una fecha de entrega. La aceptación por la CA debe comprobarse por separado.

Para lego, v5.0.0 ya aporta una prueba publicada para el borrador -01: atribuir la llegada del challenge a una versión posterior sería engañoso. En Certbot, que la PR #10633 esté cerrada no significa que se haya fusionado; la API de GitHub confirma merged: false. Las PR abiertas en octubre de 2026 siguen siendo trabajos en curso mientras no se fusionen ni se publiquen. Estas diferencias cambian la decisión operativa.

Conserva las referencias de versión en tu documentación de evaluación, junto con el borrador que sigue cada componente. Un paquete suministrado por una distribución o integrado en otro producto puede diferir de la última versión del proyecto original. Comprueba después el método que la CA ofrece realmente para la autorización en cuestión. La presencia de una opción en el cliente no sustituye esa comprobación.

DNSSEC y MPIC: por qué puede fallar la validación aunque el TXT esté presente

Una respuesta TXT legible desde tu equipo no demuestra su validez DNSSEC ni su visibilidad desde las perspectivas de la CA.

SC-085 también afecta a la validación DNS persistente

SC-085 exige la validación DNSSEC de las consultas DCV desde la perspectiva principal de la CA. El método persistente no es una excepción. Los BR v2.3.0 consolidan estos requisitos en el §4.2.2.2. Una cadena firmada inválida puede bloquear la validación aunque el texto del TXT sea correcto.

Esto no hace obligatoria la firma DNSSEC para todos los dominios. Hay que distinguir una zona sin firmar de una zona cuya cadena de confianza está rota. Un cambio de proveedor DNS con un antiguo DS todavía publicado puede provocar el segundo caso. Nuestro artículo sobre la validación DNSSEC de certificados TLS y SC-085 explica este diagnóstico.

Las respuestas DNS que varían por región pueden hacer fallar MPIC

MPIC, Multi-Perspective Issuance Corroboration, contrasta las observaciones de varias perspectivas de red. Para el método persistente, las perspectivas que corroboran deben observar una prueba válida que contenga el mismo accounturi que la perspectiva principal. El mecanismo sigue las reglas de cuórum de los BR, no una simple consulta DNS local.

Un DNS que varía geográficamente puede fallar si algunas perspectivas reciben otra cuenta o no encuentran una prueba utilizable. Esto no descarta todo GeoDNS: las respuestas A distintas según la región pueden coexistir con un TXT de validación coherente. Lo que importa es la respuesta utilizada para validar y las perspectivas necesarias, no la etiqueta comercial del servicio DNS.

Árbol de decisión: ¿esperar, evaluar o mantener el método actual?

Empieza por la autoridad y después examina el cliente y tu capacidad para gestionar la autorización. Cada respuesta debe basarse en una prueba fechada.

¿Tu autoridad acepta el método para el certificado previsto?

Busca una práctica declarada en la CP/CPS y documentación del servicio que corresponda a tu contrato. Una mención a Managed PKI no equivale a acceso para todas las cuentas ni todos los perfiles. Comprueba también el caso wildcard si dependes de él. Por último, anota el borrador y el formato de TXT que documenta la CA: URL de cuenta en claro (-01) o URI con hash (-02).

Si la respuesta es no o no está clara, mantén un método soportado. Para Let's Encrypt, la decisión sigue siendo esperar: al 11 de octubre de 2026 no hay ninguna fecha anunciada. Un anuncio antiguo o una captura del entorno de pruebas no permiten planificar una migración en producción.

¿Tu cliente dispone de una implementación publicada y compatible?

Compara la versión instalada con la matriz y después con el borrador aceptado por la CA, -01 o -02. Un cliente que genera el formato -01 no sirve para una CA que exige el URI con hash, y viceversa. Una PR sin fusionar o una solicitud abierta dejan esta etapa sin prueba de entrega. Según tu contexto, espera o prepara una evaluación fuera de producción con los componentes realmente disponibles.

Documenta el resultado esperado: negociación del challenge, validación, emisión y después renovación. Obtener un primer certificado no demuestra por sí solo que la renovación funcionará cuando caduque la prueba de la CA.

¿Están preparados tu DNS y tu gestión de autorizaciones?

Identifica quién controla el TXT, quién posee la cuenta autorizada y quién puede retirar esa autorización. Comprueba DNSSEC y la visibilidad del nombre desde varias redes. Incluye la salida de un proveedor o la sustitución de una cuenta entre las situaciones que debes gestionar. Prevé también volver a publicar el TXT si tu CA pasa del formato -01 al formato con hash.

Si todas las condiciones están documentadas, resulta razonable realizar una evaluación controlada con la CA correspondiente. Mantén la supervisión de las renovaciones y un método de recuperación probado. El beneficio esperado es reducir las escrituras DNS; se puede medir sin suponer que desaparecerá toda intervención futura.

Comprobar el TXT y DNSSEC sin presuponer la aceptación por la CA

La consulta TXT ayuda a observar el nombre _validation-persist que realmente corresponde. La comprobación DNSSEC examina la cadena de confianza del dominio. Estas dos verificaciones aportan información para el diagnóstico DNS; no negocian el challenge con tu autoridad ni garantizan la emisión de un certificado.

DNS watch puede complementar este trabajo con un seguimiento gratuito de los cambios DNS, independientemente del método. Una alerta ayuda a detectar una retirada o modificación; no certifica la compatibilidad ACME. La prueba final sigue siendo el comportamiento documentado del par cliente/CA para el certificado solicitado.

FAQ

¿dns-persist-01 sustituye a DNS-01 y dns-account-01?

No. Propone una autorización DNS duradera vinculada a una cuenta y a un emisor. DNS-01 y dns-account-01 utilizan otras pruebas y siguen siendo opciones distintas según su soporte.

¿Let's Encrypt permite utilizar dns-persist-01 al 11 de octubre de 2026?

En esa fecha, no. La issue IETF #64, cuya resolución esperaba Let's Encrypt en junio, está cerrada desde el 23 de septiembre de 2026: el borrador -02 la resuelve. Aun así, las comunicaciones consultadas no anuncian ninguna fecha de despliegue, y la documentación de los challenges activos no lo ofrece.

¿Sigue funcionando un TXT con el formato del borrador -01?

En Google Trust Services, sí: es el formato que documenta al 11 de octubre de 2026. En cambio, ya no es conforme al borrador -02, que exige un URI de cuenta con hash. Publica el formato que documente tu CA y prevé volver a publicar el TXT si adopta el formato con hash.

¿Por qué volver a validar el dominio si el TXT sigue publicado?

La autoridad solo puede basarse en una lectura del DNS durante un máximo de 10 días. Después, vuelve a leer el mismo TXT antes de emitir un certificado; no tienes que sustituirlo.

¿dns-persist-01 cubre los certificados DV, OV, EV y wildcard?

La validación persistente afecta al nombre para DV, OV y EV, sin sustituir las comprobaciones de la empresa. Los BR permiten la validación wildcard con este método, sujeta a las reglas del perfil y a la aceptación de la CA. Google Trust Services documenta esta opción con policy=wildcard. Let's Encrypt no la ofrece al 11 de octubre de 2026.

¿Basta con un cliente ACME compatible para utilizar dns-persist-01?

No. La CA debe aceptar el método para tu cuenta y tu certificado. Una versión del cliente demuestra una implementación, no la disponibilidad del servicio remoto.

¿Un TXT visible en una consulta garantiza una validación DNSSEC y MPIC correcta?

No. El resultado depende del resolvedor y del punto de observación. La CA todavía debe validar DNSSEC y obtener la corroboración necesaria desde sus perspectivas de red.