DNS y SSL: registros DNS, DNSSEC, TLS, certificados y checklist completa

Ejemplos:

• un certificado válido no sirve de nada si el registro A apunta a un servidor antiguo,
• un registro A correcto no basta si AAAA dirige el tráfico IPv6 a una máquina que no funciona,
• la renovación automática del certificado no funcionará si el registro _acme-challenge no puede crearse o el puerto 80 está bloqueado,
• DNSSEC puede aumentar la confianza en las respuestas DNS, pero un registro DS erróneo puede provocar SERVFAIL para todo el dominio,
• un TTL corto no arreglará una delegación incorrecta de servidores de nombres,
• un certificado wildcard no cubre el dominio principal ni los subdominios de varios niveles si no se han añadido por separado.

En 2026, la gestión de certificados debería ser completamente automática. A partir del 15 de marzo de 2026, los certificados TLS públicos de tipo Subscriber Certificate pueden tener una validez máxima de 200 días. El límite bajará a 100 días en marzo de 2027 y a 47 días en marzo de 2029. Let’s Encrypt sigue emitiendo por defecto certificados de 90 días, pero también ofrece perfiles más cortos y, desde mayo de 2026, el perfil tlsserver emite certificados de 45 días para los usuarios que lo elijan de forma consciente.

TL;DR: mantén al menos dos servidores DNS autoritativos accesibles de forma independiente, controla los registros A y AAAA, implementa DNSSEC solo con un proceso seguro de gestión de DS, limita las autoridades de certificación mediante CAA, usa TLS 1.3 con TLS 1.2 como mínimo compatible, automatiza la emisión y renovación de certificados mediante ACME y monitoriza la fecha de validez, la cadena de certificados, SNI, HSTS y los errores de validación desde varias ubicaciones.

La información y los requisitos se verificaron el 23 de julio de 2026.

DNS, SSL y TLS en una sola tabla

Capa	Responsable de	Elementos más importantes	Fallos habituales
Registrador de dominios	la propiedad del dominio y la delegación	servidores de nombres, bloqueo de transferencia, DS	toma de control de la cuenta, delegación incorrecta, DS antiguo
DNS autoritativo	los registros reales de la zona	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	dirección incorrecta, falta de registro, split-brain, firma incorrecta
Resolver recursivo	encontrar y almacenar en caché la respuesta	TTL, caché, validación DNSSEC, DoH/DoT	datos antiguos en caché, validación errónea
TCP/QUIC y TLS	canal seguro hacia el servidor	TLS 1.2/1.3, SNI, ALPN, certificado	protocolo débil, cadena incorrecta, hostname mismatch
Certificado	confirmación de la identidad del nombre	SAN, issuer, validez, clave, firma	caducidad, falta de nombre, intermediate incorrecto
HTTP	redirección y política HTTPS	301/308, HSTS, cabeceras de seguridad	redirect loop, mixed content, falta de HSTS

¿Cómo funciona realmente la resolución de un dominio?

DNS es un sistema de nombres jerárquico y distribuido. El resolver no obtiene toda la respuesta de un único servidor central. De forma simplificada:

1. el navegador y el sistema comprueban la caché local,
2. el resolver recursivo consulta los servidores raíz,
3. los servidores raíz indican los servidores del dominio de nivel superior correspondiente, por ejemplo .pl,
4. el servidor TLD indica los servidores autoritativos del dominio,
5. el servidor autoritativo devuelve un registro, por ejemplo A, AAAA o CNAME,
6. la respuesta se almacena según el TTL.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

DNS no garantiza que el servidor indicado esté en buen estado ni que la respuesta HTTP sea correcta. Devuelve los datos almacenados en la zona. Por tanto, la monitorización de DNS debe combinarse con pruebas de TCP, TLS y HTTP.

1. Los registros DNS más importantes

A y AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A apunta a una dirección IPv4,
• AAAA apunta a una dirección IPv6.

El registro AAAA no es un añadido sin consecuencias. Si existe, los clientes compatibles con IPv6 pueden intentar conectarse precisamente a él. No publiques AAAA hasta que el firewall, el enrutamiento, el servidor web, el certificado y el challenge de ACME funcionen correctamente sobre IPv6.

