Erreur de résolution de débogage DNS

Je débogue une erreur de résolution DNS pour le domaine auth.otc.t-systems.comavec le serveur de Cloudflare, mais je suis resté bloqué. La chose étrange est que la recherche réussit / échoue selon la machine qui exécute la requête, mais je ne peux pas comprendre où la configuration diffère.

L'échec est toujours avec le message suivant: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 est le DNS de Cloudflare.

Ce que j'ai essayé jusqu'à présent:

Fonctionnant nslookup auth.otc.t-systems.com 1.1.1.1sur différentes machines:
- Il échoue sur ma machine avec Internet professionnel et domestique (mais il réussit avec le DNS de Google dans les deux cas).
- Il échoue sur une machine de collègues avec Internet de travail.
- Il réussit dans une session ssh sur un serveur distant.
Maintenant, je suppose qu'il existe une configuration étrange sur notre Internet de travail, ce qui entraîne l'échec de la recherche. Cependant, je ne sais pas ce que je dois rechercher et j'ai également trouvé des services nslookup en ligne qui échouent également:
- Échec: https://network-tools.com/nslook/Default.asp?domain=auth.otc.t-systems.com&type=1&server=1.1.1.1&class=1&port=53&timeout=5000&go.x=21&go.y=13
- Œuvres: http://www.kloth.net/services/nslookup.php

Des conseils sur la façon de déboguer davantage?

networking domain-name-system

— Thomas Obermüller
source

Avez-vous également essayé avec 1.0.0.1ou si vous avez IPv6 2606:4700:4700::1111et 2606:4700:4700::1001, ils sont tous également CloudFlare. Regardez également blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally et son dernier paragraphe donnant des moyens de signaler le problème.

— Patrick Mevzek

Réponses:

Essayez d'utiliser dig. Il y a vingt ans, ils ont essayé de déprécier nslookup, mais il est fermement ancré dans la mémoire musculaire maintenant et impossible de s'en débarrasser, mais creuser est de loin supérieur. Par exemple.

dig +trace auth.otc.t-systems.com @1.1.1.1

Tracera la résolution entièrement pour vous, et vous pourrez voir où elles diffèrent.

— Sirch
source

Merci, je ne savais pas cela à propos de nslookup. J'ai maintenant essayé la commande dig et, étrangement, elle renvoie l'ip correcte sur ma machine. J'ai publié la sortie de la commande sur ma machine et sur la machine locale ici gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Quelle que soit la fouille, mon navigateur (Chrome sur Mac) semble être plus conforme à nslookup - il ne peut pas résoudre l'adresse.

— Thomas Obermüller

Il n'y a aucune raison de s'attendre à des résultats différents entre diget nslookuppour cette requête. Cependant, comme il 1.1.1.1s'agit d'une adresse anycast, le résultat peut différer selon le serveur sur lequel la requête finit par être servie.

— kasperd

Chrome, être un client Web peut vous rediriger. L'en-tête http ... curl -I <la page Web que vous essayez d'accéder à> révèle-t-il quelque chose à propos du transfert?

— Sirch

Quel est l'intérêt d'utiliser les deux +traceet @1.1.1.1? Êtes-vous sûr de comprendre comment ces options fonctionnent ensemble?

— Barmar

Oui, je suis certain de comprendre comment ces éléments fonctionnent ensemble. Le point d'utilisation de @ <address> serait de spécifier les serveurs DNS que son client utilise aux deux emplacements. Dans l'exemple donné, son cloudflare est, mais si un autre client utilise un autre serveur DNS, il y serait spécifié. Par exemple, où je suis, l'adresse du serveur dans resolv.conf est celle de l'entreprise, mais je peux toujours résoudre à partir de 1.1.1.1

— Sirch

Les gens du réseau ont utilisé pendant les âges 1.1.1.1 en remplacement d'une autre adresse privée dans les interfaces aléatoires des commutateurs / routeurs AP. (Je suis moi-même sur un emplacement en ce moment où l'adresse IP publique des centaines de points d'accès sans fil est 1.1.1.1)

Je parie que mon argent dans les machines que vous n'êtes pas en mesure de parler au 1.1.1.1 de Cloufare que vous avez une route (intermédiaire) pour une telle interface.

Par exemple, dans mon cas, 1.1.1.1 me donne mon adresse IP:

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296

— Rui F Ribeiro
source

C'est pourquoi les RFC 3849 et RFC 5737 doivent être rigoureusement appliquées.

— kasperd

"Trop bas" est cependant une base délicate pour déterminer quoi que ce soit. Cloudflare a beaucoup de PoPs. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msest mon RTT à la vraie chose.

— Håkan Lindqvist

@ HåkanLindqvist Votre valeur ne semble un retard trop faible pour une connexion externe .... mais oui, pas une mesure fiable.

— Rui F Ribeiro

@RuiFRibeiro Latency semble à peu près approprié pour une connectivité dans la même ville sans lien à haute latence. (Traceroute affiche 4 adresses au sein de mon FAI, une adresse Cloudflare dans un échange Internet dans ma ville, puis 1.1.1.1.)

— Håkan Lindqvist

Il semble que je puisse atteindre le DNS Cloudflare, mais il échoue pour le domaine pour moi. J'ai exécuté nslookup pour auth.otc.t-systems.comet serverfault.com. Voici le résultat de tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller