Dépannage du domaine

Si le DNS public de Google ne peut pas résoudre un domaine, cela est souvent dû à un problème avec ce domaine ou ses serveurs de noms faisant autorité. Les étapes suivantes peuvent vous aider à déterminer la cause du problème, afin que les administrateurs de domaine puissent le résoudre eux-mêmes.

Avant de suivre ces étapes, vérifiez le domaine à l'adresse dns.google, comme décrit sur la page de dépannage générale, qui peut vous renvoyer à une étape de diagnostic particulière ci-dessous. Sinon, suivez toutes les étapes ci-dessous jusqu'à ce que vous en trouviez la cause.

Étape 1: Recherchez les problèmes de validation DNSSEC

Si les recherches Web dns.google du domaine affichent "Status": 2 (SERVFAIL) et des requêtes sans DNSSEC, il se peut qu'il y ait un problème DNSSSEC avec les serveurs de noms du domaine ou son registre de domaine de premier niveau (TLD) (qui publie des enregistrements DS pour la validation DNSSEC des domaines enregistrés).

Modifications apportées au bureau d'enregistrement ou au service DNS

Des problèmes DNSSEC peuvent se produire lorsqu'un domaine passe d'un bureau d'enregistrement ou un service DNS compatible avec DNSSEC à un service qui n'est pas compatible. Si le service précédent laisse les enregistrements DS obsolètes dans le registre TLD et que le nouveau service ne crée pas d'enregistrements DNSKEY avec les enregistrements DS correspondants dans le registre TLD, la validation des outils de résolution tels que le DNS public de Google ne peut pas résoudre le domaine.

Dans ce cas, demandez à votre service d'enregistrement de noms de domaine de supprimer les enregistrements DS obsolètes du registre de domaines de premier niveau.

Les réponses DNSSEC sont trop volumineuses

Les réponses DNSSEC trop volumineuses pour tenir dans un paquet IP peuvent également être à l'origine de problèmes fragmentés, ce qui peut entraîner la suppression de réponses fragmentées. Si DNSViz indique "aucune réponse reçue jusqu'à ce que la taille de la charge utile UDP ait été réduite", les échecs DNSSEC peuvent être dus à des réponses très volumineuses. Vous pouvez réduire la taille des réponses en effectuant une ou plusieurs des actions suivantes:

  • Configurer un "nombre minimal de réponses" pour les serveurs de noms faisant autorité
  • Réduire le nombre d'enregistrements DNSKEY actifs à deux ou trois
  • Utilisez des enregistrements DNSKEY de 1 280 ou 2 048 bits (RFC 6781, StackExchange).
  • Passer des signatures RSA aux signatures ECDSA plus petites (RFC 8624)

Recherchez également d'autres problèmes DNSSEC signalés par les outils à l'étape 2. Il peut s'agir, par exemple, d'enregistrements de déni d'existence NSEC ou NSEC3 incorrects indiquant qu'il n'y a pas de sous-domaines (l'utilisation de PowerDNS avec des zones stockées dans des bases de données externes peut être présente) ou de signatures RRSIG arrivées à expiration (avec des processus de signature configurés manuellement qui ne fonctionnent pas).

Étape 2: Vérifiez les serveurs de noms faisant autorité

Page DNSViz archivée

Si le DNS public de Google (ou tout résolveur ouvert) rencontre des difficultés pour résoudre un domaine, DNSViz indique les problèmes de domaine et de serveur de noms qui en sont à l'origine. Accédez à la page Web DNSViz et saisissez le nom de domaine qui pose problème. Si DNSViz ne dispose pas de données d'historique ou ne possède que des données remontant à plus d'un jour (comme illustré sur la page ci-dessous), cliquez sur le gros bouton Analyser pour afficher un bouton "Analyser" plus petit ci-dessous (s'il n'est pas déjà visible), puis cliquez dessus. Une fois l'analyse terminée, cliquez sur "Continuer" pour afficher les résultats. Cliquez sur les erreurs rouges et les avertissements jaunes dans la barre latérale gauche pour afficher des détails, ou maintenez le pointeur de la souris sur des objets du diagramme pour faire apparaître ces informations en contexte.

Si les diagnostics précédents indiquent des problèmes DNSSEC possibles avec le domaine, accédez à la page Web de l'outil d'analyse DNSSEC, puis saisissez le nom du domaine. Si cet analyseur signale des erreurs ou des avertissements DNSSEC, placez le pointeur de la souris sur les icônes rouges ⊗ ou jaunes ⚠⚠ pour obtenir des suggestions sur la façon de les résoudre.

La page Web intoDNS signale les problèmes non-DNSSEC avec le domaine saisi sur la page principale et affiche également des suggestions pour les résoudre.

Les administrateurs de domaine devraient corriger la plupart des erreurs signalées par ces outils, car elles peuvent causer des problèmes non seulement pour le DNS public de Google, mais également pour d'autres résolveurs.

Étape 3: Recherchez les problèmes de délégation

Le DNS public de Google est un résolveur orienté parent, qui n'utilise que les serveurs de noms renvoyés dans les sites référents du domaine parent. Si les noms et les adresses de colle des serveurs de noms du domaine de premier niveau sont obsolètes ou incorrects, cela peut entraîner des problèmes de délégation.

Si DNSViz ou dans DNS signalent des incohérences entre les serveurs de noms délégués dans le TLD et ceux présents dans le domaine enfant lui-même, vous devrez peut-être corriger ces incohérences avant que le DNS public de Google puisse résoudre le domaine. Si ces outils signalent que le domaine enregistré n'existe pas (NXDOMAIN), vérifiez qu'il n'a pas expiré ou qu'il n'est pas en attente pour une raison quelconque.