Let’s Encrypt, durante la validación http-01, prefiere IPv6 cuando el dominio tiene un registro AAAA. Un IPv6 erróneo puede provocar que la emisión o renovación del certificado falle incluso cuando IPv4 es correcto.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

CNAME crea un alias hacia otro nombre DNS. Un nombre con CNAME no debería tener al mismo tiempo otros datos ordinarios, como A, AAAA o MX, porque CNAME indica que los datos reales se encuentran bajo otro nombre.

En el apex de la zona, es decir example.com, un CNAME clásico entra en conflicto con los registros obligatorios SOA y NS. Los proveedores lo evitan mediante sus propios mecanismos ALIAS, ANAME o flattening, pero no son registros CNAME normales transmitidos en la zona.

NS y SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS define los servidores de nombres autoritativos. La delegación en el registrador y los registros NS dentro de la zona deben ser coherentes.

SOA contiene los datos administrativos de la zona, entre otros el número de serie y los parámetros que utilizan los servidores secundarios. Con el mantenimiento manual de la zona, el número de serie debe aumentar tras cada cambio.

Una buena práctica operativa consiste en tener al menos dos servidores autoritativos que funcionen en redes o ubicaciones distintas. ICANN recomienda varios servidores autoritativos independientes, preferiblemente separados geográfica y topológicamente.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

Un número más bajo significa mayor prioridad. El destino del registro MX debe ser un nombre de host, no una dirección IP ni un CNAME.

Cambiar el hosting web no debería cambiar automáticamente el correo. Antes de migrar el DNS, guarda los registros MX, SPF, DKIM y DMARC.

TXT

TXT es un contenedor de texto utilizado, entre otros, por:

• SPF,
• DKIM,
• DMARC,
• la validación de la propiedad del dominio,
• ACME dns-01,
• integraciones SaaS.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Varios registros TXT bajo un mismo nombre pueden ser válidos, pero tener varios registros SPF que compiten y empiezan por v=spf1 es un error de diseño.

CAA

CAA permite al propietario del dominio indicar qué autoridades de certificación pueden emitir certificados para el dominio.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue se refiere a los certificados normales,
• issuewild se refiere a los wildcard,
• iodef indica el canal para informar de infracciones de la política.

CAA no sustituye el control de la cuenta en el registrador, DNSSEC ni la monitorización de Certificate Transparency. Es una restricción adicional para las CA públicas. La ausencia de CAA suele significar que cualquier CA de confianza pública puede emitir un certificado tras una validación correcta del dominio.

PTR

PTR implementa el reverse DNS, es decir, la asignación de una dirección IP a un nombre. El registro lo establece el propietario del rango de IP, normalmente el proveedor de VPS o de hosting. Es especialmente importante para los servidores de correo.

192.0.2.10 → mail.example.com

Para el correo, el nombre PTR debería normalmente conducir de vuelta, a través de A o AAAA, a la misma dirección.

HTTPS y SVCB

Los registros HTTPS y SVCB pueden transmitir al cliente información sobre cómo conectarse al servicio, endpoints alternativos, protocolos compatibles y los parámetros necesarios antes de establecer la conexión.

Ejemplo conceptual:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

No se deben introducir ipv4hint o ipv6hint como sustituto de registros de dirección correctos sin comprender el comportamiento de los clientes. El HTTPS RR es un mecanismo de optimización y señalización, no una solución para un DNS o TLS defectuoso.

2. TTL y la «propagación DNS»

El TTL determina cuánto tiempo puede el resolver conservar una respuesta en la caché. No existe un único reloj global de propagación. Tras un cambio:

• algunos resolvers todavía tienen la respuesta antigua,
• otros consultan el servidor de inmediato,
• las respuestas negativas, como NXDOMAIN, también pueden almacenarse en caché,
• el sistema local, el navegador, el operador y la aplicación pueden tener cachés independientes.

Valores razonables de TTL

Situación	Valor típico
registro de producción estable	3600-86400 s
preparación de una migración	300-600 s
registro ACME DNS-01	30-300 s, si el proveedor lo permite
registro NS o SOA	normalmente más largo
conmutación de emergencia	un TTL bajo solo ayuda una vez que ha caducado la caché anterior

