Comment les délais d'attente DNS sont-ils censés fonctionner?

J'ai récemment rencontré un problème lorsqu'un service distant demandant l'adresse IP de mon serveur (avec un fournisseur DNS hébergé) répondait avec:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Mise à jour: le service distant mentionné ici est Let's Encrypt; j'ai déposé un bogue contre leur traqueur de problème, ce qui m'a conduit sur ce chemin.)

Lors de tests sur mon réseau local, j'ai pu constater que j'obtiens parfois une réponse DNS vide du serveur DNS hébergé. Apparemment, cela est intermittent car cela ne se produit que lorsque les enregistrements DNS ne sont pas dans le cache, et ce n'est un problème que lorsque le serveur DNS est vraiment occupé.

Voici une description Wireshark d'un message de réponse vide:

Bien sûr, puisque la plupart des requêtes et des réponses DNS sont envoyées via UDP, un résolveur local attendra juste un peu la réponse, puis abandonnera. Ce que je me demande maintenant, c'est s'il existe des directives pour les temps de réponse DNS? Mon hébergeur DNS a en quelque sorte haussé les épaules et a dit que mon résolveur local avait envoyé la réponse vide trop tôt. Je n'ai jamais eu ce problème auparavant, mais je suis surpris du mode d'échec - une réponse DNS vide sans code d'erreur.

Est-ce que quelqu'un connaît certaines directives sur la façon dont cela est censé fonctionner, et quand / comment je peux prouver que mon hébergement DNS fait quelque chose de mal?

domain-name-system dns-hosting

— djc
source

Pouvez-vous mettre à jour la question pour fournir plus d'informations sur la réponse vide? Cela peut signifier un certain nombre de choses selon les indicateurs définis et l'apparence de la section d'autorité. Nous aurions besoin de voir la sortie de dig/ nslookupou une dissection de Wireshark. ( tcpdumpne sera pas assez bon) Si vous utilisez nslookup, exécutez d' set debugabord.

— Andrew B

J'ai un PCAP, mais je ne sais pas comment je peux le montrer ici?

— djc

Ouvrez-le dans Wireshark, cliquez sur le paquet, puis développez les informations pour le protocole DNS. Développez également les sous-catégories, puis postez une capture d'écran dans votre question à l'aide du bouton Insérer une image. Vous pouvez recadrer la capture d'écran dans le protocole DNS.

— Andrew B

Réponses:

La réponse vide que vous regardez est un état synthétique appelé NODATA. NODATAet les NXDOMAINdeux indiquent que le nom n'existe pas, mais NXDOMAINs'applique également à tous les noms sous l'enregistrement indiqué. NODATAindique que ce nom est associé à des enregistrements d'un type non demandé, ou qu'il existe d'autres enregistrements sous ce que vous demandez. (ie example.test.xavamedia.nl.)

Vos points à retenir NODATAet NXDOMAINsont en fait les mêmes dans ce contexte: l'enregistrement du nom et du type demandés n'existait pas. Un serveur de noms faisant autorité a été atteint pour le domaine demandé, et il a répondu en indiquant qu'un enregistrement de ce nom et de ce type n'existait pas. Ce n'est pas une erreur de communication. Le serveur faisant autorité a déclaré qu'il ne disposait pas des données. Il est plus que probable que le serveur avec lequel vous parliez avait déjà traité cette demande et négatif a mis en cache l'absence de cet enregistrement au cours des quatre dernières heures. (14400 secondes est l'intervalle de cache négatif défini par l'enregistrement SOA pour xavamedia.nl.)

Ni NXDOMAINou NODATA par eux - mêmes se traduira par un délai d' attente lorsque rencontré dans ce cas, mais votre bibliothèque resolver se déplacera probablement d'ici à annexant le suffixe de recherche DNS, qui peut à déclencher transformer un délai d' attente pour les serveurs DNS du domaine de recherche.

Il convient de noter que rien de tout cela n'explique pourquoi vous avez rencontré une SERVFAILréponse lors de la recherche mysql.xavamedia.nl.. Cela indique un problème avec le serveur récursif obtenant la réponse des serveurs faisant autorité. Soit le serveur faisant autorité a répondu par SERVFAIL, le serveur récursif n'a pu atteindre aucun des serveurs faisant autorité, soit le serveur récursif a déterminé que les données renvoyées n'étaient pas valides. Rien de tout cela ne peut être prouvé avec les informations que vous avez fournies.

— Andrew B
source

Merci pour votre réponse détaillée! Certaines choses ne sont toujours pas claires: si la réponse NODATA est initiée par le serveur faisant autorité, mon hébergement DNS a un problème, car ces domaines existaient depuis longtemps (en vertu d'un enregistrement générique A). Alors, mon autre question est, comment pourrais-je prouver si le serveur faisant autorité a fait quelque chose de mal?

— djc

La NODATAcapture de vos paquets en est la preuve. La question pertinente est "pourquoi un serveur faisant autorité a-t-il répondu et dit qu'aucun tel enregistrement n'existait?" . Malheureusement, c'est un problème difficile à appuyer, sauf si vous pouvez le prouver avec des recherches directes contre les serveurs faisant autorité (supprimant la possibilité de hausser les épaules et de blâmer les opérateurs des serveurs récursifs), en gardant à l'esprit qu'un seul des trois peut parfois se conduire mal.

— Andrew B

NODATAsignifie que le nom ne existe, mais elle ne dispose pas d'enregistrement du type demandé. Par exemple, vous demandez un Aenregistrement, mais il n'a qu'un MXenregistrement. Cela peut également se produire si le nom correspond à un nœud intermédiaire dans la hiérarchie DNS et n'a aucun enregistrement propre.

— Barmar

@Barmar Oui, ce qui est dit ici, c'est que le serveur faisant autorité signale une absence de cette paire nom / type d'enregistrement, et djc exprime de la confusion à ce sujet en raison d'un enregistrement générique qui est présent depuis un certain temps.

— Andrew B

Mon commentaire s'adresse à votre premier point "NODATA et NXDOMAIN indiquent tous deux que le nom n'existe pas". NXDOMAINsignifie que le nom n'existe pas, NODATAsignifie que le nom existe mais que le type d'enregistrement demandé n'existe pas.

— Barmar

Je ne connais pas de directives spécifiques à l'exception de celles définies dans la section "6.1.3.3 Utilisation efficace des ressources" de RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77

Une valeur de temporisation de "pas moins de 5 secondes" est spécifiée. Le RFC indique également que les défaillances temporaires doivent être mises en cache. Cela permet d'éviter une quantité excessive de demandes DNS si les clients violent la section 2.2 de la RFC. Cette section stipule que les clients doivent attendre un délai «raisonnable» entre les tentatives en cas de pannes légères.

Il existe également un fil de discussion Stackoverflow sur ce sujet, mais il ne contient pas beaucoup plus d'informations, à l'exception de certaines observations du monde réel. /programming/3036054/ideal-timeout-period-for-dns-lookup

C'est tout ce que je peux dire sur ce sujet. Si quelqu'un d'autre a plus à ajouter, je serais également intéressé.

— Janek Bevendorff
source