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?
dig/nslookupou une dissection de Wireshark. (tcpdumpne sera pas assez bon) Si vous utiliseznslookup, exécutez d'set debugabord.Réponses:
La réponse vide que vous regardez est un état synthétique appelé
NODATA.NODATAet lesNXDOMAINdeux indiquent que le nom n'existe pas, maisNXDOMAINs'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. (ieexample.test.xavamedia.nl.)Vos points à retenir
NODATAetNXDOMAINsont 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 pourxavamedia.nl.)Ni
NXDOMAINouNODATApar 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 recherchemysql.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 parSERVFAIL, 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.la source
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.NODATAsignifie que le nom ne existe, mais elle ne dispose pas d'enregistrement du type demandé. Par exemple, vous demandez unAenregistrement, mais il n'a qu'unMXenregistrement. 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.NXDOMAINsignifie que le nom n'existe pas,NODATAsignifie que le nom existe mais que le type d'enregistrement demandé n'existe pas.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é.
la source