Serveur DNS ne répond pas : Guide complet de dépannage

Une erreur "DNS server not responding" signifie que votre système d’exploitation a envoyé une requête de résolution à un résolveur DNS et n’a reçu aucune réponse dans le délai imparti — le navigateur n’a donc jamais obtenu l’adresse IP nécessaire pour ouvrir une connexion TCP. Le résultat est un échec de chargement de page même lorsque votre lien réseau physique est entièrement opérationnel. La cause principale peut se situer n’importe où dans la chaîne de résolution : votre résolveur stub local, le résolveur récursif de votre FAI, un serveur faisant autorité en amont, ou un périphérique réseau mal configuré entre vous et l’un d’eux.

Ce guide parcourt chaque couche de cette chaîne — du redémarrage du routeur en 30 secondes au remplacement de pilote de bas niveau — avec des commandes exactes pour Windows, macOS et Linux, ainsi qu’une comparaison des résolveurs publics et une matrice de décision pour vous aider à isoler rapidement la panne.

Ce qui se passe réellement lors de la résolution DNS

Avant de corriger l’erreur, comprendre le chemin de résolution évite les efforts inutiles. Lorsque vous tapez example.com dans un navigateur :

1. Le système d’exploitation vérifie son cache DNS local (et le fichier hosts).
2. Si aucun enregistrement en cache n’existe, le résolveur stub transmet la requête au résolveur récursif configuré sur l’interface réseau (généralement votre routeur ou un serveur assigné par le FAI).
3. Le résolveur récursif parcourt la hiérarchie DNS — serveurs racine, serveurs de noms TLD, serveurs de noms faisant autorité — et renvoie l’enregistrement A ou AAAA final.
4. Le système d’exploitation met le résultat en cache pour la durée du TTL de l’enregistrement et transmet l’adresse IP au navigateur.

Une erreur "not responding" se déclenche généralement à l’étape 2 ou 3. Le résolveur stub a envoyé un paquet UDP au port 53 et n’a obtenu que le silence. Ce silence a un nombre étonnamment élevé de causes.

Causes principales de l’erreur DNS Server Not Responding

Pannes côté résolveur DNS

• Le résolveur récursif configuré est temporairement surchargé ou hors ligne.
• L’infrastructure DNS de votre FAI est sous une attaque DDoS ou en cours de maintenance.
• L’adresse IP du résolveur a changé mais votre appareil conserve toujours l’ancienne valeur.

Problèmes de réseau local et de matériel

• Bugs du firmware du routeur qui corrompent le relais DNS (courant sur les appareils grand public après de longues périodes de fonctionnement).
• Un bail DHCP qui a transmis une adresse de serveur DNS obsolète ou invalide.
• Un câble Ethernet défectueux ou un signal Wi-Fi dégradé causant des pertes de paquets spécifiquement sur le port UDP 53.

Mauvaises configurations au niveau de l’hôte

• Un cache DNS local corrompu ou empoisonné contenant des réponses négatives obsolètes.
• Une adresse DNS saisie manuellement qui est incorrecte ou n’est plus accessible.
• Une entrée dans le fichier hosts qui entre en conflit avec la réponse DNS attendue.

Interférences des logiciels de sécurité

• Les pare-feux ou outils de sécurité des points de terminaison qui bloquent le port UDP/TCP 53 sortant ou interceptent les requêtes DNS pour inspection puis les abandonnent.
• Les clients VPN qui redirigent le trafic DNS via un point de terminaison de tunnel actuellement inaccessible.
• Les logiciels de contrôle parental qui agissent comme proxy DNS local et plantent silencieusement.

Problèmes de pilotes et au niveau du système d’exploitation

• Un pilote NIC obsolète ou corrompu qui gère mal les datagrammes UDP.
• Le service DNS Client de Windows (Dnscache) dans un état bloqué.
• Un processus mDNSResponder de macOS qui a consommé une mémoire excessive et a cessé de répondre.

Corrections étape par étape : classées par effort et probabilité

Suivez ces étapes dans l’ordre. Chaque étape prend moins de cinq minutes et élimine une couche spécifique du problème.

