Aller au contenu principal

SERVFAIL après activation DNSSEC : diagnostic et correction

Par CaptainDNS
Publié le 25 février 2026

Diagnostic SERVFAIL DNSSEC : arbre de décision pour identifier et corriger la cause d'un SERVFAIL après activation DNSSEC
TL;DR
  • Un SERVFAIL lié à DNSSEC signifie que le résolveur a rejeté la réponse parce qu'un maillon de la chaîne de confiance est cassé
  • Cinq causes couvrent 95 % des cas : DS manquant, DS incorrect, RRSIG expirée, algorithme incompatible, cache périmé
  • Trois commandes dig suffisent pour isoler le problème exact (arbre de décision dans l'article)
  • Chaque scénario inclut la commande de diagnostic, la correction et la vérification post-correction

Vous venez d'activer DNSSEC chez votre registrar. Les premiers tests passent. Puis, quelques heures plus tard, vos utilisateurs signalent que le site est inaccessible. Votre serveur répond, votre configuration DNS est correcte, mais dig retourne SERVFAIL.

Ce SERVFAIL n'est pas un problème de serveur. C'est le résolveur DNS qui refuse de retourner la réponse parce que la validation DNSSEC a échoué. Votre infrastructure fonctionne ; le résolveur la bloque.

Ce guide couvre les cinq scénarios de SERVFAIL liés à DNSSEC, avec pour chacun la commande de diagnostic, la correction exacte et la vérification post-correction.

SERVFAIL et DNSSEC : le mécanisme

Quand un résolveur validant (1.1.1.1, 8.8.8.8, 9.9.9.9) reçoit une réponse DNS pour un domaine signé DNSSEC, il vérifie la chaîne de confiance complète : ancre de confiance, DS record, DNSKEY, RRSIG.

Si une seule vérification échoue, le résolveur marque la réponse comme BOGUS et renvoie SERVFAIL au client. Conséquence directe : le site devient inaccessible pour tous les utilisateurs dont le résolveur valide DNSSEC. Selon les mesures de l'APNIC, cela représente environ 38 % des requêtes DNS mondiales.

Le problème : un SERVFAIL ne dit pas pourquoi la validation a échoué. Le code d'erreur est le même quelle que soit la cause. Il faut diagnostiquer manuellement avec dig.

Diagnostic rapide : trois commandes

Avant d'analyser chaque scénario, voici les trois commandes qui couvrent la majorité des cas. Exécutez-les dans l'ordre : chaque résultat oriente vers un scénario précis.

Commande 1 : vérifier le DS record

dig DS captaindns.com +short

Si la commande ne renvoie rien, il n'y a pas de DS record au TLD. La chaîne de confiance n'est pas établie (voir cause 1).

Commande 2 : comparer DS et DNSKEY

dig DNSKEY captaindns.com +short

Le DS record contient un hash de la KSK (flag 257). Si le hash ne correspond à aucune DNSKEY publiée, le DS est incorrect (voir causes 2 et 4).

Commande 3 : confirmer que DNSSEC est la cause

dig A captaindns.com +dnssec +cd

Le flag +cd (Checking Disabled) demande au résolveur de retourner la réponse sans valider DNSSEC. Si la réponse arrive avec +cd mais pas sans, le problème est confirmé comme lié à DNSSEC.

Les cinq causes de SERVFAIL après DNSSEC

Cause 1 : DS record manquant

Symptôme : dig DS captaindns.com +short ne renvoie rien.

Explication : vous avez signé votre zone (les DNSKEY et RRSIG existent) mais le DS record n'a pas été publié au TLD. Sans DS, le résolveur ne peut pas relier votre zone à la zone parente.

Statut DNSSEC : INSECURE (pas BOGUS). Le résolveur ne valide pas, mais ne bloque pas non plus. Ce cas ne provoque un SERVFAIL que si le résolveur a un ancien DS en cache (configuration précédente ou transfert de domaine).

Correction :

  1. Récupérez le DS record depuis votre fournisseur DNS (Cloudflare, Route 53, OVHcloud)
  2. Ajoutez-le dans l'interface de votre registrar (section DNSSEC)
  3. Attendez la propagation (TTL du DS au TLD, souvent 24-48 h)

Vérification :

dig DS captaindns.com +short
# Doit retourner : Key Tag, Algorithm, Digest Type, Digest

Cause 2 : DS record incorrect

Symptôme : le DS record existe mais le hash ne correspond à aucune KSK publiée.

Explication : le DS au TLD contient un hash qui ne correspond pas à la KSK de votre zone. C'est la cause la plus fréquente de SERVFAIL après activation DNSSEC. Origines courantes :

  • Copier-coller erroné lors de la saisie manuelle du DS
  • Rotation de la KSK sans mise à jour du DS au registrar
  • DS généré avec un mauvais algorithme de hash (SHA-1 au lieu de SHA-256)

Statut DNSSEC : BOGUS. Le résolveur renvoie SERVFAIL.

Diagnostic :

# Récupérer le DS au TLD
dig DS captaindns.com +short
# Exemple : 12345 13 2 ABC123...

# Récupérer les DNSKEY
dig DNSKEY captaindns.com +short
# Chercher la KSK (flag 257)
# Comparer le Key Tag (12345) avec celui du DS

Correction :

  1. Depuis votre fournisseur DNS, générez le DS record correct
  2. Dans l'interface du registrar, supprimez l'ancien DS et ajoutez le nouveau
  3. Si votre registrar supporte CDS/CDNSKEY (RFC 7344), la mise à jour peut être automatique

Vérification :

dig captaindns.com +dnssec | grep flags
# Le flag "ad" (Authenticated Data) doit être présent

Cause 3 : signatures RRSIG expirées

Symptôme : la réponse DNS contient des RRSIG dont la date d'expiration est dépassée.

Explication : chaque signature RRSIG a une durée de validité définie (typiquement 7 à 30 jours). Si les signatures ne sont pas renouvelées avant expiration, les résolveurs les rejettent. Une RRSIG expirée rend le domaine inaccessible aussi surement qu'un DS incorrect.

Statut DNSSEC : BOGUS. SERVFAIL sur tous les enregistrements dont la signature a expiré.

Diagnostic :

dig A captaindns.com +dnssec +cd
# Examiner le champ RRSIG : inception et expiration
# Format : RRSIG A 13 2 300 20260315120000 20260301120000 12345 captaindns.com. ABC...
#                                ^^^^^^^^^^^^^^^^ expiration
#                                                 ^^^^^^^^^^^^^^^^ inception

Comparez la date d'expiration avec la date actuelle (UTC). Si l'expiration est dans le passé, cette cause est confirmée.

Origines courantes :

  • BIND ou PowerDNS autogéré sans renouvellement automatique configuré
  • Erreur dans le cron de re-signature
  • Migration DNS sans transférer les clés de signature

Correction :

  1. Si DNS managé : contactez le support du fournisseur (incident de leur côté)
  2. Si BIND autogéré : relancez la signature avec rndc sign captaindns.com
  3. Si PowerDNS : exécutez pdnsutil rectify-zone captaindns.com

Cause 4 : algorithme incompatible

Symptôme : le DS record spécifie un algorithme différent de celui utilisé par la DNSKEY.

Explication : le DS record indique par exemple l'algorithme 8 (RSA/SHA-256) alors que la DNSKEY utilise l'algorithme 13 (ECDSA P-256). Le résolveur ne peut pas vérifier la correspondance. Ce cas survient typiquement après une migration vers un nouveau fournisseur DNS qui utilise un algorithme différent.

Statut DNSSEC : BOGUS. SERVFAIL.

Diagnostic :

# Vérifier l'algorithme du DS
dig DS captaindns.com +short
# Format : KeyTag Algorithm DigestType Digest
# Exemple : 12345 8 2 ABC...  (algorithme 8 = RSA/SHA-256)

# Vérifier l'algorithme de la DNSKEY
dig DNSKEY captaindns.com +short
# Format : Flags Protocol Algorithm PublicKey
# Exemple : 257 3 13 ABC...  (algorithme 13 = ECDSA P-256)

Si les numéros d'algorithme diffèrent entre DS et DNSKEY (flag 257), la cause est confirmée.

Correction :

  1. Régénérez le DS record depuis votre fournisseur DNS (il utilisera le bon algorithme)
  2. Mettez à jour le DS au registrar
  3. Attendez la propagation (vérifiez le TTL du DS au TLD)

Cause 5 : cache du résolveur (faux SERVFAIL)

Symptôme : SERVFAIL intermittent. Certains résolveurs retournent SERVFAIL, d'autres non.

Explication : le résolveur a mis en cache un ancien DS record ou une ancienne DNSKEY. Après une modification DNSSEC (activation, rotation de clé, changement de fournisseur DNS), le cache du résolveur peut contenir des données incohérentes avec l'état actuel de la zone.

Diagnostic :

# Tester avec plusieurs résolveurs
dig A captaindns.com @1.1.1.1 +dnssec
dig A captaindns.com @8.8.8.8 +dnssec
dig A captaindns.com @9.9.9.9 +dnssec

Si certains résolveurs fonctionnent et d'autres non, le cache est en cause. Ce n'est pas un problème de configuration mais de timing.

Correction :

  1. Attendez l'expiration du TTL (vérifiez le TTL du DS record au TLD)
  2. Purgez le cache des résolveurs publics si possible :

Prévention : avant toute modification DNSSEC, baissez le TTL du DS record 24 h à l'avance (si votre registrar le permet).

Arbre de décision SERVFAIL DNSSEC : identifier la cause en trois commandes dig

Prévenir les SERVFAIL DNSSEC

Trois pratiques réduisent le risque de casse. Aucune n'est complexe ; chacune élimine une catégorie entière de causes.

DNS managé plutôt qu'autogéré

Les fournisseurs DNS managés (Cloudflare, Route 53, OVHcloud, Google Cloud DNS) gèrent la signature automatiquement : rotation des clés, renouvellement des RRSIG, publication du DS via CDS/CDNSKEY. Avec un DNS managé, les causes 3 (RRSIG expirée) et 4 (algorithme) disparaissent.

Double DS pendant les transitions

Lors d'une rotation de KSK, publiez les deux DS records (ancien + nouveau) au registrar. Attendez la propagation complète du nouveau DS avant de supprimer l'ancien. Règle : ne jamais supprimer un DS avant d'avoir confirmé que son remplaçant est propagé sur tous les résolveurs testés.

Surveillance continue

Vérifiez régulièrement la propagation DNS de votre configuration DNSSEC. Un DS incorrect ou une signature expirée peuvent survenir silencieusement, surtout après un transfert de domaine ou une migration de fournisseur. Une alerte automatique sur le statut DNSSEC de votre domaine détecte un problème avant que vos utilisateurs le signalent.

Processus de correction SERVFAIL DNSSEC : de la détection à la vérification post-correction

Plan d'action en cas de SERVFAIL

  1. Confirmer que DNSSEC est la cause : exécutez dig captaindns.com +cd. Si la réponse arrive avec +cd mais pas sans, DNSSEC est en cause
  2. Identifier le maillon cassé : vérifiez DS, DNSKEY et RRSIG avec les trois commandes de diagnostic ci-dessus
  3. Appliquer la correction : suivez le scénario correspondant parmi les cinq causes détaillées dans cet article
  4. Vérifier la réparation : attendez l'expiration du TTL puis confirmez que le flag ad est présent avec dig captaindns.com +dnssec
  5. Documenter l'incident : notez la cause racine, la correction appliquée et le temps de résolution pour accélérer le diagnostic futur

Lancez un diagnostic DNSSEC complet de votre domaine pour vérifier que chaque maillon de la chaîne de confiance est en place.

Guides DNSSEC connexes

FAQ

Qu'est-ce qu'un SERVFAIL DNS ?

SERVFAIL (Server Failure, RCODE 2) est un code de réponse DNS indiquant que le résolveur n'a pas pu obtenir une réponse valide. Dans le contexte DNSSEC, un SERVFAIL signifie que la validation cryptographique a échoué : le résolveur a rejeté la réponse parce qu'un maillon de la chaîne de confiance est invalide ou manquant.

Quelle est la différence entre SERVFAIL et NXDOMAIN ?

NXDOMAIN signifie que le domaine n'existe pas. SERVFAIL signifie que le domaine existe probablement, mais le résolveur n'a pas pu valider la réponse. Avec DNSSEC, un SERVFAIL indique un problème de validation (DS incorrect, signature expirée), pas un domaine inexistant.

Comment savoir si un SERVFAIL est causé par DNSSEC ?

Utilisez le flag +cd (Checking Disabled) dans votre commande dig : dig captaindns.com +cd. Si la réponse arrive avec +cd mais pas sans, DNSSEC est la cause du SERVFAIL. Sans +cd, le résolveur valide DNSSEC et bloque la réponse.

Combien de temps faut-il pour corriger un SERVFAIL DNSSEC ?

La correction elle-même prend quelques minutes (ajout ou modification du DS record au registrar). La propagation prend de 1 à 48 heures selon le TTL du DS record au TLD. Pendant la propagation, les résolveurs ayant l'ancienne valeur en cache continueront à renvoyer SERVFAIL. Purger le cache des résolveurs publics (Google, Cloudflare) peut accélérer la résolution.

Faut-il désactiver DNSSEC en urgence si SERVFAIL ?

Non. Désactiver DNSSEC en urgence (supprimer le DS record sans désactiver la signature de zone) peut aggraver le problème car la zone reste signée. Identifiez d'abord la cause exacte avec les commandes de diagnostic. Si le DS record est incorrect, corrigez-le. Ne désactivez DNSSEC que si vous n'arrivez pas à identifier la cause et que le site est critique, en supprimant d'abord le DS au registrar puis en désactivant la signature de zone.

Pourquoi le SERVFAIL n'affecte-t-il pas tous les utilisateurs ?

Seuls les résolveurs validants (qui vérifient DNSSEC) retournent SERVFAIL. Les résolveurs non validants ignorent les signatures et retournent la réponse normalement. De plus, les résolveurs qui ont encore l'ancienne réponse en cache peuvent continuer à fonctionner jusqu'à expiration du TTL.

Comment vérifier que la correction DNSSEC a fonctionné ?

Exécutez dig captaindns.com +dnssec | grep flags. Si le flag ad (Authenticated Data) est présent, la chaîne de confiance est validée. Testez avec plusieurs résolveurs (1.1.1.1, 8.8.8.8, 9.9.9.9) pour confirmer que la propagation est complète.

Le DNS managé élimine-t-il le risque de SERVFAIL DNSSEC ?

Presque entièrement. Les fournisseurs DNS managés (Cloudflare, Route 53, OVHcloud) gèrent automatiquement la signature, la rotation des clés et le renouvellement des RRSIG. Le seul risque restant est un DS record incorrect au registrar, ce qui peut arriver lors de la configuration initiale ou d'un transfert de domaine.

Glossaire

  • SERVFAIL : code de réponse DNS (RCODE 2) indiquant que le résolveur n'a pas pu compléter la requête. En contexte DNSSEC, il signale que la validation cryptographique a échoué.
  • BOGUS : état interne du résolveur quand la validation DNSSEC échoue. Un domaine marqué BOGUS provoque un SERVFAIL pour l'utilisateur final.
  • INSECURE : état d'un domaine dont la zone est signée mais sans DS record au TLD. Le résolveur ne valide pas DNSSEC mais ne bloque pas la résolution.
  • DS record : enregistrement publié au TLD contenant un hash de la KSK. C'est le maillon qui relie une zone signée à sa zone parente dans la chaîne de confiance.
  • RRSIG : signature cryptographique d'un enregistrement DNS, avec une date d'inception et une date d'expiration. Passé la date d'expiration, la signature est rejetée.
  • +cd (Checking Disabled) : flag dig qui désactive la validation DNSSEC au résolveur. Indispensable pour distinguer un SERVFAIL lié à DNSSEC d'un SERVFAIL d'une autre origine.

Sources

Articles similaires