Corriger « Server DNS Address Could Not Be Found »

L’appel se passe en général comme ceci : « Internet est cassé, mais seulement pour un seul site web ». Chrome affiche une page grise, un petit dinosaure et les mots Server DNS address could not be found, avec DNS_PROBE_FINISHED_NXDOMAIN en plus petit en dessous. Tout le reste se charge sans problème. La personne au téléphone a déjà redémarré le routeur deux fois.

J’ai corrigé cette erreur plus de fois que je ne peux les compter, et elle ne signifie presque jamais ce que les gens craignent. Chrome n’a rien, et le site web n’a en général pas disparu. Votre ordinateur a demandé l’adresse du site et, quelque part le long de la chaîne, la réponse est revenue sous la forme « cet endroit n’existe pas ». Cette chaîne — le cache de votre navigateur, le cache de votre système d’exploitation, votre routeur, le résolveur de votre fournisseur — compte plusieurs maillons, et n’importe lequel peut être le menteur. Tout le travail consiste à trouver lequel.

Première question : le site est-il en panne pour tout le monde, ou seulement pour vous ?

Avant de toucher au moindre réglage, prenez votre téléphone. Désactivez le Wi-Fi pour que le téléphone utilise les données mobiles, puis ouvrez le site. Vous venez d’effectuer le test le plus utile de tout ce guide, car vous avez changé tout le chemin réseau en cinq secondes.

• Le site se charge en données mobiles. Le site web va bien. Quelque chose entre votre ordinateur et le résolveur de votre fournisseur vous donne une mauvaise réponse, et tout ce qui suit va le corriger.
• Le site échoue là aussi. Essayez un autre site que vous utilisez chaque jour. S’il se charge, le problème est probablement du côté du site web : un enregistrement de domaine expiré, un changement DNS raté ou un hébergeur qui a tout débranché. Vous ne pouvez pas corriger cela depuis votre chaise.
• Tout échoue partout. Ce n’est plus cette erreur ; c’est votre connexion elle-même. Autre problème, autre guide.

Si vous voulez la même réponse avec plus de portée que ce que votre téléphone vous offre, le vérificateur de propagation DNS interroge des résolveurs publics dans plusieurs pays et montre s’ils sont d’accord sur l’adresse du site. Si les résolveurs du monde entier renvoient NXDOMAIN, le site a un vrai problème DNS. S’ils renvoient tous une adresse sans rechigner, la mauvaise réponse est produite quelque part près de chez vous.

Ce que l’erreur signifie vraiment

Le DNS est la recherche qui transforme un nom comme example.com en l’adresse numérique à laquelle votre navigateur se connecte réellement. Cette erreur signifie que la recherche n’est pas revenue vide par accident : le résolveur a activement signalé que le nom n’existe pas. C’est ce que signifie NXDOMAIN, et notre article sur ce que signifie NXDOMAIN traite la réponse elle-même en profondeur.

Voici le point qui déroute les gens : « n’existe pas » peut être une réponse vraie au sujet d’un site supprimé, ou une réponse périmée que votre propre équipement a mise en cache plus tôt et continue de répéter. Le message d’erreur est identique dans les deux cas. C’est pourquoi les correctifs ci-dessous s’attaquent aux caches et aux résolveurs plutôt qu’au navigateur lui-même : réinstaller Chrome pour cela revient à acheter un nouveau téléphone parce que le numéro d’un seul contact a changé.

Associez le symptôme à la cause

Les correctifs, dans l’ordre où je les essaie vraiment

1. 1

   Videz votre cache DNS

   Sous Windows, ouvrez l’Invite de commandes et exécutez ipconfig /flushdns. Sur un Mac, c’est sudo dscacheutil -flushcache dans Terminal. Cela jette les réponses stockées de votre ordinateur, y compris la mauvaise, et force une nouvelle recherche. Cela prend dix secondes et ne casse rien, c’est pourquoi c’est toujours mon premier réflexe.

2. 2

   Passez à un résolveur public

   Si le vidage n’a rien changé, la mauvaise réponse vient de plus haut. Réglez les serveurs DNS de votre ordinateur sur un résolveur public tel que 1.1.1.1 ou 8.8.8.8, puis rechargez. Si le site reprend vie, le résolveur de votre fournisseur était le menteur : laissez le réglage tel quel, ou gardez-le jusqu’à ce que votre fournisseur se remette.

3. 3

   Vérifiez le fichier hosts

   Le fichier hosts écrase complètement le DNS. Si une de ses lignes associe le nom du site à une ancienne adresse — laissée là par un vieux logiciel, une expérience passée ou quelque chose que vous avez collé il y a des années puis oublié —, aucun changement de résolveur ne servira, car votre ordinateur ne demande même pas. Ouvrez le fichier, cherchez le nom du site et supprimez ou commentez toute ligne que vous trouvez.

4. 4

   Redémarrez le routeur, une fois

   Les routeurs mettent aussi les réponses en cache, et les modèles bon marché le font mal. Un seul redémarrage vide ce cache et renégocie la connexion. Je dis une fois, car le redémarrer quatre fois de suite, comme les appelants l’avouent souvent, fait exactement ce que le redémarrer une fois fait.