Étape 1 : Vérifier d’abord la portée du problème

Avant de modifier des paramètres, exécutez un diagnostic rapide pour confirmer que DNS est réellement le point de défaillance et non la connectivité générale :

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Si ping 8.8.8.8 réussit mais que nslookup example.com échoue, la résolution DNS est définitivement le problème. Si ping 8.8.8.8 échoue également, le problème est plus profond — probablement le routage ou la connectivité physique — et DNS est un symptôme, pas la cause.

Étape 2 : Redémarrer votre routeur et votre modem

Un cycle d’alimentation efface le cache de relais DNS interne du routeur, réinitialise les baux DHCP et rétablit la connexion WAN avec de nouvelles attributions de serveurs DNS de votre FAI.

1. Débranchez le câble d’alimentation du modem et du routeur.
2. Attendez 30 secondes complètes (les condensateurs ont besoin de temps pour se décharger).
3. Allumez d’abord le modem ; attendez qu’il se synchronise complètement (voyant WAN fixe).
4. Allumez ensuite le routeur ; attendez qu’il termine sa séquence de démarrage.
5. Reconnectez votre appareil et relancez le test nslookup de l’étape 1.

Cas particulier : Si votre routeur fonctionne depuis des semaines sans redémarrage, son relais DNS (dnsmasq ou similaire) peut avoir un cache plein ou une fuite mémoire. Certains routeurs fournis par les FAI ont des bugs connus où le relais DNS cesse de transmettre les requêtes après un certain seuil de temps de fonctionnement. Un redémarrage est la solution la plus rapide.

Étape 3 : Vider le cache DNS local

Les entrées de cache obsolètes ou corrompues amènent le système d’exploitation à renvoyer de mauvais résultats ou à générer des échecs de recherche avant même qu’une requête ne quitte la machine.

Windows :

ipconfig /flushdns

Vous devriez voir : Successfully flushed the DNS Resolver Cache.

macOS (spécifique à la version — utilisez la commande correcte pour votre système d’exploitation) :

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved) :

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd) :

sudo service nscd restart

Étape 4 : Passer à un résolveur DNS public fiable

Si le résolveur DNS de votre FAI est le problème, passer à un résolveur public bien maintenu est la solution de contournement la plus rapide. Le tableau ci-dessous compare les options les plus utilisées :

Cloudflare 1.1.1.1 mesure systématiquement la latence moyenne mondiale des requêtes la plus faible dans les benchmarks indépendants. Quad9 est le meilleur choix si vous souhaitez un blocage passif des domaines malveillants sans gérer un filtre DNS séparé.

Modifier le DNS sur Windows 10/11 :

1. Ouvrez Paramètres > Réseau et Internet > Modifier les options de l’adaptateur.
2. Faites un clic droit sur votre adaptateur actif et sélectionnez Propriétés.
3. Sélectionnez Internet Protocol Version 4 (TCP/IPv4) et cliquez sur Propriétés.
4. Sélectionnez Utiliser les adresses de serveur DNS suivantes.
5. Entrez les IP de résolveur principal et secondaire de votre choix.
6. Cliquez sur OK, puis exécutez ipconfig /flushdns pour effacer les entrées de cache obsolètes.

Pour les réseaux IPv6, répétez le processus pour Internet Protocol Version 6 (TCP/IPv6) en utilisant les adresses IPv6 du résolveur (par exemple, Cloudflare : 2606:4700:4700::1111 et 2606:4700:4700::1001).

Modifier le DNS sur macOS :

1. Ouvrez Réglages Système > Réseau.
2. Sélectionnez votre connexion active et cliquez sur Détails.
3. Accédez à l’onglet DNS.
4. Supprimez les entrées existantes avec le bouton –, puis ajoutez les IP de résolveur de votre choix avec +.
5. Cliquez sur OK et Appliquer.

Modifier le DNS sur Linux (NetworkManager) :

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Étape 5 : Redémarrer le service DNS Client (Windows)

Le service DNS Client de Windows (Dnscache) met en cache les noms résolus et gère le résolveur stub. S’il entre dans un état bloqué, toutes les requêtes DNS échouent silencieusement.