Antes de una migración, reduce el TTL con al menos un periodo de TTL antiguo de antelación. Bajar el TTL cinco minutos antes del cambio no elimina las respuestas que el resolver ya ha guardado durante 24 horas.

Una vez terminada la migración, aumenta el TTL para reducir el número de consultas y la dependencia de los problemas puntuales del DNS autoritativo.

3. DNSSEC: integridad de las respuestas, no cifrado

DNSSEC añade autenticación del origen de los datos DNS y protección de la integridad mediante firmas digitales. No cifra las consultas ni oculta los nombres de dominio al proveedor de red o al resolver.

La cadena de confianza utiliza, entre otros:

• DNSKEY - las claves públicas de la zona,
• RRSIG - las firmas de los conjuntos de registros,
• DS - la huella de la clave registrada en la zona superior,
• NSEC o NSEC3 - la confirmación criptográfica de la inexistencia de un nombre o tipo.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

El RFC 9364 define el uso de DNSSEC para autenticar el origen de los datos DNS como una buena práctica actual.

El mayor riesgo de DNSSEC

El problema más frecuente no es la falta de DNSSEC, sino una cadena DNSSEC errónea. Si en el registrador queda un registro DS que apunta a una clave antigua y el nuevo operador DNS firma la zona con otra clave, los resolvers que validan devolverán SERVFAIL.

Una migración segura de DNSSEC requiere:

1. comprobar quién firma la zona,
2. determinar el método de transferencia o de rollover de claves,
3. publicar el DS correcto en el dominio superior,
4. esperar el TTL de los registros DNSKEY y DS,
5. solo entonces eliminar las claves antiguas o la zona antigua,
6. probar mediante resolvers que validan.

No actives DNSSEC si el proveedor no ofrece un proceso claro de gestión de DS y rotación de claves.

4. DNSSEC frente a DoH y DoT

Estos mecanismos resuelven problemas distintos:

Mecanismo	Protege	No proporciona
DNSSEC	autenticidad e integridad de los datos DNS	confidencialidad de la consulta
DNS over TLS	cifrado entre el cliente y el resolver mediante TLS, normalmente el puerto 853	autenticidad de los datos sin validación DNSSEC
DNS over HTTPS	cifrado de DNS sobre HTTPS	autenticidad de los datos sin DNSSEC
DNS normal	resolución básica de nombres	confidencialidad ni integridad criptográfica

DNS over TLS lo describe el RFC 7858, y DNS over HTTPS, el RFC 8484. El transporte cifrado protege la consulta frente a la escucha simple en el tramo cliente-resolver, pero el operador del resolver sigue viendo las consultas y la resolución posterior depende de su política.

5. SSL frente a TLS: terminología correcta

«Certificado SSL» sigue siendo un término de marketing habitual, pero los sitios actuales usan TLS. SSL 2.0 y SSL 3.0 están obsoletos, y TLS 1.0 y 1.1 han sido formalmente retirados por el IETF.

En 2026:

• TLS 1.3 debería ser el preferido,
• TLS 1.2 sigue siendo el mínimo compatible para clientes más antiguos que aún tienen soporte,
• TLS 1.0, TLS 1.1, SSLv2 y SSLv3 deberían estar desactivados,
• la configuración de TLS 1.2 debería usar suites modernas con AEAD y forward secrecy,
• el servidor no debería ofrecer algoritmos ni intercambios de claves obsoletos.

El RFC 9325 contiene las recomendaciones actuales para el uso seguro de TLS y ha sustituido al anterior BCP 195.

6. ¿Qué comprueba el navegador en un certificado?

Durante una conexión TLS, el cliente comprueba, entre otras cosas:

1. si el certificado está dentro de su periodo de validez,
2. si el nombre de host aparece en subjectAltName,
3. si la firma conduce, a través de una cadena intermedia correcta, hasta una root CA de confianza,
4. si el certificado no se está usando para un fin inadecuado,
5. si los parámetros de la conexión son aceptables,
6. si las políticas del navegador no rechazan el certificado.

