Résolution des problèmes de vérification DNS

Lorsque vous ajoutez un domaine personnalisé, Elido interroge le DNS toutes les 30 secondes pour rechercher les enregistrements que nous vous avons demandé de créer. En général, la vérification se termine dans les 60 secondes. Lorsque cela prend plus de temps, cette liste de contrôle couvre ce qui est presque toujours en cause.

Confirmez que les enregistrements existent depuis l'extérieur de votre réseau#

La première vérification est de savoir si les enregistrements sont visibles publiquement, pas seulement chez votre registrar.

dig links.acme.com CNAME +short
# attendu : <quelque chose>.elido.me.

Pour un domaine apex :

dig acme.link A +short
# attendu : 2 enregistrements A (Hetzner FRA + OVH FRA)

dig acme.link AAAA +short
# attendu : IPv6 de l'un de ces PoPs

Si dig ne retourne rien, le registrar n'a pas encore propagé — ou, plus souvent, l'enregistrement a été sauvegardé avec une faute de frappe.

Patterns de fautes de frappe courants#

Comparez la valeur de l'enregistrement avec la valeur exacte qu'Elido vous a montrée dans Paramètres → Domaines → [domaine] → Enregistrements DNS. Les erreurs les plus courantes :

Point final. Certains registrars exigent <cible>.elido.me. (avec le point final) ; certains l'ajoutent automatiquement. Coller <cible>.elido.me. dans un registrar qui l'ajoute automatiquement donne <cible>.elido.me.. — invalide. Essayez sans le point final.
Nom d'hôte au lieu de FQDN dans le champ Nom. Pour links.acme.com, certains registrars veulent links dans le champ Nom, pas links.acme.com. Si vous avez tapé le FQDN complet, vous avez en fait créé links.acme.com.acme.com.
Mauvais type d'enregistrement. Un sous-domaine a besoin de CNAME. Un apex a besoin de A (ou ALIAS). Si votre registrar ne supporte pas le flattening CNAME apex, passez aux enregistrements A — nous fournissons les deux options dans le panneau d'instructions DNS.

Domaines apex (racine de zone)#

Les CNAMEs à l'apex sont interdits par la spécification DNS. Si vous essayez acme.link (pas links.acme.com), vous avez trois options :

Utilisez les deux enregistrements A que nous fournissons. Fonctionne partout.
Utilisez ALIAS / ANAME si votre registrar le supporte (Cloudflare, DNSimple, easyDNS). Cela se résout automatiquement aux bons enregistrements A.
Choisissez plutôt un sous-domaine. go.acme.com ou links.acme.link est plus simple et plus compatible CDN que l'apex.

Proxy Cloudflare (nuage orange)#

Si votre domaine est derrière le proxy Cloudflare (nuage orange activé), la vérification DNS fonctionne toujours mais le provisionnement TLS échoue. Cloudflare termine lui-même le TLS, donc notre Caddy ne voit jamais le visiteur et ne peut pas émettre de certificat.

Désactivez le nuage orange (DNS uniquement / nuage gris). Cloudflare servira uniquement de DNS autoritatif ; nous gérons le proxy.

Si vous avez vraiment besoin de la couche DDoS de Cloudflare devant, utilisez le certificat Origin CA de Cloudflare et chargez-le dans Elido sous Paramètres → Domaines → [domaine] → Certificat personnalisé.

Enregistrements CAA#

Si votre domaine a des enregistrements CAA, ils doivent autoriser Let's Encrypt :

dig acme.link CAA +short
# si le résultat contient des lignes, letsencrypt.org doit en être une

Si vous voyez 0 issue "letsencrypt.org" dans la sortie, vous êtes tranquille. Si vous voyez des enregistrements CAA pour d'autres CAs seulement, ajoutez-en un pour Let's Encrypt :

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

Incohérence DNSSEC#

Si votre registrar a activé DNSSEC mais que les enregistrements DS n'ont pas été publiés correctement, les résolveurs publics renverront SERVFAIL au lieu de vos enregistrements. Exécutez :

dig +trace links.acme.com

Si la trace se termine par SERVFAIL, corrigez DNSSEC chez votre registrar avant de continuer — généralement en désactivant DNSSEC, en attendant une heure, et en le réactivant avec les bons enregistrements DS.

Cadence de polling de vérification#

Nous interrogeons le DNS toutes les 30 secondes pendant la première heure après que vous avez ajouté le domaine, puis toutes les 5 minutes pendant les 24 heures suivantes, puis toutes les heures. Vous pouvez cliquer sur Vérifier maintenant à tout moment pour forcer une vérification immédiate.

Si votre domaine reste En attente pendant 24 heures et que dig depuis l'extérieur de votre réseau montre les bons enregistrements, cliquez une fois sur Vérifier maintenant — parfois notre résultat négatif mis en cache de la propagation antérieure persiste.

À quoi ressemble « vérifié mais sans TLS »#

Si le DNS est vérifié mais que le domaine affiche « TLS en attente » pendant plus de 10 minutes, Caddy a des difficultés avec Let's Encrypt. Causes :

Enregistrements CAA (voir ci-dessus).
Limitation de débit de Let's Encrypt (50 certificats/semaine/domaine enregistré). Ne se produit que lors de déploiements à très grand volume.
Challenge TLS-ALPN bloqué par un pare-feu en amont. Ouvrez le port 443 vers nos IPs d'ingress (listées sur notre page de confiance).

Résolution des problèmes#

La vérification fonctionne depuis mon ordinateur mais pas depuis le tableau de bord. Votre ordinateur utilise votre résolveur DNS local ; notre vérificateur utilise des résolveurs publics (1.1.1.1, 8.8.8.8). Si votre registrar n'a pas encore propagé globalement, les résolveurs publics peuvent ne pas encore voir l'enregistrement. Utilisez dig @1.1.1.1 links.acme.com pour confirmer ce que nous voyons.

Les enregistrements semblent corrects mais Vérifier échoue continuellement. Abaissez le TTL des enregistrements à 300 secondes et attendez 10 minutes. Les TTL élevés rendent la mise en cache négative pénible.

Le flattening CNAME apex était activé mais la vérification a échoué. Cloudflare effectue le flattening au moment de la requête, mais seulement pour les requêtes via les résolveurs Cloudflare. Les résolveurs publics voient le CNAME et rejettent. Passez explicitement aux enregistrements A.