net stop dnscache
net start dnscache

Alternativement, via la console Services : appuyez sur Win + R, tapez services.msc, localisez DNS Client, faites un clic droit et sélectionnez Redémarrer. Notez que sur certaines versions de Windows 11, l’option de redémarrage est grisée dans l’interface graphique — utilisez plutôt la méthode en ligne de commande.

Étape 6 : Désactiver temporairement le pare-feu ou le logiciel de sécurité

Les pare-feux tiers et les suites de protection des points de terminaison interceptent parfois le trafic DNS pour inspection et, en raison d’un conflit de règles ou d’un bug du moteur, abandonnent complètement les paquets.

Pare-feu Windows Defender (test temporaire uniquement) :

netsh advfirewall set allprofiles state off

Réactivez immédiatement après le test :

netsh advfirewall set allprofiles state on

macOS :

Accédez à Réglages Système > Confidentialité et sécurité > Pare-feu et désactivez-le à des fins de test.

Si la désactivation du pare-feu résout le problème, ne le laissez pas désactivé. Ouvrez plutôt l’éditeur de règles du pare-feu et recherchez les règles bloquant le trafic sortant sur le port UDP 53 et le port TCP 53. Ajoutez des règles d’autorisation explicites pour les IP de résolveur DNS de votre choix.

Les clients VPN méritent une attention particulière ici. De nombreuses applications VPN installent un proxy DNS local sur 127.0.0.1:53 et redirigent toutes les requêtes via le tunnel. Si le serveur VPN est inaccessible, chaque requête DNS échoue. Déconnectez le VPN, testez le DNS, puis reconnectez-vous et vérifiez les paramètres de fuite DNS du client VPN.

Étape 7 : Essayer un navigateur différent

Certaines extensions de navigateur — notamment les bloqueurs de publicités, les outils de confidentialité et les plugins de sécurité — interceptent les requêtes DNS-over-HTTPS (DoH) ou modifient le comportement du résolveur système. Si le DNS fonctionne dans un navigateur mais pas dans un autre, le problème est au niveau des extensions, pas au niveau du système d’exploitation.

Testez d’abord dans une fenêtre privée/incognito (les extensions sont généralement désactivées). Si cela résout le problème, désactivez les extensions une par une pour identifier le coupable. Si le problème persiste dans tous les navigateurs, la panne se situe au niveau du système d’exploitation ou du réseau.

Étape 8 : Mettre à jour ou restaurer les pilotes réseau

Un pilote NIC corrompu peut provoquer une gestion erratique des paquets UDP, ce qui se manifeste par des échecs DNS intermittents même lorsque les connexions TCP fonctionnent.

Windows — mise à jour via le Gestionnaire de périphériques :

1. Appuyez sur Win + X et sélectionnez Gestionnaire de périphériques.
2. Développez Cartes réseau.
3. Faites un clic droit sur votre adaptateur et sélectionnez Mettre à jour le pilote > Rechercher automatiquement des pilotes.
4. Redémarrez après l’installation.

Windows — restaurer un pilote récemment mis à jour :

Si l’erreur DNS a commencé immédiatement après une mise à jour Windows, le nouveau pilote peut être la régression. Dans le Gestionnaire de périphériques, faites un clic droit sur l’adaptateur, sélectionnez Propriétés > Pilote > Restaurer le pilote.

macOS : Les pilotes NIC sont intégrés à macOS. Appliquez toutes les mises à jour système en attente via Réglages Système > Général > Mise à jour de logiciels.

Linux :

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Étape 9 : Vérifier les connexions réseau physiques

Si vous utilisez une connexion filaire, un câble Ethernet dégradé provoque des pertes de paquets intermittentes qui affectent de manière disproportionnée les protocoles basés sur UDP comme DNS (qui n’a pas de retransmission intégrée au niveau de la couche application).

• Réinsérez les deux extrémités du câble Ethernet.
• Remplacez le câble par un câble connu comme fonctionnel.
• Testez un port différent sur le routeur ou le commutateur.
• Vérifiez les voyants LED d’état du lien de la NIC — un voyant vert ou orange fixe confirme le lien physique ; un voyant clignotant ou absent indique un problème de couche 1.

