Un SERVFAIL qui apparaît après l'activation de DNSSEC ou après un changement d'hébergeur DNS signifie presque toujours que la chaîne de confiance est cassée : l'enregistrement DS publié par le registrar ne correspond plus à la clé de la zone. Pour le confirmer, comparez dig votre-domaine.fr et dig +cd votre-domaine.fr sur un résolveur validant : si la seconde commande répond normalement, c'est DNSSEC. La correction la plus rapide consiste à supprimer le DS chez le registrar, puis à le republier avec la bonne clé.
Pendant la panne, votre site et vos emails sont injoignables pour tous les internautes qui passent par un résolveur validant (Google Public DNS, Cloudflare 1.1.1.1, Quad9 et de nombreux résolveurs de FAI). D'autres, dont le résolveur ne valide pas, n'ont aucun problème. C'est ce qui rend ce type de panne difficile à repérer.
Étape 1 : confirmer que c'est DNSSEC
Interrogez un résolveur validant, sans puis avec l'option +cd (checking disabled), qui désactive la vérification des signatures :
dig @1.1.1.1 votre-domaine.fr A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37080
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
dig @1.1.1.1 +cd votre-domaine.fr A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35118
;; ANSWER SECTION:
votre-domaine.fr. 300 IN A 203.0.113.10
Lecture :
- SERVFAIL sans
+cd, réponse correcte avec +cd : la zone répond, mais la validation DNSSEC échoue. C'est le cas traité ici.
- SERVFAIL dans les deux cas : le problème est ailleurs (serveurs faisant autorité injoignables, délégation cassée, zone absente).
Cette méthode est celle que recommande Cloudflare dans sa documentation de dépannage DNSSEC. Si la lecture d'une sortie dig vous est peu familière, voir notre tutoriel ligne par ligne.
Étape 2 : lire le code d'erreur étendu
Les résolveurs récents joignent à leur SERVFAIL un code d'erreur étendu (Extended DNS Error, RFC 8914). Une version récente de dig l'affiche dans la section OPT PSEUDOSECTION. Les versions plus anciennes, comme celle livrée avec macOS, affichent seulement le texte brut. Exemple réel obtenu sur un domaine de test au DNSSEC cassé :
; OPT=15: 00 09 ... ("..no SEP matching the DS found for brokendnssec.net.")
L'API DNS-over-HTTPS de Google Public DNS renvoie le même diagnostic en JSON :
curl -s "https://dns.google/resolve?name=votre-domaine.fr&type=A"
| Code EDE | Nom | Cause la plus probable |
|---|
| 9 | DNSKEY Missing | Le DS pointe vers une clé que la zone ne publie pas : DS orphelin ou mauvaise clé transmise |
| 10 | RRSIGs Missing | La zone n'est plus signée, ou l'un des serveurs faisant autorité sert une version non signée |
| 7 | Signature Expired | Les signatures n'ont pas été renouvelées (signature manuelle, serveur de signature arrêté) |
| 6 | DNSSEC Bogus | Validation impossible pour une autre raison : signature invalide, données incohérentes |
| 1 ou 2 | Unsupported DNSKEY Algorithm / DS Digest Type | Algorithme non pris en charge par le résolveur (le domaine est alors traité comme non signé, pas en SERVFAIL) |
Étape 3 : comparer le DS et la DNSKEY
Récupérez le DS publié dans la zone parente et les clés publiées par votre zone :
dig +short DS votre-domaine.fr
2371 8 2 173EA96867879929EEEB7C6D245D2472C266043EB596370AEBC7D2CC A43EE84F
dig +short DNSKEY votre-domaine.fr
(aucune réponse)
Le premier champ du DS (2371) est le key tag de la clé attendue, le deuxième (8) son algorithme. Il doit exister une DNSKEY avec le drapeau 257, le même algorithme et le même key tag. Ici, la zone ne publie aucune clé : le DS est orphelin. Les résolveurs validants attendent une zone signée et refusent toute réponse non signée.
Pour une vue graphique de toute la chaîne (racine, extension, domaine), analysez le domaine sur DNSViz (dnsviz.net). Les liens en rouge montrent exactement où la chaîne se rompt. Le Verisign DNSSEC Debugger donne un diagnostic texte équivalent.
Les quatre causes fréquentes et leur correction
1. DS orphelin après un changement d'hébergeur DNS
C'est de loin la cause la plus courante. Vous passez vos DNS d'OVHcloud à Cloudflare (ou l'inverse), mais l'ancien DS reste chez le registrar. La nouvelle zone n'est pas signée, ou signée avec une autre clé. Cloudflare le résume : le problème survient souvent quand les serveurs faisant autorité changent sans que les enregistrements DS soient mis à jour.
Correction : supprimez le DS chez le registrar. La résolution revient dès que le TTL du DS a expiré dans les caches. Réactivez ensuite DNSSEC chez le nouvel hébergeur DNS et publiez le nouveau DS.
2. Mauvaise clé transmise au registrar
Erreur de copie, clé de zone (drapeau 256) au lieu de la clé de signature de clés (257), mauvais algorithme, ou condensat SHA-1 alors que le registrar attend SHA-256.
Correction : supprimez le DS erroné et saisissez à nouveau les valeurs exactes fournies par l'hébergeur DNS. Chez OVHcloud, les quatre champs à remplir (Key Tag, Flag, Algorithme, Clé publique) sont décrits dans notre guide activer DNSSEC chez OVH.
3. Zone partiellement signée
Plusieurs fournisseurs DNS servent la même zone, mais un seul la signe. Ou un serveur secondaire n'a pas reçu la version signée. Selon le serveur interrogé, la réponse valide ou non. Le symptôme est intermittent.
Correction : interrogez chaque serveur faisant autorité avec dig @ns1.fournisseur.net +dnssec votre-domaine.fr A et vérifiez la présence d'un RRSIG sur chacun. Retirez le serveur non signé de la délégation ou configurez la signature multi-fournisseur.
4. Signatures expirées
Fréquent quand la zone est signée par vos propres outils (BIND, Knot, PowerDNS) et que la re-signature automatique s'arrête. Les signatures RRSIG ont une date de fin de validité.
Correction : relancez la signature de la zone, puis vérifiez les dates d'expiration des RRSIG avec dig +dnssec votre-domaine.fr SOA.
Combien de temps avant le retour à la normale
Une fois la correction faite, les résolveurs doivent oublier l'ancien DS. Le délai dépend du TTL de cet enregistrement dans la zone parente. Nous avons relevé :
| Zone parente | TTL du DS mesuré |
|---|
.fr | 3 600 secondes (1 heure) |
.com | 86 400 secondes (24 heures) |
Vous pouvez accélérer le retour chez deux grands résolveurs publics : Google Public DNS et Cloudflare proposent chacun une page de purge de cache pour un nom donné (« Flush Cache » chez Google, « Purge Cache » sur 1.1.1.1). Les résolveurs des FAI suivront au rythme du TTL.
Pour désactiver DNSSEC proprement, l'ordre compte : supprimez d'abord le DS chez le registrar, puis attendez avant de retirer les clés de la zone. Cloudflare recommande d'attendre au moins 1,5 fois le TTL du DS, soit 36 heures pour un TTL de 24 heures.
Éviter le prochain SERVFAIL
- Avant toute migration DNS, retirez le DS, attendez son TTL, migrez, puis réactivez. La procédure générale est dans notre guide pour activer DNSSEC selon votre registrar.
- Après chaque activation, vérifiez le drapeau
ad avec dig @1.1.1.1 votre-domaine.fr A.
- Testez depuis plusieurs résolveurs validants, pas seulement celui de votre box.
- Contrôlez régulièrement DS et DNSKEY avec notre DNS Lookup.
Domains Defender surveille DNSSEC dans la configuration de vos domaines et vous alerte si elle se dégrade, ainsi qu'à chaque changement d'enregistrement NS. Un changement de NS non accompagné d'une mise à jour du DS est justement le scénario qui provoque ces pannes. Voir les plans.
Questions fréquentes
Pourquoi mon site marche chez moi mais pas chez certains clients ?
Votre résolveur ne valide sans doute pas DNSSEC, contrairement à celui de vos clients. Testez avec dig @1.1.1.1 ou dig @8.8.8.8 : ce sont des résolveurs validants.
Que signifie l'option +cd de dig ?
Checking Disabled : elle demande au résolveur de ne pas vérifier les signatures DNSSEC. Si la réponse revient avec +cd et pas sans, la panne vient de DNSSEC.
Faut-il désactiver DNSSEC pour corriger un SERVFAIL ?
Supprimer le DS chez le registrar rétablit la résolution le plus vite, une fois son TTL écoulé. Ce n'est pas une fin en soi : republiez ensuite un DS correct pour retrouver la protection.
Combien de temps dure un SERVFAIL DNSSEC après correction ?
Le temps que le TTL du DS expire dans les caches : de l'ordre d'une heure pour un .fr, jusqu'à 24 heures pour un .com, d'après nos relevés.