DNSSEC et SERVFAIL : trouver la cause de l’échec

Un SERVFAIL est un échec de résolution, pas un diagnostic complet. Lorsqu’un domaine fonctionne sur certains réseaux mais échoue sur d’autres, DNSSEC fait partie des pistes : un résolveur validant peut refuser des données que d’autres retournent. Il faut toutefois établir cette cause avant de modifier une zone ou les réglages des clients.

La procédure suivante concerne un domaine public que vous administrez ou dont vous pouvez examiner les données publiques. Les noms en .example et les adresses de documentation sont fictifs. Remplacez-les par les éléments autorisés de votre environnement, sans soumettre de noms internes à des outils publics.

Conserver l’échec avant toute modification

Commencez avec le nom exact et le type de requête concerné. Une application peut échouer sur un sous-domaine ou sur une cible de CNAME alors que le domaine principal répond. Notez l’heure, le résolveur, le réseau client et le statut complet.

Capturez les réponses avec leurs options et sections, sans vous limiter à la présence d’une adresse. Gardez aussi un nom de contrôle connu pour fonctionner sur le même chemin. Si toutes les requêtes échouent, la panne doit être cherchée plus largement avant de cibler une signature particulière.

# Exemples fictifs : résolveur et domaine de documentation
 dig @192.0.2.53 portail.service.example. A +dnssec
 dig @192.0.2.53 portail.service.example. AAAA +dnssec

L’option +dnssec demande les données DNSSEC disponibles. Elle ne transforme pas dig en validateur complet de la chaîne. Un enregistrement RRSIG visible constitue une donnée à examiner, pas une preuve automatique de validation réussie.

Lire les erreurs détaillées du résolveur

Recherchez un diagnostic complémentaire dans la sortie et dans les journaux du résolveur. Les Extended DNS Errors peuvent préciser qu’une signature est expirée, qu’une clé manque ou que les autorités ne sont pas joignables. La RFC 8914 définit ces indications en complément des codes de réponse DNS.

Conservez le numéro et le texte reçus. L’absence de détail ne permet pas d’écarter DNSSEC. Inversement, une indication très précise doit être vérifiée avec la zone et la période concernées, surtout si plusieurs caches ou serveurs intermédiaires interviennent.

Évitez de traduire SERVFAIL en « domaine inexistant ». Si le code est réellement NXDOMAIN, le diagnostic concerne une autre situation. Mélanger ces erreurs dans un tableau de bord conduit à envoyer une panne de validation vers une équipe chargée de corriger des noms mal saisis.

Comparer avec une validation désactivée pour ce test

Sur le même résolveur et à une heure proche, une requête avec le bit Checking Disabled peut aider à isoler l’étape de validation :

# Diagnostic ponctuel, pas une configuration de production
 dig @192.0.2.53 portail.service.example. A +dnssec +cdflag

Si la requête habituelle échoue mais que ce test obtient les données, la validation devient une piste prioritaire. Le guide de dépannage de Google Public DNS utilise cette comparaison pour orienter les échecs DNSSEC. Le résultat ne prouve pas que les données obtenues sont fiables.

Ne naviguez pas vers la destination sur la seule foi de ce test. Conservez les deux sorties, puis revenez aux données de délégation et de signature. Si les deux requêtes échouent, examinez aussi la disponibilité des autorités, la délégation et le transport réseau.

Localiser la rupture de confiance

Pour une zone signée, vérifiez les enregistrements DS publiés par le parent, les DNSKEY publiées par la zone et les signatures des ensembles concernés. La RFC 4035 décrit le traitement de validation et le rôle de ces données dans la chaîne de confiance.

Dans votre investigation, relevez surtout les changements récents : transfert de registrar, migration de DNS, rotation de clés, restauration d’une ancienne zone ou panne du signataire. Demandez la configuration attendue au propriétaire technique et comparez-la aux données réellement servies.

Un exemple fictif : service.example migre vers un nouveau fournisseur DNS. Le parent conserve un DS associé à l’ancienne clé, tandis que les nouvelles autorités publient d’autres DNSKEY. Des clients obtiennent des erreurs après expiration de leurs caches précédents. La correction doit rétablir une chaîne cohérente avec le gestionnaire de zone et le registrar ; changer le résolveur des utilisateurs masquerait le défaut.

Vérifiez également les périodes de validité des signatures et l’heure système du résolveur. Un décalage temporel peut produire un résultat trompeur. Archivez les données exactes avant leur remplacement pour permettre une relecture de l’incident.

Ne pas oublier les autorités et le réseau

Interrogez les autorités séparément depuis un point autorisé. Des réponses différentes peuvent révéler un déploiement incomplet ou un serveur qui conserve une ancienne zone. Notez lequel répond, avec quel ensemble de données et quel numéro de série SOA lorsqu’il est pertinent.

Si les grosses réponses échouent, comparez les comportements UDP et TCP et vérifiez le filtrage du chemin. Une modification simultanée du réseau et de DNSSEC complique le diagnostic : changez une variable à la fois et consignez le résultat attendu avant chaque test.

Un outil public de diagnostic peut représenter la chaîne d’un domaine public. Utilisez son résultat comme une observation supplémentaire, avec son heure et son point de vue. Il ne remplace pas la réponse reçue par les clients affectés ni les journaux du résolveur de l’entreprise.

Valider la réparation sur le chemin initial

Après une correction, répétez la requête initiale avec la validation active. Vérifiez le nom exact, les types affectés et les différents réseaux qui avaient échoué. Gardez les sorties avant et après, ainsi que l’heure de modification et les éventuels caches encore en circulation.

Le résultat attendu est une résolution correctement validée, sans dépendre du test +cdflag. Si une purge est nécessaire pour accélérer une vérification locale, notez-la explicitement. Les autres clients peuvent rester soumis à des caches différents, ce qui demande une surveillance adaptée.

La sécurisation du DNS couvre les mesures de prévention qui suivent l’incident. Pour une investigation liée à une destination suspecte, complétez avec la corrélation des événements DNS et processus.

Enfin, DNSSEC ne certifie pas le contenu d’un site. Vous pouvez consulter un rapport de réputation du domaine pour examiner ce sujet distinct, en conservant une conclusion séparée pour l’intégrité DNS et pour les indices d’abus observés.