Aller au contenu principal

Diagnostic et usages · 4 min

DNSSEC et SERVFAIL : comprendre une résolution DNS qui échoue

Un domaine peut échouer chez un résolveur validant et fonctionner ailleurs. Distinguez validation DNSSEC, panne de DNS et problème de navigateur avant de modifier les réglages.

Relevez le nom exact, le résolveur utilisé et la réponse obtenue. Un SERVFAIL est un indice à examiner, pas la preuve automatique d’un défaut DNSSEC.
Situer un échec de validation DNS ; Relever nom, résolveur et réponse ; Faire contrôler la chaîne de confiance ; Retester le service après correction
Schéma explicatif.
01Intention claireParticuliers et télétravailleurs
4points de contrôleà vérifier avant de choisir.
4réponses FAQclaires, courtes et directement utiles.

Données pratiques

Choisir le prochain contrôle

Repères de diagnostic à adapter au matériel et aux règles du réseau utilisé.

Choisir le prochain contrôle
ObservationCe qu’elle indiqueProchain contrôle
SERVFAIL sur un résolveurÉchec de résolution à préciserConserver la réponse complète
Navigateur et système diffèrentDNS utilisé possiblement différentIdentifier le résolveur effectif
Domaine modifié récemmentChaîne de signature à contrôlerContacter hébergeur et registre
DNS revenu, site toujours bloquéAutre couche de connexionExaminer HTTPS et application

Ces cas orientent les essais ; ils ne remplacent pas la documentation du modèle ou du service.

Comprendre la protection et ses limites

DNSSEC ajoute une vérification de l’origine et de l’intégrité des données DNS. Il ne chiffre pas la consultation et ne remplace pas HTTPS. Un domaine non signé peut aussi être consulté : absence de signature et signature invalide sont deux situations différentes.

Pour un utilisateur, le résultat utile est de savoir si le nom peut être résolu de manière fiable. Pour le gestionnaire du domaine, la chaîne de confiance et la cohérence des signatures doivent être examinées. Un test de débit ne répond à aucune de ces questions.

Comparer des réponses sans changer tout le réseau

Notez le nom complet et l’heure, puis comparez avec un autre appareil utilisant le même DNS. Un navigateur avec DNS chiffré peut interroger un autre résolveur que le système. Documentez cette différence avant de conclure que le Wi-Fi est responsable.

Si vous utilisez un outil DNS, conservez réponse, type de requête et serveur interrogé. Un SERVFAIL peut avoir plusieurs causes. La comparaison avec un autre résolveur sert à localiser le problème ; elle ne prouve pas que celui qui répond a mieux sécurisé la réponse.

Transmettre les bons éléments au gestionnaire

Sur votre propre domaine, vérifiez avec l’hébergeur les clés, signatures et informations publiées chez le bureau d’enregistrement. Une modification incomplète peut interrompre la résolution chez des validateurs. Planifiez les changements et gardez les informations nécessaires à la récupération.

Si le domaine appartient à un tiers, signalez nom, date et réponses observées. Ne désactivez pas durablement une validation pour faire disparaître l’alerte. Évitez de modifier plusieurs paramètres DNS pendant l’intervention : les caches rendraient ensuite les résultats difficiles à interpréter.

Contrôler après correction

Rejouez la requête auprès des résolveurs utilisés avant l’incident et vérifiez le service web ou mail qui dépend du nom. Un résultat DNS correct ne prouve pas que l’application est revenue : elle peut présenter une seconde panne ou un problème de certificat.

Conservez les heures de modification et de retour des réponses. Les durées de cache varient suivant les enregistrements ; n’annoncez pas un délai universel de propagation. Si une panne persiste pour une seule machine, examinez son cache et sa configuration sans effacer tous ses réglages réseau.

Questions fréquentes

DNSSEC chiffre-t-il les noms consultés ?

Non. Il apporte une vérification d’authenticité et d’intégrité ; DoH et DoT répondent à une autre question.

SERVFAIL signifie-t-il toujours signature invalide ?

Non. C’est une réponse d’échec dont la cause doit être recherchée.

Un domaine non signé est-il forcément inaccessible ?

Non. La validation distingue notamment données non signées et données dont la validation échoue.

Faut-il vider tous les caches ?

Commencez par noter les résultats. Un effacement ne corrige pas une erreur de publication du domaine.

Vérification et attribution

Sources, cartes et outils pour vérifier ce guide

Sources consultées le 03/10/2026. Les conditions applicables figurent dans les documents officiels cités.

La sélection dépend du sujet traité : autorité publique, carte de couverture, démarche officielle ou outil de mesure. Une disponibilité, un tarif ou une garantie doit toujours être confirmé dans le contexte exact de l’utilisateur.

Documentation de référence

IETF — principes DNSSEC

Domaine rfc-editor.org

Objectif et limites des extensions de sécurité DNS.

Documentation de référence

IETF — validation DNSSEC

Domaine rfc-editor.org

Traitement des données et validation par les résolveurs.

À lire aussi