La identidad del servidor se verifica actualmente a partir del SAN, no del campo Common Name como fuente principal del nombre.

SAN

Un mismo certificado puede cubrir varios nombres:

example.com
www.example.com
api.example.com

Cada nombre debe estar incluido en el SAN.

Wildcard

*.example.com

cubre:

www.example.com
api.example.com
shop.example.com

pero no cubre automáticamente:

example.com
www.eu.example.com

El dominio principal debe añadirse por separado, y el wildcard solo funciona para un único nivel de etiqueta.

SNI

Server Name Indication permite al cliente transmitir el nombre de host durante el handshake, de modo que una misma dirección IP puede servir varios certificados. Una configuración de SNI incorrecta a menudo hace que se muestre el certificado de otro dominio.

Cadena de certificados

El servidor debería enviar el certificado del dominio y los certificados intermedios necesarios, pero normalmente no el root. La falta de un intermediate puede funcionar en un dispositivo que ya guardó el certificado antes y fallar en otro.

7. Validez de los certificados en 2026

El CA/Browser Forum ha adoptado un calendario para acortar los certificados TLS públicos:

Fecha de emisión	Validez máxima
antes del 15 de marzo de 2026	398 días
15 de marzo de 2026 - 14 de marzo de 2027	200 días
15 de marzo de 2027 - 14 de marzo de 2029	100 días
a partir del 15 de marzo de 2029	47 días

Esto no significa que cada CA emita el certificado por el periodo máximo. Let’s Encrypt sigue emitiendo por defecto certificados de 90 días, dispone de certificados opcionales de seis días y de un perfil tlsserver con certificados de 45 días disponible para despliegues tempranos desde mayo de 2026.

La conclusión es sencilla: renovar certificados manualmente deja de ser una práctica operativa razonable.

8. ACME y la automatización de certificados

ACME es un protocolo estándar que automatiza el registro de la cuenta, la validación del control del dominio, y la emisión, renovación y revocación del certificado.

HTTP-01

La CA descarga un archivo:

http://example.com/.well-known/acme-challenge/TOKEN

Ventajas:

• configuración sencilla para un único servidor web,
• automatización fácil,
• no requiere API de DNS.

Limitaciones:

• requiere que el puerto 80 esté accesible,
• no emite wildcard,
• el challenge debe llegar al servidor correcto,
• un AAAA erróneo, un proxy, un redirect o un load balancer pueden interrumpir la validación.

Let’s Encrypt recomienda dejar el puerto 80 abierto para los servidores web públicos y redirigir el tráfico normal a HTTPS.

DNS-01

El cliente publica un TXT:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Ventajas:

• admite wildcard,
• funciona sin un servidor HTTP público,
• resulta adecuado para la gestión centralizada de certificados.

Riesgos:

• requiere un acceso seguro a la API de DNS,
• la propagación y la caché pueden retrasar la validación,
• un token de API con permiso para editar toda la zona aumenta las consecuencias de una fuga,
• los TXT antiguos pueden dificultar el diagnóstico.

Let’s Encrypt recomienda claramente usar DNS-01 con un proveedor que ofrezca API, porque la automatización de las renovaciones es fundamental. Asigna al token el menor alcance posible: preferiblemente solo a los registros _acme-challenge, no a la gestión del dominio, de la cuenta o de todas las zonas.

El wildcard en Let’s Encrypt requiere DNS-01.

TLS-ALPN-01

La validación se realiza mediante una conexión TLS especial en el puerto 443 y el protocolo ALPN. Resulta útil para proxies especializados y sistemas de gestión de certificados, pero se configura manualmente con menos frecuencia.

Renewal Information

Un cliente ACME moderno debería admitir ACME Renewal Information, es decir, ARI. En lugar de renovar cada certificado según un único umbral rígido, el cliente puede recibir de la CA una ventana de renovación sugerida. Let’s Encrypt recomienda consultar la información de ARI al menos dos veces al día.

9. CAA y ACME: ejemplo práctico

Para los certificados de Let’s Encrypt:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Si no quieres wildcard:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Antes de la emisión, una CA pública está obligada a comprobar el CAA. Desde el 15 de marzo de 2026, los requisitos del CA/Browser Forum exigen también la validación DNSSEC para las consultas relacionadas con CAA realizadas desde la perspectiva de red principal, y un error de validación DNSSEC no debe interpretarse como consentimiento para la emisión.

