Un site qui ne charge plus, des e-mails qui disparaissent dans le vide, un outil SaaS qui refuse de valider le domaine : dans la majorité des cas, le problème se situe au niveau de la résolution DNS. Avant de contacter l’hébergeur ou de soupçonner une panne serveur, on gagne du temps en vérifiant que le DNS est ok.
Ce guide détaille les vérifications concrètes à mener et les réglages qui font la différence sur la fiabilité et la sécurité de vos serveurs DNS.
Diagnostiquer un problème DNS avant de toucher à la configuration
Sur le terrain, le réflexe classique consiste à lancer un ping vers le nom de domaine depuis un terminal. Si le ping échoue mais qu’un ping vers l’adresse IP du serveur fonctionne, le problème est bien côté résolution DNS, pas côté réseau.
Deux outils en ligne de commande couvrent la plupart des situations. nslookup interroge un serveur DNS précis pour vérifier qu’un enregistrement existe et pointe au bon endroit. dig (disponible nativement sous Linux et macOS, installable sous Windows) donne un retour plus détaillé : TTL restant, autorité de la réponse, temps de réponse en millisecondes.
Quand on soupçonne un souci de propagation après une modification de zone, on interroge plusieurs résolveurs publics (ceux de Google en 8.8.8.8, ceux de Cloudflare en 1.1.1.1) et on compare les réponses. Si les IP retournées diffèrent, la propagation n’est pas terminée.
- Vérifier l’enregistrement A (ou AAAA pour IPv6) : il doit pointer vers l’IP actuelle du serveur d’hébergement.
- Contrôler le MX : un enregistrement MX absent ou mal priorisé bloque la réception des e-mails.
- Inspecter le CNAME : un alias qui pointe vers un sous-domaine supprimé (CNAME « dangling ») crée une faille exploitable par un tiers.
- Tester le TXT pour SPF et DKIM : sans ces enregistrements, les e-mails sortants finissent en spam.
CNAME dangling et DNS floods : les menaces à surveiller en 2026
La configuration DNS ne se limite plus à faire fonctionner un site. En premier semestre 2026, Cloudflare rapporte une forte hausse des attaques DDoS réseau dépassant 1 Tbit/s, avec un bond de plus de 500 % entre le premier et le deuxième trimestre. Les attaques basées sur le DNS représentent environ un tiers des attaques de couche réseau sur cette période.
Concrètement, un résolveur DNS ouvert mal configuré peut être exploité comme amplificateur dans une attaque par réflexion. Si vous gérez un serveur DNS récursif, limiter le débit de requêtes et restreindre l’accès aux seuls réseaux internes réduit considérablement le risque.
Enregistrements CNAME orphelins
Un rapport Infoblox couvrant la période juin 2025 – juin 2026 signale plus de 120 millions de nouveaux domaines éphémères utilisés à des fins malveillantes. L’un des vecteurs exploités : les CNAME « dangling », ces alias DNS qui pointent vers une ressource cloud supprimée.
En pratique, si vous avez un jour créé un CNAME vers un bucket de stockage ou une application tierce que vous n’utilisez plus, supprimez l’enregistrement DNS avant de résilier le service. Un attaquant peut recréer la ressource à l’identique et détourner le trafic de votre sous-domaine.
Paramètres réseau et choix du résolveur DNS public
Changer le résolveur DNS utilisé par votre système est l’optimisation la plus rapide à mettre en place. Le résolveur fourni par défaut par votre fournisseur d’accès internet fonctionne, mais ses performances varient selon l’heure et la charge du réseau.
Modifier le serveur DNS sous Windows
Dans les paramètres réseau de Windows, ouvrez les propriétés de votre connexion, puis la configuration IPv4. Saisissez l’adresse du serveur DNS préféré (par exemple 8.8.8.8 pour Google Public DNS ou 1.1.1.1 pour Cloudflare) et un serveur secondaire distinct. Validez, puis ouvrez un terminal et exécutez ipconfig /flushdns pour vider le cache local.
Sous macOS et Linux
Sur macOS, la modification se fait dans Préférences Système, section Réseau, onglet DNS. Sous Linux, on édite le fichier /etc/resolv.conf ou on passe par systemd-resolved selon la distribution. La logique reste la même : renseigner au moins deux serveurs DNS pour assurer la redondance.
Sur un smartphone Android, le réglage DNS privé (dans les paramètres de connexion) permet d’appliquer un résolveur chiffré via DNS-over-TLS, ce qui protège la confidentialité des requêtes DNS sur les réseaux Wi-Fi publics.
Vérifier la propagation DNS après modification de zone
Un enregistrement DNS modifié ne prend pas effet instantanément. Le délai de propagation dépend du TTL (Time To Live) défini sur l’ancien enregistrement. Si le TTL était fixé à 86 400 secondes (24 heures), les résolveurs qui ont mis la réponse en cache continueront à servir l’ancienne valeur pendant cette durée.
Abaisser le TTL à 300 secondes 48 heures avant une migration permet de réduire le temps de propagation au moment du basculement. On le remonte ensuite à une valeur plus élevée une fois la migration confirmée.
Pour vérifier la propagation en temps réel, on utilise des services en ligne qui interrogent des dizaines de résolveurs répartis sur plusieurs continents. Les retours varient selon les caches locaux, et il faut parfois attendre que le dernier résolveur distant ait vidé son cache pour confirmer que tout est aligné.
Activer DNSSEC pour signer les réponses DNS
DNSSEC ajoute une signature cryptographique aux enregistrements de votre zone DNS. Le résolveur du visiteur peut vérifier que la réponse provient bien du serveur autoritaire et qu’elle n’a pas été altérée en transit.
L’activation se fait en deux étapes : générer les clés de signature côté serveur DNS autoritaire, puis déclarer l’enregistrement DS (Delegation Signer) auprès du registrar du domaine. Si l’une des deux étapes manque, DNSSEC ne protège rien.
DNSSEC ne chiffre pas les requêtes DNS, il garantit leur intégrité. Pour la confidentialité, il faut combiner DNSSEC avec DNS-over-TLS ou DNS-over-HTTPS côté client.
Confirmer que le DNS est ok ne se résume pas à vérifier qu’un site s’affiche. C’est un audit régulier des enregistrements de zone, un nettoyage des alias obsolètes, et un paramétrage réseau qui tient compte des menaces actuelles. Un TTL bien réglé et un DNSSEC activé couvrent déjà la majorité des risques opérationnels.
