Fehler beim Debuggen der DNS-Auflösung

Ich debugge einen DNS-Auflösungsfehler für die Domain auth.otc.t-systems.commit dem Cloudflare-Server, stecke aber fest. Das Seltsame ist, dass die Suche je nach dem Computer, auf dem die Abfrage ausgeführt wird, erfolgreich ist / fehlschlägt, aber ich kann nicht herausfinden, wo sich die Konfiguration unterscheidet.

Der Fehler tritt immer mit der folgenden Meldung auf: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 ist das DNS von Cloudflare.

Was ich bisher versucht habe:

Laufen nslookup auth.otc.t-systems.com 1.1.1.1auf verschiedenen Maschinen:
- Auf meinem Computer mit Work & Home Internet schlägt dies fehl (in beiden Fällen ist es jedoch mit Googles DNS erfolgreich).
- Auf einem Kollegencomputer mit Arbeitsinternet schlägt dies fehl.
- Es ist erfolgreich in einer SSH-Sitzung zu einem Remote-Server.
Jetzt würde ich annehmen, dass es in unserem Arbeitsinternet eine seltsame Konfiguration gibt, die dazu führt, dass die Suche fehlschlägt. Ich weiß jedoch nicht, wonach ich suchen soll, und ich habe auch einige Online-nslookup-Dienste gefunden, die ebenfalls fehlschlagen:
- Fehler: 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
- Funktioniert: http://www.kloth.net/services/nslookup.php

Irgendwelche Hinweise, wie ich das weiter debuggen kann?

networking domain-name-system

— Thomas Obermüller
quelle

Haben Sie es auch mit 1.0.0.1oder wenn Sie IPv6 haben 2606:4700:4700::1111und 2606:4700:4700::1001, sind sie alle auch CloudFlare. Schauen Sie sich auch blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally und den letzten Absatz an, in dem Sie Möglichkeiten finden, das Problem zu melden.

— Patrick Mevzek

Antworten:

Versuchen Sie es mit dig. Vor zwanzig Jahren haben sie versucht, nslookup zu missbilligen, aber es ist jetzt fest im Muskelgedächtnis verankert und unmöglich loszuwerden, aber dig ist weit überlegen. Zum Beispiel.

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

Verfolgt die Auflösung vollständig für Sie und Sie können sehen, wo sie sich unterscheiden.

— Sirch
quelle

Danke, das wusste ich nicht über nslookup. Ich habe jetzt den Befehl dig ausprobiert und seltsamerweise gibt er die richtige IP auf meinem Computer zurück. Ich habe die Ausgabe des Befehls sowohl auf meinem Computer als auch auf dem lokalen Computer hier veröffentlicht . Gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Was auch immer dig anders macht, mein Browser (Chrome auf Mac) scheint eher mit nslookup übereinzustimmen - er kann die Adresse nicht auflösen.

— Thomas Obermüller

Es gibt keinen Grund, zwischen digund nslookupfür diese Abfrage unterschiedliche Ergebnisse zu erwarten . Da es sich jedoch 1.1.1.1um eine Anycast-Adresse handelt, kann das Ergebnis je nach Server, von dem die Abfrage bereitgestellt wird, unterschiedlich sein.

— Kasperd

Chrome, ein Webclient zu sein, leitet Sie möglicherweise weiter. Zeigt der http-Header ... curl -I <die Webseite, auf die Sie zugreifen möchten> etwas über die Weiterleitung an?

— Sirch

Was bringt es, beide +traceund zu verwenden @1.1.1.1? Sind Sie sicher, dass Sie verstehen, wie diese Optionen zusammenarbeiten?

— Barmar

Ja, ich bin sicher, ich verstehe, wie diese zusammenarbeiten. Der Sinn der Verwendung von @ <Adresse> besteht darin, die DNS-Server anzugeben, die sein Client an den beiden Standorten verwendet. Im angegebenen Beispiel handelt es sich um Cloudflare, aber wenn ein anderer Client einen anderen DNS-Server verwendet, wird dieser dort angegeben. Wenn ich zum Beispiel bin, ist die Serveradresse in resolv.conf eine Firmenadresse, aber ich kann sie immer noch von 1.1.1.1

— Sirch

Netzwerk-Benutzer verwenden seit 1.1.1.1 Jahren als Ersatz für eine andere private Adresse in zufälligen Schnittstellen von Switches / Router-APs. (Ich bin selbst an einem Ort, an dem die öffentlich zugängliche IP-Adresse der Hunderte von drahtlosen APs 1.1.1.1 lautet.)

Ich wette mein Geld in den Maschinen, die Sie nicht mit Cloufares 1.1.1.1 sprechen können, dass Sie dort eine (unmittelbare) Route für eine solche Schnittstelle haben.

In meinem Fall gibt mir 1.1.1.1 beispielsweise meine IP-Adresse:

$ 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
quelle

Aus diesem Grund müssen RFC 3849 und RFC 5737 strikt durchgesetzt werden.

— Kasperd

"Zu niedrig" ist jedoch eine schwierige Grundlage, um etwas zu bestimmen. Cloudflare hat viele PoPs. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msist meine RTT zur realen Sache.

— Håkan Lindqvist

@ HåkanLindqvist Ihr Wert ist eine zu geringe Verzögerung für eine externe Verbindung scheint .... aber ja, kein zuverlässiger Metrik.

— Rui F Ribeiro

@RuiFRibeiro Die Latenz scheint für Konnektivität in derselben Stadt ohne Verbindung mit hoher Latenz ungefähr richtig zu sein. (Traceroute zeigt 4 Adressen in meinem ISP, eine Cloudflare-Adresse bei einer Internet-Vermittlungsstelle in meiner Stadt, dann 1.1.1.1.)

— Håkan Lindqvist

Es scheint, dass ich das Cloudflare-DNS erreichen kann, nur dass es für die Domain für mich fehlschlägt. Ich habe nslookup für auth.otc.t-systems.comund ausgeführt serverfault.com. Hier ist das Ergebnis von tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller