DNSSEC et SERVFAIL : vérifier la chaîne de confiance sans couper le domaine

Votre domaine répond sur un serveur DNS mais renvoie SERVFAIL chez certains visiteurs. Avant de modifier son adresse IP, vérifiez si un résolveur rejette sa chaîne DNSSEC. La documentation de dépannage Cloudflare permet de distinguer cette panne d’un problème Web.

Intention de recherche : diagnostiquer une validation DNSSEC défaillante, puis activer ou rétablir une chaîne cohérente. Les noms de cet exercice sont fictifs.

1. Identifier le maillon défaillant

DNSSEC authentifie les données DNS ; il ne chiffre pas les requêtes. Le DNS autoritatif publie des clés publiques DNSKEY et des signatures RRSIG. Le DS, publié dans la zone parente via le registrar, référence une clé de la zone enfant. La validation remonte jusqu’à une ancre de confiance.

Relevez d’abord les NS et le DS existants, sans rien désactiver :

Remplacez le NS fictif par chacun de vos serveurs. Une RRSIG indique une signature présente, pas sa validité : dig +dnssec demande ces données, sans effectuer lui-même une validation complète.

Si la requête normale échoue et celle avec +cdflag reçoit une réponse, suspectez DNSSEC. Ce drapeau désactive le contrôle pour cette requête : il sert au diagnostic, jamais de correction permanente. Un SERVFAIL peut aussi provenir d’un serveur indisponible.

Exemple à interpréter

Une zone fictive retourne example.com. 300 IN A 192.0.2.40 avec une RRSIG, mais le parent conserve le DS de l’ancien fournisseur. La signature peut être présente et la chaîne néanmoins cassée. Comparez le DS complet fourni par l’opérateur : identifiant de clé, algorithme, type d’empreinte et empreinte. Ne fabriquez pas ces valeurs à partir de cet exemple.

2. Activer ou réparer dans le bon ordre

Risque : publier un mauvais DS ou arrêter la signature alors qu’un DS reste actif peut rendre le site et les e-mails inaccessibles aux résolveurs validateurs.

1. Sauvegardez les paramètres DNSSEC, les NS et les TTL observés. Confirmez l’accès au registrar et au fournisseur DNS.
2. Pour une nouvelle activation, activez d’abord la signature chez le DNS autoritatif. Vérifiez DNSKEY et RRSIG sur tous ses NS.
3. Publiez ensuite exactement le DS fourni, dans l’interface DNSSEC du registrar, et non comme simple entrée de la zone enfant.
4. Pour une panne, comparez la clé attendue au DS parent et vérifiez les dates des signatures. Faites corriger une signature expirée ou absente par le fournisseur ; restaurez la clé encore référencée si cette option est maîtrisée.
5. Contrôlez la validation depuis deux résolveurs et documentez l’heure du changement. Évitez de combiner activation et migration des NS.

Retour arrière

Privilégiez le rétablissement d’une chaîne signée valide. Si un retrait de DNSSEC est nécessaire, retirez le DS au registrar tout en maintenant la zone signée ; attendez la disparition du DS parent et l’expiration de ses caches avant d’arrêter la signature. Cette transition retire une protection et n’efface pas instantanément une panne déjà en cache.

3. Vérification finale

Pour une zone signée correctement validée, recherchez NOERROR et ad dans la réponse d’un résolveur validateur de confiance. Confirmez aussi la chaîne dans DNSViz. L’absence de ad seule ne prouve pas une falsification.

Erreurs courantes

Ne confondez pas aa (autoritatif) et ad (données authentifiées). Un DS ancien après migration, une RRSIG expirée ou une clé supprimée prématurément sont des pistes concrètes. Désactiver la validation chez le client masque le symptôme et affaiblit sa protection.

Sources : Cloudflare, dépannage DNSSEC, ISC, options de diagnostic BIND.