Solución de problemas de verificación de DNS

Cuando añades un dominio personalizado, Elido consulta el DNS cada 30 segundos para buscar los registros que te pedimos crear. Normalmente, la verificación se completa en 60 segundos. Cuando tarda más, esta lista de verificación cubre lo que casi siempre está mal.

Confirma que los registros existen desde fuera de tu red#

La primera verificación es si los registros son visibles públicamente, no solo en tu registrador.

dig links.acme.com CNAME +short
# expected: <something>.elido.me.

Para un dominio apex:

dig acme.link A +short
# expected: 2 A records (Hetzner FRA + OVH FRA)

dig acme.link AAAA +short
# expected: IPv6 from one of those PoPs

Si dig no devuelve nada, el registrador aún no ha propagado — o, más a menudo, el registro se guardó con un error tipográfico.

Patrones de errores tipográficos comunes#

Compara el valor del registro con el valor exacto que Elido te mostró en Settings → Domains → [domain] → DNS records. Los errores más comunes:

Punto final. Algunos registradores requieren <target>.elido.me. (con el punto final); algunos lo añaden automáticamente. Pegar <target>.elido.me. en un registrador que lo añade automáticamente resulta en <target>.elido.me.. — inválido. Intenta sin el punto final.
Hostname en lugar de FQDN en el campo Nombre. Para links.acme.com, algunos registradores quieren links en el campo Nombre, no links.acme.com. Si escribiste el FQDN completo, en realidad creaste links.acme.com.acme.com.
Tipo de registro incorrecto. Un subdominio necesita CNAME. Un apex necesita A (o ALIAS). Si tu registrador no admite la resolución de CNAME en el apex, cambia a registros A — ofrecemos ambas opciones en el panel de instrucciones de DNS.

Dominios Apex (raíz de zona)#

Los CNAME en el apex están prohibidos por la especificación de DNS. Si estás intentando acme.link (no links.acme.com), tienes tres opciones:

Usa los dos registros A que proporcionamos. Funciona en todas partes.
Usa ALIAS / ANAME si tu registrador lo admite (Cloudflare, DNSimple, easyDNS). Se resuelve automáticamente a los registros A correctos.
Elige un subdominio en su lugar. go.acme.com o links.acme.link es más fácil y amigable para CDN que el apex.

Proxy de Cloudflare (nube naranja)#

Si tu dominio está detrás del proxy de Cloudflare (nube naranja activada), la verificación de DNS sigue funcionando, pero el aprovisionamiento de TLS falla. Cloudflare termina el TLS por sí mismo, por lo que nuestro Caddy nunca ve al visitante y no puede emitir un certificado.

Desactiva la nube naranja (off) (solo DNS / nube gris). Cloudflare servirá solo como DNS autoritativo; nosotros manejamos el proxy.

Si realmente necesitas la capa DDoS de Cloudflare al frente, usa el certificado Origin CA de Cloudflare y súbelo a Elido en Settings → Domains → [domain] → Custom certificate.

Registros CAA#

Si tu dominio tiene registros CAA, deben permitir Let's Encrypt:

dig acme.link CAA +short
# if the result has any lines, letsencrypt.org must be one of them

Si ves 0 issue "letsencrypt.org" en la salida, estás bien. Si solo ves registros CAA para otras CAs, añade uno para Let's Encrypt:

acme.link.    CAA  0 issue "letsencrypt.org"

Discrepancia de DNSSEC#

Si tu registrador tiene DNSSEC habilitado pero los registros DS no se publicaron correctamente, los resolvers públicos devolverán SERVFAIL en lugar de tus registros. Ejecuta:

dig +trace links.acme.com

Si el seguimiento termina en SERVFAIL, corrige DNSSEC en tu registrador antes de continuar — generalmente deshabilitando DNSSEC, esperando una hora y volviendo a habilitar con los registros DS correctos.

Cadencia de sondeo de verificación#

Sondeamos DNS cada 30 segundos durante la primera hora después de añadir el dominio, luego cada 5 minutos durante las siguientes 24 horas, y después cada hora. Puedes hacer clic en Verify now en cualquier momento para forzar una verificación inmediata.

Si tu dominio permanece Pendiente durante 24 horas y dig desde fuera de tu red muestra los registros correctos, haz clic en Verify now una vez — a veces nuestro resultado negativo en caché de una propagación anterior persiste.

Cómo se ve "verificado pero sin TLS"#

Si el DNS está verificado pero el dominio muestra "TLS pending" durante más de 10 minutos, Caddy está teniendo problemas con Let's Encrypt. Causas:

Registros CAA (ver arriba).
Limitación de velocidad de Let's Encrypt (50 certs/semana/dominio-registrado). Esto solo ocurre en implementaciones de muy alto volumen.
Desafío TLS-ALPN bloqueado por un firewall upstream. Abre el puerto 443 a nuestras IPs de entrada (listadas en nuestra página de confianza).

Solución de problemas#

La verificación funciona desde mi laptop pero no desde el dashboard. Tu laptop está usando tu resolver DNS local; nuestro verificador usa resolvers públicos (1.1.1.1, 8.8.8.8). Si tu registrador no ha propagado globalmente, los resolvers públicos podrían no ver el registro aún. Usa dig @1.1.1.1 links.acme.com para confirmar lo que vemos.
Los registros parecen correctos pero la verificación sigue fallando. Reduce el TTL de los registros a 300 segundos y espera 10 minutos. Los TTLs altos hacen que el almacenamiento en caché negativo sea problemático.
La resolución de CNAME en el apex estaba habilitada pero la verificación falló. Cloudflare resuelve en tiempo de consulta, pero solo para consultas a través de los resolvers de Cloudflare. Los resolvers públicos ven el CNAME y lo rechazan. Cambia explícitamente a registros A.