5. 5

   Désactivez le VPN et retestez

   Un VPN redirige vos requêtes DNS vers ses propres serveurs. Si ceux-ci sont en panne, mal configurés, ou si le tunnel est à moitié mort alors que votre connexion est restée active, les recherches de noms échouent alors que tout semble connecté. Déconnectez complètement — pas mettre en pause, déconnecter — et rechargez la page.

Deux choses dont les gens jurent qu’elles aident et qui aident rarement

Réinstaller le navigateur. Le navigateur garde bien un petit cache à lui, mais cette erreur est générée par l’échec de la recherche au niveau du système, et une installation neuve hérite du même résolveur, du même fichier hosts et du même routeur. Vous passerez vingt minutes à restaurer vos favoris pour revenir au dinosaure.

L’autre, c’est « attendre 48 heures », répété comme une formule magique. Attendre corrige vraiment un seul scénario : le site a réellement changé son DNS récemment, et l’ancienne réponse continue de se vider des caches du monde entier. Notre guide pour diagnostiquer « ce site est inaccessible » sépare cette attente des défauts que vous pouvez corriger vous-même. Mais si le site se charge sur votre téléphone aujourd’hui, attendre ne réparera pas votre réseau : les cinq étapes ci-dessus le feront, en général en dix minutes.

Quand un seul navigateur affiche l'erreur

Voici une variante qui envoie les gens sur la mauvaise piste pendant des heures : le site échoue dans Chrome mais se charge très bien dans un autre navigateur, sur la même machine, le même réseau, à la même minute. Ce seul fait écarte d'un coup votre routeur, votre fournisseur et le site web. La différence se trouve à l'intérieur même du navigateur.

Les navigateurs modernes effectuent de plus en plus leurs propres requêtes au lieu de faire confiance au système. Chrome possède un réglage Secure DNS qui peut envoyer les requêtes via une connexion chiffrée vers un résolveur choisi par le navigateur, en contournant celui avec lequel votre ordinateur est configuré ; Firefox dispose d'une fonction similaire avec ses propres réglages par défaut. Si ce chemin choisi par le navigateur est cassé — ou détient simplement une réponse périmée que le reste de votre système a déjà oubliée — vous obtenez cette erreur dans exactement un programme pendant que tout le reste fonctionne. Régler le DNS sécurisé du navigateur pour utiliser le résolveur système, ou le désactiver, est le test de deux minutes qui tranche la question.

La répartition inverse est tout aussi instructive : tous les navigateurs échouent mais une requête en ligne de commande réussit, ce qui renvoie à quelque chose que les navigateurs partagent — les paramètres du résolveur système, le fichier hosts, le réseau lui-même. Un programme contre tous les programmes est le moyen le plus rapide que je connaisse pour localiser la couche qui détient la mauvaise réponse, et c'est pourquoi ma première question, lors de ces appels, ne porte jamais sur les réglages. C'est : « est-ce que ça échoue partout, ou seulement ici ? »

Vous pouvez aussi interroger les résolveurs un par un au lieu de deviner. Une commande comme nslookup example.com 1.1.1.1 demande sa réponse à un résolveur précis, en ignorant vos réglages par défaut. Interrogez votre résolveur habituel, puis un résolveur public. Si le résolveur public renvoie une adresse pendant que le vôtre renvoie NXDOMAIN, vous avez pris le menteur sur le fait — et vous savez si le travail restant consiste à vider le cache, à attendre ou à changer le réglage pour de bon.

La même panne porte d'autres costumes ailleurs, ce qui déroute les gens qui cherchent de l'aide. Le Chrome d'Android l'appelle ERR_NAME_NOT_RESOLVED, Firefox dit que le serveur est introuvable, et Safari signale qu'il ne trouve pas le serveur. Des mots différents, le même événement en dessous : une requête est revenue en disant que le nom n'existe pas. Si un correctif d'un guide consacré à l'un de ces messages concerne en réalité les caches ou les résolveurs, il s'applique aussi au vôtre — traduisez le nom de l'erreur, gardez la méthode.

Quand ce n’est vraiment pas votre problème

Parfois, ma réponse lors de ces appels est : c’est eux, pas vous. Un domaine dont l’enregistrement expire voit ses serveurs de noms retirés, et tous les résolveurs de la planète se mettent à répondre NXDOMAIN — exactement la même erreur, sauf qu’elle dit maintenant la vérité. Un propriétaire de site en pleine migration peut aussi publier un enregistrement cassé et faire tomber le nom pour tout le monde d’un seul coup.

L’indice révélateur, c’est la constance. Votre téléphone échoue, celui de votre voisin échoue, et les astuces locales de notre guide pour corriger les erreurs Windows DNS_PROBE_FINISHED ne changent rien — pendant que les résolveurs publics du monde entier s’accordent sur le fait qu’il n’y a aucune adresse. À ce stade, fermez les onglets de réglages. Il ne reste rien à réparer de votre côté ; le site reviendra quand son propriétaire corrigera l’enregistrement, ou il ne reviendra pas du tout.