Tras cambiar de CA, recuerda actualizar el CAA antes de iniciar el nuevo proceso de emisión.

10. HTTPS, redirecciones y HSTS

Esquema mínimo:

http://example.com
        ↓ 301 lub 308
https://example.com

Una vez confirmado el funcionamiento completo de HTTPS, se puede añadir:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS indica al navegador que en el futuro use solo HTTPS y que no permita saltarse ciertos errores de certificado.

No empieces con un max-age largo, includeSubDomains y preload si:

• existen subdominios sin HTTPS,
• parte de la infraestructura la gestiona un socio,
• no se ha probado el proceso de renovación,
• no hay monitorización de certificados,
• no se sabe si el servicio antiguo seguirá siendo necesario.

El preload de HSTS coloca la regla en la distribución de los navegadores. Eliminar la entrada puede llevar semanas.

11. Errores de DNS más frecuentes

Registro AAAA erróneo

IPv4 funciona, pero algunos clientes eligen un IPv6 que no funciona. Los síntomas son aleatorios según la red del usuario.

CNAME y otros registros bajo el mismo nombre

El alias entra en conflicto con los registros de dirección, MX o TXT. El panel del proveedor puede bloquear el cambio o generar una zona ambigua.

Delegación NS incoherente

El registrador indica servidores distintos de los de la zona, o uno de los servidores tiene una versión más antigua de los datos.

DS antiguo tras un cambio de DNS

El dominio devuelve SERVFAIL solo en los resolvers que validan DNSSEC.

TTL demasiado bajo de forma permanente

Aumenta el número de consultas y la sensibilidad a la indisponibilidad puntual del DNS, y no garantiza automáticamente un failover rápido.

TTL demasiado alto antes de una migración

Las direcciones antiguas permanecen en la caché durante muchas horas.

Registros TXT abandonados

Los tokens de verificación y de ACME antiguos dificultan la auditoría y aumentan el caos operativo.

Falta de coherencia entre www y apex

example.com y www.example.com apuntan a sistemas distintos, tienen certificados diferentes o crean un bucle de redirecciones.

12. Errores de TLS y de certificados más frecuentes

Certificado caducado

Lo más habitual no es la falta de automatización, sino un automatismo que dejó de funcionar sin ninguna alerta.

El certificado no cubre el host

Un certificado para example.com no protege automáticamente www.example.com.

Cadena incompleta

Falta un certificado intermedio. El problema puede darse solo en dispositivos nuevos o en determinados clientes.

Certificado incorrecto debido a SNI

El reverse proxy tiene un default virtual host incorrecto o el nuevo dominio no se ha añadido a la asignación.

Protocolos y cipher suites antiguos

El servidor sigue ofreciendo TLS 1.0/1.1 o suites antiguas porque la configuración es de hace muchos años.

Falta de coherencia en varias capas

El CDN tiene un certificado público correcto, pero la conexión CDN→origin no está cifrada o no verifica el nombre de host.

Renovación realizada, pero el proceso no recargó el servidor

El nuevo archivo de certificado existe en el disco, pero Nginx, Apache, HAProxy o la aplicación siguen usando el certificado antiguo cargado en memoria.

13. Diagnóstico paso a paso

Registros DNS

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delegación

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

Un SERVFAIL cuando funciona sin validación es una señal clara de un problema de DNSSEC.

Certificado y SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Fechas del certificado

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP y HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Comprueba la redirección, Strict-Transport-Security, el hostname, el estado final y la ausencia de bucles.

También puedes usar el Inspector de DNS y SSL de POLPROG gratuito, que muestra los registros DNS y la información del certificado TLS. Completa la prueba con el Inspector de cabeceras de seguridad, el Estado del sitio web y el artículo Fundamentos de seguridad de aplicaciones web.

14. Monitorización en producción

No monitorices únicamente la página de inicio desde una sola ubicación. Conjunto mínimo:

• la respuesta del DNS autoritativo,
• los registros A, AAAA, CNAME, NS, MX y CAA,
• la validación DNSSEC,
• la disponibilidad sobre IPv4 e IPv6,
• las fechas del certificado,
• la concordancia del SAN,
• la cadena completa,
• TLS 1.2 y TLS 1.3,
• la redirección final HTTP→HTTPS,
• HSTS,
• la respuesta del origin detrás del CDN,
• el funcionamiento de ACME y la última renovación correcta.

Umbrales de alerta del certificado

Para un sistema completamente automático:

Tiempo restante	Reacción
30 días	aviso o control de la tendencia
14 días	alerta que requiere análisis
7 días	incidente operativo
3 días	alerta crítica y escalado
menos de 24 h	fallo inminente

Los umbrales deben ajustarse a la duración del certificado. Para certificados de seis días o de 45 días, la monitorización debe reaccionar mucho antes, de forma proporcional al ciclo de renovación.

15. Lista de comprobación segura de DNS y TLS

Registrador y DNS

• La cuenta del registrador tiene MFA.
• La transferencia del dominio está bloqueada.
• Los datos de contacto y el proceso de recuperación están actualizados.
• Se usan al menos dos servidores DNS autoritativos.
• Los servidores funcionan en redes o ubicaciones distintas.
• La delegación NS en el registrador y en la zona es coherente.
• Los registros A y AAAA apuntan a infraestructura activa.
• IPv6 se monitoriza realmente.
• Los registros MX, SPF, DKIM y DMARC se conservan en las migraciones.
• CAA permite solo las CA utilizadas.
• No hay registros TXT ni tokens de verificación innecesarios.
• El TTL se ha reducido con antelación antes de la migración.
• El TTL se ha aumentado tras la estabilización.
• El acceso a la API de DNS tiene permisos mínimos.

DNSSEC

• El proveedor admite DNSSEC y la rotación de claves.
• El registro DS en el registrador corresponde al DNSKEY activo.
• Los cambios de operador DNS cuentan con un plan de migración de DNSSEC.
• Los DS y claves antiguos se eliminan solo tras la caducidad de la caché.
• El dominio se prueba con un resolver que valida.
• Una alerta detecta SERVFAIL y la caducidad de las firmas.

Certificados

• Los certificados se emiten y renuevan mediante ACME.
• Se ha probado la renovación, no solo la primera emisión.
• El proceso recarga el servidor tras instalar el nuevo certificado.
• Todos los hosts aparecen en el SAN.
• El wildcard se usa de forma consciente.
• La cadena contiene los intermediates correctos.
• La clave privada no sale del sistema correspondiente.
• Los permisos sobre la clave están restringidos.
• Las alertas funcionan con independencia del propio cliente ACME.
• DNS-01 usa un token de API restringido.
• HTTP-01 funciona sobre IPv4 e IPv6.
• Se usa la CA de staging para las pruebas de automatización.

TLS y HTTPS

• TLS 1.3 está activado.
• TLS 1.2 se mantiene solo para la compatibilidad necesaria.
• TLS 1.0, TLS 1.1 y SSL están desactivados.
• El servidor no ofrece cipher suites obsoletas.
• SNI devuelve el certificado correcto para cada host.
• HTTP redirige directamente a HTTPS.
• No hay mixed content.
• HSTS se ha implementado por etapas.
• includeSubDomains es seguro para todo el dominio.
• El preload se ha analizado antes de enviarlo.
• CDN→origin también usa TLS correctamente verificado.

Veredicto

Una buena configuración de DNS y TLS en 2026 se basa en cuatro principios:

1. El DNS debe ser coherente y resistente a nivel operativo.
2. DNSSEC solo debe implementarse con una gestión correcta de DS y de las claves.
3. Los certificados deben gestionarse automáticamente mediante ACME.
4. TLS 1.3, una cadena correcta, la monitorización y HSTS forman parte de un mismo proceso, no son tareas separadas.

El mayor riesgo no es la ausencia del «candado verde» el día del lanzamiento. Es el fallo silencioso unos meses después: un certificado caducado, un registro AAAA desactualizado, un DS abandonado, un token de DNS con permisos excesivos o un automatismo de renovación que nadie monitorizaba.