dns-persist-01: estado y árbol de decisión para certificados TLS
Por CaptainDNS
Publicado el 16 de septiembre de 2026
- dns-persist-01 vincula un TXT duradero a una autoridad de certificación y a una cuenta ACME. Su disponibilidad depende de ambos lados del protocolo.
- 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 16 de septiembre de 2026, el despliegue de Let's Encrypt sigue congelado. Comprueba primero tu autoridad y después tu cliente antes de plantearte una evaluación.
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 16 de septiembre de 2026?
Estado al 16 de septiembre de 2026
Los BR TLS v2.3.0 permiten la validación DNS persistente en el §3.2.2.4.22. Datatracker sigue mostrando
draft-ietf-acme-dns-persist-01, un documento de trabajo cuya sintaxis TXT puede cambiar.Let's Encrypt mantiene congelado su despliegue a la espera de que se resuelva la issue IETF ACME #64, todavía abierta. Su documentación presenta HTTP-01, DNS-01 y TLS-ALPN-01 como métodos utilizables. Aquí no se confirma ninguna fecha de producción ni el funcionamiento actual del entorno de pruebas.
El bloqueo es explícito. El 25 de junio de 2026, Aaron Gable escribió: "We will not be deploying dns-persist-01 until [...] is resolved." El fragmento omitido se refiere a la issue #64, que solicita incluir en la prueba información calculada por el cliente. Esta reserva afecta a la seguridad del protocolo, no a un simple retraso de empaquetado. El mensaje de Aaron Gable sigue siendo la referencia para esta congelación.
La página de tipos de challenge de Let's Encrypt no incluye dns-persist-01 entre los métodos activos. También conserva un aviso histórico sobre TLS-SNI-01, ya retirado. La caducidad del borrador -01 el 25 de septiembre de 2026 afecta a esa versión del documento IETF. No es una fecha de lanzamiento ni una anulación de los BR.
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 actual, versión 3.0 del 24 de agosto de 2026, describe ahora 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_DE_LA_CUENTA. 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 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. Como el protocolo ACME sigue en discusión, conserva la versión de la especificación asociada a cada evaluación.
La cuenta merece tanta atención como el DNS. Cuando un proveedor deja tu organización, mantener su URI 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. En el estado recogido aquí, dns-persist-01 no se puede utilizar en Let's Encrypt, tampoco para wildcard. 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 muestra la versión -03 en la fecha del análisis. 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 16 de septiembre 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 16 de septiembre de 2026; no clasifica a las autoridades capaces de emitir.
| 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 | Versión v5.0.0, incluido el cambio #2991 | 16/09/2026 | Prueba para lego ≥ v5.0.0; comprueba la compatibilidad de la versión elegida con la CA. No se deduce disponibilidad en LE. |
| acme.sh | La versión 3.1.4 anuncia dns-persist-01; modo documentado | Versión 3.1.4 y wiki del modo DNS persistente | 16/09/2026 | Versión que acredita soporte, sin pretender establecer la primera versión compatible. 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 #10633 e issue #10549 | 16/09/2026 | Esta PR no entrega el cambio del módulo manual. Su antiguo hito no permite deducir un procedimiento utilizable. |
| cert-manager | Solicitud #8373 abierta | Issue #8373 | 16/09/2026 | Una solicitud no demuestra una implementación publicada ni compatibilidad con una CA. |
| win-acme | Solicitud #2849 abierta | Issue #2849 | 16/09/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: atribuir la llegada del challenge a una versión posterior sería engañoso. En Certbot, que la PR esté cerrada no significa que se haya fusionado; la API de GitHub confirma merged: false. Estas diferencias cambian la decisión operativa.
Conserva las referencias de versión en tu documentación de evaluación. 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.
Si la respuesta es no o no está clara, mantén un método soportado. Para Let's Encrypt en el estado descrito, la decisión es esperar. 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 la especificación aceptada por la CA. 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.
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 16 de septiembre de 2026?
El despliegue sigue congelado a la espera de que se resuelva la issue IETF #64. La documentación de los challenges activos no lo ofrece. Aquí no se establece disponibilidad en producción ni en el entorno de pruebas.
¿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. Let's Encrypt no lo ofrece en el estado constatado.
¿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.