Les problèmes de délégation peuvent également être dus à l'échec de la résolution des noms des serveurs de noms d'un domaine. Vérifiez les enregistrements A et AAAA des serveurs de noms sur dns.google pour voir s'il existe des problèmes avec les domaines.

Étape 4: Recherchez les réponses volumineuses

DNS s'appuie sur UDP pour acheminer la majeure partie de son trafic. Les grammes de données UDP volumineux sont soumis à une fragmentation, et les UDP fragmentés souffrent d'une distribution peu fiable. Cette démarche était l'objectif de la Journée de l'indicateur DNS 2020, qui vise à améliorer la fiabilité du DNS à l'échelle mondiale. Le DNS public de Google a pris part à cette initiative et limite la taille des réponses UDP acceptées par UDP. Essayez une requête comme celle ci-dessous avec votre propre invite de commande ou Google Cloud Shell:

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

Ces requêtes pour différents types d'enregistrements indiquent:

+dnssec
Activez DNSSEC, en particulier lorsqu'ils renvoient les enregistrements requis pour la validation DNSSEC, le cas échéant. Cela peut augmenter considérablement la taille du résultat. Cela émule le comportement du DNS public de Google.
+bufsize=1400
Limitez la taille de la mémoire tampon UDP autorisée. Cela émule le comportement du DNS public de Google, lors de l'effort DNS Flag Day 2020.
+timeout=1
Définissez le délai avant expiration sur une seconde. Cela émule le comportement du DNS public de Google.
@ns1.example.com
Serveur faisant l'objet d'une requête : conserver le signe @, mais le remplacer par le serveur faisant autorité de votre propre domaine, comme indiqué dans la première commande.

Observez le résultat. Voyez-vous une ligne semblable à celle-ci:

;; Truncated, retrying in TCP mode.
Cela indique que la réponse était supérieure à la taille de mémoire tampon UDP demandée. Elle a donc été tronquée et a renvoyé une réponse TCP. Vos serveurs faisant autorité doivent pouvoir gérer le trafic DNS sur le port TCP 53. (Consultez la RFC 7766, qui exige que les implémentations DOIVENT être compatibles avec les modes de transport UDP et TCP.)
;; MSG SIZE rcvd: 2198
Pour toute valeur supérieure à 1 400 ? Cela indique à nouveau que la réponse est élevée.
;; Query time: 727 msec
Si le nombre dépasse 500, Les DNS lents (en particulier ceux proches d'une seconde ou plus) peuvent être supprimés par le DNS public de Google. C'est probablement le cas si le temps a été passé sur une tentative UDP, puis sur une tentative TCP. L'emplacement géographique du serveur et du client peut avoir un impact important sur la latence.
;; connection timed out; no servers could be reached
Cela signifie notamment que votre serveur ne parvient pas à répondre aux requêtes DNS dans les meilleurs délais.

Vous pouvez essayer les variantes de requête suivantes:

Ajouter un paramètre +tcp
Cela oblige dig à utiliser TCP immédiatement. Vous pouvez vérifier si votre serveur faisant autorité gère les requêtes TCP directement de cette manière.
Suppression du paramètre +bufsize=1400...
Cela restaurera le comportement par défaut de dig (taille de 4096). Si vos requêtes échouent avec ce paramètre, mais qu'elles ne fonctionnent pas, cela indique que votre serveur ne gère pas correctement le basculement TCP. Le recours à UDP pour transmettre des réponses volumineuses ne fonctionne que parfois. Nous vous recommandons de prendre en charge le transport TCP pour le DNS.
Répétition sur chaque serveur de noms.
L'exemple ci-dessus comprend deux serveurs de noms faisant autorité (ns1 et ns2). Certains problèmes sont causés par des serveurs différents qui renvoient des réponses différentes. Vérifiez qu'elles répondent toutes de manière cohérente en répétant les mêmes requêtes sur tous les serveurs faisant autorité.

Si toutes les réponses étaient petites (1 400 octets ou moins), rapides (de préférence 500 millisecondes ou plus rapides) et fiables (fonctionnent de manière cohérente avec TCP et UDP), la taille des réponses ne vous pose pas problème. Lisez les autres sections de dépannage. Même si vos réponses sont rapides, les requêtes provenant de zones géographiques éloignées peuvent être plus lentes.

Si l'une de ces vérifications échoue (la méthode est vaste : lente ? non fiable). La méthode principale consiste à : (A) s'assurer que le serveur répond avec la troncature UDP lorsque sa réponse dépasse la taille de tampon UDP demandée et B) afin de pouvoir traiter la nouvelle tentative de requête TCP. Plusieurs outils peuvent vous aider à diagnostiquer les problèmes de fiabilité DNS:

Si ces outils révèlent des erreurs ou des avertissements, veillez à les corriger. Veillez également à lire toutes les autres instructions de dépannage sur ce site.

Étape 5: Vérifiez si d'autres résolveurs publics résolvent le domaine

Si vous n'avez pas trouvé de cause du problème après avoir suivi les étapes ci-dessus, exécutez les commandes suivantes dans une invite de commande, en remplaçant example.test. par le domaine en question (sans modifier les points finaux):

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS ou Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

Ces commandes utilisent les résolveurs DNS OpenDNS, Quad9 et Cloudflare 1.1.1.1. Si vous rencontrez des problèmes de résolution de deux d'entre eux et du DNS public de Google, le problème est probablement lié au domaine ou à ses serveurs de noms.

Si vous obtenez un résultat concluant de la part de plusieurs autres résolveurs publics, le problème est peut-être lié au DNS public de Google. Si aucun problème similaire n'a été signalé pour le domaine (ou son TLD) dans l'outil de suivi des problèmes, vous devez nous le signaler, y compris le résultat de la commande et le texte de la page de diagnostic ou des captures d'écran dans votre rapport.