Étape 10 : Exécuter l’utilitaire de résolution des problèmes réseau Windows

Windows inclut un diagnostic automatisé qui peut détecter et corriger les mauvaises configurations DNS courantes, notamment la réinitialisation du client DNS et le vidage du cache.

Accédez à Paramètres > Système > Résolution des problèmes > Autres utilitaires de résolution des problèmes > Connexions Internet et exécutez l’assistant. Il tentera des réparations automatiques et signalera ce qu’il a trouvé. Bien qu’il ne couvre pas tous les scénarios, c’est une vérification utile qui prend moins d’une minute.

Étape 11 : Vérifier et modifier le fichier hosts

Un fichier hosts corrompu ou modifié de manière malveillante peut remplacer le DNS pour des domaines spécifiques, provoquant des échecs de résolution qui ressemblent à une erreur de serveur DNS.

Windows — ouvrir avec des privilèges élevés :

notepad C:WindowsSystem32driversetchosts

macOS / Linux :

sudo nano /etc/hosts

Recherchez les entrées qui redirigent des domaines courants vers 0.0.0.0 ou 127.0.0.1. Les logiciels de sécurité, les bloqueurs de publicités et les malwares modifient tous ce fichier. Supprimez toutes les entrées suspectes, enregistrez et videz le cache DNS.

Étape 12 : Réinitialiser la pile TCP/IP et Winsock (Windows)

Si plusieurs composants réseau sont mal configurés, une réinitialisation complète de la pile est plus rapide que de rechercher les paramètres individuels :

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Redémarrez la machine après avoir exécuté les cinq commandes. Cela réinitialise les paramètres de registre TCP/IP et le catalogue Winsock à leur état par défaut sans affecter vos pilotes de carte réseau.

Étape 13 : Réinitialiser votre routeur aux paramètres d’usine

Utilisez ceci en dernier recours avant de contacter votre FAI. Une réinitialisation d’usine efface toute la configuration personnalisée — SSID Wi-Fi, mots de passe, règles de redirection de port et tous les paramètres DNS personnalisés — et restaure le routeur à son état d’origine.

La plupart des routeurs ont un bouton de réinitialisation encastré. Maintenez-le avec une épingle pendant 10 à 15 secondes jusqu’à ce que les voyants d’état s’allument en cycle. Après le redémarrage du routeur, reconfigurez votre réseau depuis le début. Si le DNS fonctionne immédiatement après la réinitialisation, un paramètre de routeur mal configuré en était la cause.

Étape 14 : Contacter votre FAI

Si toutes les étapes ci-dessus échouent et que le problème affecte tous les appareils de votre réseau, le problème se situe presque certainement en amont de votre routeur — soit dans l’infrastructure du résolveur récursif du FAI, soit sur le lien WAN lui-même. Contactez le support technique de votre FAI avec les informations suivantes prêtes :

• Résultats de nslookup example.com en utilisant à la fois le DNS de votre FAI et un résolveur public comme 8.8.8.8.
• Si le problème est intermittent ou constant.
• Si le passage à un point d’accès mobile (contournant entièrement votre FAI) résout le problème.

Ce dernier test est le test d’isolation du FAI définitif.

Configuration DNS pour les administrateurs de serveurs

Si vous gérez un environnement VPS Hosting ou un Serveur Dédié, les erreurs DNS prennent des dimensions supplémentaires. Un résolveur mal configuré sur un serveur affecte chaque application qui s’y exécute — les serveurs web, la distribution de courrier, les gestionnaires de paquets et les agents de surveillance dépendent tous d’une résolution de noms fiable.

Vérifier la configuration du résolveur sur les serveurs Linux :

cat /etc/resolv.conf

Un fichier sain doit contenir au moins deux lignes nameserver pointant vers des résolveurs fiables :

nameserver 1.1.1.1
nameserver 8.8.8.8

