Certains serveurs DNS dans le monde donnent une mauvaise adresse IP pour notre domaine?

Notre domaine, grahamhancock.com est mal résolu par quelques personnes à travers le monde, mais il se résout correctement pour la plupart des gens.

Lorsque je parcours une liste de fournisseurs DNS ouverts gratuits, environ 90% se résolvent correctement et donnent des informations cohérentes avec notre fichier de zone. 10%, cependant, ne le font pas et prétendent que l'adresse IP est liée à une instance Amazon EC2 que nous n'avons jamais possédée ou utilisée par le passé. Voici quelques exemples de serveurs DNS donnant des informations erronées:

dig www.grahamhancock.com @173.84.127.88
dig www.grahamhancock.com @209.222.18.222

Comment ces serveurs pourraient-ils avoir la mauvaise information, et comment pouvons-nous reprendre le contrôle de la situation?

Serait-ce quelque chose de malveillant ou une mauvaise configuration? Nous sommes un site d'un million de visites par mois, avec de bons classements de recherche, nous sommes donc probablement la cible de quelque chose de malveillant. La mauvaise adresse IP que le serveur erroné renvoie à certaines personnes pointe vers un site get-rich-quick sur une instance AWS EC2.

Que devrions nous faire?

domain-name-system

— Duncan Marshall
source

Est-ce le vrai nom de domaine?

— Drifter104

Oui, c'est le vrai domaine.

— Duncan Marshall

Certains serveurs DNS sont également mal configurés, la question est de savoir pourquoi votre client n'utilise pas son DNS ISP? comme au moins, vous pouvez demander à une hotline de le faire réparer si sur un DNS ISP.

— yagmoth555 - GoFundMe Monica

Nos utilisateurs utilisent les serveurs DNS de leur FAI, mais ces serveurs n'accepteront pas mes requêtes car je ne suis pas leur client. Les serveurs DNS ci-dessus sont publics, donc je les ai utilisés pour tester. S'ils sont mal configurés, ils sont mal configurés de la même manière, et sont soudainement devenus mal configurés, car cela ne se produisait pas hier. Voici l'IP d'un des serveurs DNS de notre FAI: 177.86.168.11. Nos autres utilisateurs n'étaient pas suffisamment réactifs ou compétents pour nous donner l'IP de leur serveur DNS.

— Duncan Marshall

Puis-je en passant remercier profondément l'affiche originale pour avoir inclus le nom de domaine réel dans sa question, plutôt que de le supprimer? Comme j'ai eu l'occasion de le noter auparavant , les questions DNS sont des membres de cette classe, auxquelles il est beaucoup plus facile de répondre rapidement et de manière canonique lorsque la divulgation complète est effectuée, et je pense personnellement que la très haute qualité des réponses à cette question est due en partie à de nombreuses globes oculaires pouvant regarder directement le problème.

— MadHatter prend en charge Monica

Réponses:

Drifter est correct, vous avez un problème de configuration du serveur de noms. Voici la fin de la sortie de dig +trace +additional www.grahamhancock.com:

grahamhancock.com.      172800  IN      NS      ns1.grahamhancock.com.
grahamhancock.com.      172800  IN      NS      ns2.grahamhancock.com.
grahamhancock.com.      172800  IN      NS      server.grahamhancock.com.
ns1.grahamhancock.com.  172800  IN      A       199.168.117.67
ns2.grahamhancock.com.  172800  IN      A       199.168.117.67
server.grahamhancock.com. 172800 IN     A       199.168.117.67
;; Received 144 bytes from 192.35.51.30#53(f.gtld-servers.net) in 92 ms

www.grahamhancock.com.  14400   IN      CNAME   grahamhancock.com.
grahamhancock.com.      14400   IN      A       199.168.117.67
grahamhancock.com.      86400   IN      NS      ns2.grahamhancock.com.com.
grahamhancock.com.      86400   IN      NS      ns1.grahamhancock.com.com.
;; Received 123 bytes from 199.168.117.67#53(ns2.grahamhancock.com) in 17 ms

Vos enregistrements de colle pointent vers une adresse IP de 199.168.117.67, qui renvoie la bonne réponse. Cependant, votre zone définit des enregistrements de serveur de noms se terminant par com.com. Si nous faisons +traceplutôt partie de ces serveurs de noms ...

com.com.                172800  IN      NS      ns-180.awsdns-22.com.
com.com.                172800  IN      NS      ns-895.awsdns-47.net.
com.com.                172800  IN      NS      ns-1084.awsdns-07.org.
com.com.                172800  IN      NS      ns-2015.awsdns-59.co.uk.
;; Received 212 bytes from 192.26.92.30#53(c.gtld-servers.net) in 22 ms

ns1.grahamhancock.com.com. 30   IN      A       54.201.82.69
com.com.                172800  IN      NS      ns-1084.awsdns-07.org.
com.com.                172800  IN      NS      ns-180.awsdns-22.com.
com.com.                172800  IN      NS      ns-2015.awsdns-59.co.uk.
com.com.                172800  IN      NS      ns-895.awsdns-47.net.
;; Received 196 bytes from 205.251.195.127#53(ns-895.awsdns-47.net) in 16 ms

... nous nous retrouvons sur les serveurs de noms hébergés par AWS.

Votre problème est connu sous le nom de décalage d'enregistrement de colle . Les serveurs de noms distants apprennent initialement votre domaine via les enregistrements de collage, mais une fois que ces serveurs distants effectuent une actualisation, ils finissent par interroger les faux serveurs de noms que vous avez définis avec un supplément .comà la fin.

Ce n'est pas votre seul problème. Vous répertoriez la même adresse IP trois fois dans vos enregistrements de colle, ce qui est extrêmement volatile. Vous devez toujours avoir plusieurs serveurs de noms, ils ne doivent jamais partager un sous-réseau ou un homologue de réseau en amont, et ils ne doivent jamais être situés au même emplacement physique. Dans l'état actuel des choses, tout bref problème de routage entre les serveurs DNS et votre serveur unique rendra votre domaine temporairement inaccessible.

Mise à jour:

Ce Q & A a été présenté sur la première page et reçoit beaucoup de commentaires. Malheureusement, cela inclut les personnes qui sont juste un peu trop impatientes de répondre à cette réponse sans vérifier si leurs points ont déjà été traités dans les commentaires étendus.

Le détail que la plupart des gens semblent négliger est le commentaire que je cite ici:

[...] les serveurs DNS géo-redondants empêchent les scénarios où une brève interruption de routage entraîne une mise en cache négative temporaire des serveurs de noms. Si brève que soit la période de mise en cache négative, elle dépassera certainement la durée d'interruption de la connectivité. [...] le nombre de scénarios où le manque de géo-redondance DNS ne créera pas de problèmes de disponibilité sporadiques et difficiles à résoudre est exactement nul.

Si vous pensez que ma compréhension de la mise en cache négative des serveurs de noms est erronée, c'est un jeu ouvert à la discussion, mais en dehors de cela, vous devez apporter quelque chose d'autre que "c'est un petit site et qui se soucie si le site Web et le serveur DNS sont en panne à la fois". Si vous dites cela, vous ne comprenez pas le sujet aussi bien que vous le pensez.

Deuxième mise à jour:

Je suis allé de l'avant et j'ai écrit un Q&A canonique auquel nous pouvons nous lier chaque fois que le sujet du serveur DNS unique revient à l'avenir. Espérons que cela mettra un terme à la question.

— Andrew B
source

Peu importe ce que vous voyez dans le panneau de commande, c'est la réalité. dig @199.168.117.67 grahamhancock.com NSrend cela explicite - que les données proviennent de vos serveurs. Pour ce qui est d'un "problème financier", je vais être franc ici: si vous n'utilisez pas de serveurs DNS redondants, vous n'avez absolument rien à faire avec votre propre DNS. Vous aurez des temps d'arrêt. À moins que vous ne soyez très proche du propriétaire, vous serez responsable de ce temps d'arrêt et de la mise en œuvre de cette configuration.

— Andrew B

Je vous entends, mais c'est hors de mes mains. Quoi qu'il en soit, merci pour l'aide.

— Duncan Marshall

@Bodo Assez juste. Cela dit, vous ignorez toujours le fait que les serveurs DNS géo-redondants empêchent les scénarios où une brève interruption de routage entraîne une mise en cache négative temporaire des serveurs de noms. Si brève que soit la période de mise en cache négative, elle dépassera certainement la durée d'interruption de la connectivité. (ou pour le dire plus simplement car je ne peux pas continuer à répondre à ceci: "bla bla bla DNS bla, le nombre de scénarios où le manque de géo-redondance DNS ne créera pas de problèmes sporadiques et difficiles à dépanner est exactement nul") .)

— Andrew B

Vous pouvez obtenir un hébergement DNS pour 1 $ avec des serveurs NS redondants. Ce n'est pas un choix financier. Ne soyez pas un cow-boy.

— JamesRyan

Il existe de nombreux fournisseurs DNS secondaires gratuits adaptés aux zones à faible charge. Ou comme @JamesRyan l'a dit ci-dessus, on peut payer une (très petite) somme d'argent pour un service géré professionnellement avec une sorte de SLA. Les deux sont des alternatives viables pour les sites à faible trafic.

— un CVn le

L'utilisation des outils suivants donne quelques indices

https://www.whatsmydns.net/#NS/grahamhancock.comsignale que les enregistrements NS sur le point de domaine pour ns1.grahamhancock.com.comremarquer le .com supplémentaire

http://mxtoolbox.com/SuperTool.aspx?action=dns%3agrahamhancock.com&run=toolpage signale également que le même serveur de noms signale qu'il fait autorité.

Si vous regardez ici, http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=grahamhancock.comil indique également que vos serveurs de noms sont ouverts.

Il semblerait donc quelque part le long de la ligne que les serveurs de noms ne sont pas définis correctement. S'ils vous apparaissent correctement via un panneau de contrôle, etc., vous devrez parler au fournisseur afin qu'ils puissent les vérifier sur les serveurs réels.

Ces liens ont également un rapport complet sur les meilleures pratiques et comment les traiter

— Drifter104
source

Et les parasites ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ H ^ Les gens com.comont configuré le DNS générique pour profiter de ce genre d'erreur. Si votre enregistrement NS pointe vers everything.com.com, il répondra à toutes les requêtes reçues de manière à diriger le trafic vers lui. Essayez de dig @anything.com.com anyotherthing.comconsulter l'autorité et les sections supplémentaires de la réponse!