Si vous ne parvenez pas à résoudre des domaines à l'aide du DNS public de Google, commencez par consulter la page d'accueil du DNS public de Google à l'adresse https://dns.google/. Il possède un formulaire de résolution DNS simple, illustré ici.
Si votre navigateur ne trouve pas le serveur dns.google ou s'il ne répond pas, vérifiez que vous pouvez accéder aux serveurs DNS publics de Google à l'aide des diagnostics de ligne de commande.
Saisissez google.com (ou tout nom de domaine ou adresse IP), puis appuyez sur Entrée pour afficher une page de résultats DNS détaillée, comme ci-dessous:
Résoudre les problèmes liés au DNS public de Google
Il existe de nombreux types de problèmes de résolution DNS. Suivez les instructions sous l'en-tête qui correspondent le mieux à votre problème. Si vous devez signaler un problème et obtenir de l'aide, incluez le résultat des commandes ou du texte des pages de diagnostic dans votre rapport.
Problèmes liés à la résolution d'un domaine
Si le DNS public de Google rencontre des difficultés pour résoudre un nom de domaine, saisissez-le sur la page d'informations de dns.google. Si le problème concerne un type d'enregistrement de ressources DNS (RR), saisissez-le dans le champ de texte "Type RR" (vous pouvez également saisir un nombre). Appuyez sur Entrée ou cliquez sur Résoudre pour afficher les résultats.
Dans les résultats détaillés, une ligne comportant "Comment": au bas de l'écran peut contenir des diagnostics concernant votre requête DNS. Par exemple, "DNSSEC validation failure. Check http://dnsviz.net/d/dnssec-failed.org/dnssec/
and http://dnssec-debugger.verisignlabs.com/dnssec-failed.org for errors"
Consultez toutes les URL des commentaires (il ne s'agit pas de liens, copiez-les et collez-les dans un navigateur) pour afficher les diagnostics détaillés permettant d'identifier la cause des problèmes de résolution.
Si une ligne de commentaire correspond à l'une des entrées suivantes, cliquez sur le lien correspondant pour accéder directement à une étape de diagnostic spécifique, ou commencez par la première étape de la section Dépannage de domaine.
DNSSEC validation failure- Si vous voyez ce message, désactivez la validation en cliquant sur le bouton d'activation/de désactivation DNSSEC, puis sur Résoudre le problème pour relancer la requête. Si l'opération réussit (
"Status": 0), un problème DNSSEC est survenu. Consultez la page Dépannage DNSSEC. Sinon, consultez la section Dépannage du serveur de noms. Name servers- Consultez Dépannage du serveur de noms.
Resolution failureouLame delegation- Consultez Résoudre les problèmes liés à la délégation.
Si vous rencontrez des problèmes avec des enregistrements volumineux (généralement des clés DNSSEC ou des enregistrements TXT), consultez la page Résoudre les problèmes liés aux réponses volumineuses.
Affichage de réponses incorrectes pour un domaine
Il existe de nombreuses raisons pour lesquelles le DNS public de Google peut renvoyer des réponses erronées. Essayez l'une des solutions suivantes qui vous semblent possibles compte tenu de vos connaissances du domaine.
- Si les serveurs d'un domaine ont été modifiés récemment
En particulier, si le domaine dispose de nouveaux serveurs DNS ou d'un nouveau bureau d'enregistrement DNS, le DNS public de Google peut renvoyer des réponses anciennes mises en cache (mais non expirées). Utilisez la fonctionnalité Flush Cache (documentation) pour vider le domaine enregistré et le nom de domaine spécifique renvoyant une réponse obsolète.
Si vous n'obtenez toujours pas les réponses obsolètes après le vidage, interrogez le type RR
SOAdu domaine enregistré sur la page de détails dns.google. Vérifiez ensuite le numéro de série de la zone (le premier nombre de la colonne "Answer" data"). Si vous obtenez parfois des numéros de série différents, certains serveurs de noms faisant autorité peuvent diffuser des données obsolètes, et l'opérateur DNS du domaine doit résoudre le problème.- Si les adresses d'un domaine du réseau de diffusion de contenu (CDN) sont éloignées
Lorsqu'une adresse plus proche aurait dû être renvoyée, il est possible que les serveurs de noms faisant autorité n'implémentent pas correctement le sous-réseau client ECS. Les opérateurs DNS du domaine doivent vérifier qu'ils suivent toutes les consignes de cette page.
- Si vos applications affichent des adresses différentes des résultats Web de dns.google
Si le site Web dns.google est bloqué ou affiche des résultats très différents, commencez par vérifier que vous utilisez le DNS public de Google. Si tel est le cas, différentes réponses peuvent être dues au piratage d'un DNS par un portail Wi-Fi captif, à la présence d'un logiciel malveillant sur votre routeur, votre FAI ou ses réseaux. Consultez les instructions de dépannage pour le blocage et le piratage.
La résolution des domaines est trop lente
Bien que les outils tels que traceroute et ping signalent les latences de réseau, ils ne mesurent pas la vitesse de résolution DNS et ne sont utiles que pour trouver l'emplacement des retards ou pour confirmer la joignabilité du réseau.
Google ne bloque pas les adresses IP ICMP ou aléatoires vers Google DNS, mais il existe des limites de débit pour les réponses d'erreur ICMP. De plus, le trafic ICMP peut être dépriorisé au sein des réseaux Google.
Pour mesurer la vitesse de résolution DNS, vous devez utiliser un outil de test DNS, tel que farrokhi/dnsdiag (Python, GitHub) ou dnsping (C#, SourceForge). Des mesures plus complètes peuvent être effectuées à l'aide d'outils tels que Namebench ou le GRC DNS Benchmark (pour Windows).
Déterminer la zone de diffusion de vos requêtes
La distance réseau entre votre appareil et le résolveur DNS public de Google contribue directement à la vitesse de résolution. Nous implémentons l'option d'identifiant du serveur de noms pour signaler le code d'aéroport de la zone métropolitaine où la requête DNS est gérée. Si la zone métro est éloignée de votre emplacement, la latence des requêtes est plus élevée. Cela peut être dû à diverses raisons, y compris un routage non optimal entre votre réseau et Google, ou à un manque de capacité de diffusion dans une agglomération plus proche.
Pour trouver le code d'aéroport, vous pouvez envoyer une requête à nos résolveurs DNS en définissant l'identifiant de serveur de noms NSDNS. La réponse sera au format gpdns-<airport code>. Exécutez la commande suivante pour savoir de quelle zone métropolitaine la réponse provient:
macOS ou Linux
$ dig @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")
$ dig www.google.com @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")
La résolution sur IPv6 est plus lente
Si les latences de résolution sur IPv6 sont considérablement plus longues que pour IPv4, la connectivité IPv6 entre votre FAI et Google peut être sous-optimale. Les FAI avec Google doivent vérifier le nombre de sauts beaucoup plus important dans les résultats de traceroute IPv6 (consultez la section Accéder aux serveurs DNS publics de Google) ou d'autres problèmes liés au routage BGP affichés sur le tableau de bord du FAI. Si le routage IPv6 semble se trouver dans une autre zone métropolitaine que IPv4, envoyez un e-mail au NOC Google.
Aucune réponse à (certaines) de mes requêtes DNS
Il est normal qu'une très petite partie des requêtes DNS UDP soient abandonnées. Toutefois, si vous constatez des baisses pour un pour cent ou plus de vos requêtes, utilisez un outil de test DNS comme ceux de la section précédente.
Si un outil de test DNS indique un niveau élevé de requêtes sans réponse (et surtout si ping et traceroute n'indiquent pas des taux d'abandon comparables), vérifiez si votre adresse IP génère plus de 1 000 requêtes par seconde, ce qui peut déclencher une limitation du débit.
Si tel est le cas, vous pouvez demander une augmentation de la fréquence limite sur notre outil de suivi des problèmes.
Blocage et piratage DNS
Si vous n'obtenez aucune réponse aux requêtes DNS (mais que la page dns.google fonctionne), les requêtes UDP et TCP risquent d'être bloquées ou piratées. Exécutez les commandes suivantes pour vérifier si les requêtes UDP et TCP atteignent le DNS public de Google:
Windows
nslookup -debug -type=TXT test.dns.google.com. dns.google.
nslookup -debug -type=TXT -vc locations.dns.google.com. dns.google.
macOS ou Linux
dig -t TXT test.dns.google.com. '@dns.google.'
dig -t TXT +tcp locations.dns.google.com. '@dns.google.'
Si la première sortie de la commande indique "Thanks for using Google Public DNS.", vos requêtes UDP atteignent le DNS public de Google. Si la sortie de la deuxième commande inclut locations.publicdns.goog., vos requêtes TCP atteignent également Google.
Si le résultat est NXDOMAIN, vous arrivez à un autre résolveur DNS.
Si le délai d'expiration du résultat est affiché, les requêtes DNS envoyées au DNS public de Google sont bloquées.
Utilisez les commandes UDP ou DNS traceroute de la section suivante pour identifier les cas de piratage ou de piratage.
Vérifier que vous accédez aux serveurs DNS publics de Google
Si vous ne parvenez pas à ouvrir la page d'accueil dns.google, il est possible qu'un problème de réseau ou un blocage vous empêche d'accéder au DNS public de Google.
Si votre système est configuré pour utiliser le DNS public de Google, vous devrez peut-être remplacer le nom dns.google dans les commandes suivantes par les adresses IP du DNS public de Google.
Essayez d'abord de saisir le nom. Si ce n'est pas possible, utilisez 8.8.8.8 ou une autre adresse.
Ouvrez une fenêtre de terminal à l'aide d'une invite de commande et exécutez les commandes traceroute suivantes:
Windows
Routage de trace avec la requête d'écho ICMP:
tracert -d -w 2000 dns.google
Pour tester la connectivité IPv6:
tracert -6 -d -w 2000 dns.google
macOS ou Linux
Routage de trace avec des paquets UDP non DNS:
/usr/sbin/traceroute -n -w 2 -m 30 dns.google
Pour tester la connectivité IPv6:
/usr/sbin/traceroute6 -n -w 2 -m 30 dns.google
Si votre système indique que vous n'êtes pas autorisé à exécuter traceroute, utilisez la commande sudo pour l'exécuter:
sudo /usr/sbin/traceroute -n -w 2 -m 30 dns.google
Si la dernière ligne du résultat n'affiche pas d'adresse IP publique de Google (8.8.8.8, 8.8.4.4, ou une adresse IPv6 commençant par 2001:4860:4860), un problème réseau peut vous empêcher d'accéder à Google.
Sur les systèmes autres que Windows, répétez les commandes ci-dessus avec une option -I ou -U, pour utiliser des paquets ICMP ou des paquets UDP non DNS envoyés au port DNS (53).
Si l'option -I n'est pas reconnue, exécutez la commande ping pour envoyer ICMP:
macOS ou Linux
ping -c 2 dns.google
La commande dnstraceroute des outils de test DNS Farrokhi/dnsdiag décrits dans la section La résolution des domaines est trop lente peut être utilisée pour tracer la route des requêtes DNS réelles (même sous Windows).
Si certaines de ces commandes fonctionnent et d'autres renvoient des erreurs réseau ou des délais avant expiration, le filtrage de réseau peut vous empêcher d'atteindre le DNS public de Google. Contactez votre administrateur réseau ou l'assistance de votre FAI pour le vérifier.
Si aucune de ces commandes ne fonctionne, contactez votre FAI (en amont), ou si vous êtes un FAI appairé avec Google, contactez le NOC Google.
La dernière ligne du résultat traceroute qui n'a pas trois étoiles * * * (affiche des délais avant expiration cohérents) peut indiquer l'endroit où le problème se produit.