Sur les systèmes utilisant systemd-resolved, /etc/resolv.conf est un lien symbolique. Le modifier directement n’a aucun effet. Utilisez plutôt resolvectl :

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Tester la latence de résolution depuis un serveur :

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Si les temps de requête dépassent systématiquement 200ms, le résolveur est géographiquement distant ou sous charge. Passez à un résolveur avec un point de présence plus proche du centre de données de votre serveur.

Pour les serveurs exécutant des environnements cPanel VPS, la configuration DNS est également gérée via la page Basic cPanel & WHM Setup de WHM. Assurez-vous que les résolveurs listés correspondent à ce qui se trouve dans /etc/resolv.conf pour éviter les problèmes de résolution split-brain.

DNS et enregistrement de domaine : la connexion en amont

Une erreur "DNS server not responding" sur votre propre domaine — plutôt que celui de quelqu’un d’autre — remonte souvent à la configuration des serveurs de noms au niveau du registrar. Si vous avez récemment enregistré un domaine ou modifié des serveurs de noms via l’Enregistrement de Domaine, la propagation prend jusqu’à 48 heures. Pendant cette période, certains résolveurs dans le monde conservent encore les anciens enregistrements NS.

Utilisez un vérificateur de propagation ou interrogez directement plusieurs résolveurs géographiquement distribués :

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Les divergences entre les réponses des résolveurs pendant la propagation sont normales. Si les réponses sont toujours incohérentes après 48 heures, les enregistrements NS chez le registrar sont probablement mal configurés.

Sécuriser le DNS : DNSSEC et DNS-over-HTTPS

Les requêtes DNS standard transitent en clair sur le port UDP 53, les rendant vulnérables aux attaques de DNS spoofing et d’empoisonnement du cache. Deux technologies complémentaires y remédient :

DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS, permettant aux résolveurs de vérifier qu’une réponse est authentique et n’a pas été altérée. Il protège l’intégrité des données mais ne chiffre pas la requête elle-même.

DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) chiffrent l’intégralité de la requête DNS, empêchant l’écoute clandestine et la manipulation sur le chemin. Les navigateurs modernes prennent en charge DoH nativement. Pour l’activer à l’échelle du système sur Windows 11, accédez à Paramètres > Réseau et Internet > [votre adaptateur] > Attribution du serveur DNS > Modifier et définissez le chiffrement sur Chiffré uniquement (DNS over HTTPS).

Pour les serveurs, configurez systemd-resolved pour utiliser DoT :

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Si vous exploitez un service d’Hébergement Email ou gérez votre propre serveur de messagerie, une configuration DNS correcte — notamment les enregistrements SPF, DKIM et DMARC — est essentielle pour la délivrabilité. Les pannes DNS sur un serveur de messagerie ne se contentent pas de bloquer la navigation sortante ; elles provoquent des reports ou des rebonds d’e-mails et des échecs de validation des certificats TLS.

Certificats SSL et dépendance DNS

L’émission et le renouvellement des certificats TLS dépendent entièrement du DNS. Les Autorités de Certification effectuant la validation de domaine (DV) via le défi ACME DNS-01 doivent résoudre l’enregistrement TXT _acme-challenge de votre domaine. Si le DNS est défaillant au moment du renouvellement, les outils automatisés comme Certbot échoueront silencieusement, et vos Certificats SSL expireront — entraînant la perte de HTTPS avec eux.

Mettez en place une surveillance à la fois de la résolution DNS et de l’expiration des certificats. Une vérification simple basée sur cron :

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Matrice de décision : isoler la couche de défaillance DNS

Utilisez cette matrice pour identifier la couche de panne avant de passer du temps sur des corrections qui ne s’appliqueront pas à votre situation.

Liste de contrôle des points clés techniques

• Exécutez d’abord ping 8.8.8.8. S’il échoue, le DNS n’est pas votre problème principal — corrigez d’abord le routage ou la connectivité physique.
• Videz toujours le cache DNS local après avoir modifié les paramètres du résolveur ; les entrées obsolètes masqueront si la correction a fonctionné.
• Passez à Cloudflare 1.1.1.1 ou Quad9 9.9.9.9 comme premier changement de résolveur — les deux sont plus rapides et plus fiables que la plupart des résolveurs FAI.
• Sur Windows, si l’interface graphique des Services grise l’option de redémarrage du DNS Client, utilisez net stop dnscache && net start dnscache depuis une invite de commandes élevée.
• Sur les serveurs Linux, ne modifiez jamais /etc/resolv.conf directement sur les systèmes systemd-resolved — les modifications sont écrasées au redémarrage du réseau. Utilisez resolvectl ou nmcli.
• Les clients VPN sont souvent des coupables silencieux. Testez toujours avec le VPN déconnecté avant d’escalader.
• Pour vos propres domaines, dig +trace contourne tous les caches et montre exactement ce que les serveurs faisant autorité renvoient — utilisez-le avant de supposer un problème de résolveur.
• Activez la validation DNSSEC et DNS-over-TLS/HTTPS sur les serveurs de production pour éliminer toute une classe de pannes DNS basées sur le spoofing.
• Sur les serveurs, surveillez conjointement la santé de la résolution DNS et l’expiration des certificats SSL — une panne DNS entraînera silencieusement l’échec du renouvellement des certificats quelques jours plus tard.

Foire aux questions

Pourquoi le DNS échoue-t-il même si j’ai une connexion internet fonctionnelle ?

La résolution DNS utilise des paquets UDP vers le port 53, ce qui est distinct des connexions TCP que votre navigateur utilise pour charger des pages. Une règle de pare-feu, un relais DNS planté sur votre routeur ou un résolveur hors ligne peut bloquer spécifiquement le port 53 tout en laissant tout autre trafic non affecté. Exécutez ping 8.8.8.8 pour confirmer la connectivité IP, puis nslookup example.com pour confirmer que le DNS est la panne isolée.

Est-il sûr d’utiliser définitivement le DNS de Google ou Cloudflare à la place du résolveur de mon FAI ?

Oui, pour la plupart des utilisateurs et des cas d’usage. Google Public DNS et Cloudflare 1.1.1.1 prennent tous deux en charge la validation DNSSEC et offrent des SLA de disponibilité supérieurs aux résolveurs FAI typiques. La contrepartie est que vos requêtes DNS sont traitées par un fournisseur d’infrastructure tiers plutôt que par votre FAI. Cloudflare publie une politique stricte de non-journalisation des requêtes ; Google conserve des journaux anonymisés jusqu’à 48 heures.

Quelle est la différence entre vider le cache DNS et changer le serveur DNS ?

Vider le cache supprime les résultats de résolution stockés localement, forçant le système d’exploitation à envoyer de nouvelles requêtes au résolveur configuré. Changer le serveur DNS redirige l’endroit où ces requêtes sont envoyées. Si votre cache contient une entrée empoisonnée ou obsolète, le vidage la corrige sans changer votre résolveur. Si votre résolveur lui-même est hors ligne ou lent, changer l’adresse du serveur le corrige sans toucher au cache. En pratique, faire les deux ensemble après une panne DNS est l’approche la plus propre.

Pourquoi nslookup réussit-il mais le navigateur affiche-t-il toujours une erreur DNS ?

Les navigateurs utilisent de plus en plus leur propre implémentation DNS-over-HTTPS, qui contourne entièrement le résolveur du système d’exploitation. Si le point de terminaison DoH configuré du navigateur est inaccessible, il peut échouer même lorsque le résolveur système fonctionne correctement. Vérifiez les paramètres de confidentialité ou de sécurité du navigateur pour une option "DNS sécurisé" ou "DNS over HTTPS" et désactivez-la ou pointez-la vers un fournisseur DoH accessible.

Comment diagnostiquer les problèmes DNS sur un VPS Linux sans interface graphique ?

Utilisez dig, nslookup et resolvectl depuis la ligne de commande. Exécutez dig @1.1.1.1 example.com pour tester un résolveur spécifique directement, en contournant entièrement la configuration locale. Exécutez resolvectl status pour voir quel résolveur le système utilise actuellement et si DNSSEC est actif. Vérifiez /etc/resolv.conf pour confirmer les serveurs de noms configurés, et vérifiez que le fichier n’est pas un lien symbolique cassé avec ls -la /etc/resolv.conf.