DNS-Server der Telekom extrem langsam und mit kurzer Cache-Haltezeit
vor 3 Jahren
Hallo Support,
mein V-DSL-100-Anschluss bekommt von euch folgende DNS-Server zugewiesen:
nameserver 217.237.151.205
nameserver 217.237.148.70
Beide Server benötigen für jede neue Hostabfrage 3 bis 4 Sekunden. Das Ergebnis bleibt auch nur für wenige Minuten im Cache , dann dauert es wieder so lange. Beispiele:
leela:~ # time nslookup www2.shopdriver.de 217.237.151.205
Server: 217.237.151.205
Address: 217.237.151.205#53
Non-authoritative answer:
Name: www2.shopdriver.de
Address: 146.0.237.226
real 0m3.056s
user 0m0.000s
sys 0m0.006s
leela:~ # time nslookup www2.shopdriver.de 217.237.148.70
Server: 217.237.148.70
Address: 217.237.148.70#53
Non-authoritative answer:
Name: www2.shopdriver.de
Address: 146.0.237.226
real 0m3.051s
user 0m0.005s
sys 0m0.002s
Zum Vergleich hier die Abfragen über den Public DNS von Google:
leela:~ # time nslookup www2.shopdriver.de 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: www2.shopdriver.de
Address: 146.0.237.226
real 0m0.051s
user 0m0.000s
sys 0m0.006s
leela:~ # time nslookup www2.shopdriver.de 8.8.4.4
Server: 8.8.4.4
Address: 8.8.4.4#53
Non-authoritative answer:
Name: www2.shopdriver.de
Address: 146.0.237.226
real 0m0.048s
user 0m0.006s
sys 0m0.000s
Es liegt nicht an der Verbindung:
leela:~ # mtr -r 217.237.151.205
Start: 2022-02-01T16:57:41+0100
HOST: leela.expeedo.de Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.2.1 0.0% 10 1.0 1.0 0.8 1.6 0.2
2.|-- p3e9bf413.dip0.t-ipconnec 0.0% 10 8.0 10.4 7.8 22.5 5.0
3.|-- do-ec4-i.DO.DE.NET. DTAG .D 0.0% 10 10.7 9.7 8.6 14.8 1.9
4.|-- do-ec4-i.DO.DE.NET. DTAG .D 0.0% 10 8.4 8.6 8.4 9.0 0.2
5.|-- pd9002772.dip0.t-ipconnec 0.0% 10 8.7 8.8 8.6 9.0 0.2
6.|-- do-lb-a01.isp.t-ipnet.de 0.0% 10 8.7 8.7 8.6 9.1 0.1
leela:~ # mtr -r 217.237.148.70
Start: 2022-02-01T16:58:18+0100
HOST: leela.expeedo.de Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.2.1 0.0% 10 0.2 0.6 0.2 0.9 0.3
2.|-- p3e9bf413.dip0.t-ipconnec 0.0% 10 7.7 8.0 7.7 8.5 0.2
3.|-- d-eb6-i.D.DE.NET. DTAG .DE 0.0% 10 9.8 12.7 9.8 32.7 7.1
4.|-- pd9002712.dip0.t-ipconnec 0.0% 10 10.5 10.8 10.4 12.5 0.6
5.|-- d-lb-a01.isp.t-ipnet.de 0.0% 10 9.5 9.7 9.5 10.1 0.2
Mit besten Grüßen
Michael Balzer
11254
7
Das könnte Ihnen auch weiterhelfen
1677
0
2
1715
2
6
vor 5 Jahren
575
0
3
vor 3 Jahren
@balzer
Was für einen Router nutzt Du?
Auf der Fritzbox nutze ich die Cloudflare DNS Server:
Das sind die schnellsten DNS Server, und vor allem im Datenschutz sehr gut.
3
Antwort
von
vor 3 Jahren
Es tut eigentlich zwar nichts zur Sache, aber mein Router ist ein Vigor 2760.
Jeder public DNS ist ein Datenschutz-GAU, und der Unfall wächst mit der Anzahl der User, die diesen nutzen. Cloudflare insbesondere (und jeder ähnliche Anbieter) setzt hier noch eine Dimension drauf wenn man eine über Cloudflare laufende Website aufruft, da durch den entschlüsselnden Proxy Cloudflare jedes Passwort mitschneiden kann. In der IT nennen wir so etwas einen Man-in-the-middle-Angriff, und dass es als Dienstleistung verpackt wird und von den Website-Betreibern bezahlt wird macht es keinen Deut besser.
Antwort
von
vor 3 Jahren
Die heute gängigen Antivirenprogramme machen das auf Client-Seite aber leider auch, mit eigenen Zwischenzertifikaten brechen die TLS/SSL auf und führen https ins Leere.
Ich nutze hier auf der pfSense den Unbound im Resolver Modus, der fragt also die Root- und Authorized-Server an und cached das Ganze auch gut.
Antwort
von
vor 3 Jahren
Unbound ist eine gute Lösung für ein lokales Netz, aber das Problem der langsamen DNS-Auflösung betrifft ja alle Telekom-Kunden, die "einfach nur" surfen wollen, und indirekt so auch alle Web-Anbieter.
Uneingeloggter Nutzer
Antwort
von
vor 3 Jahren
Hallo Michael,
Diese Domain hat Fehler, die dazu führen, dass die DNS Resolver u. U. lange brauchen, um aufzulösen (timeouts). Einer der autoritativen DNS Server antwortet nicht auf Anfragen via UDP. Das war vermutlich der Grund für die lange Zeit.
Siehe auch
https://dnsviz.net/d/www2.shopdriver.de/dnssec/
Darüber hinaus ist "nslookup" kein geeignetes Werkzeug (mehr) für DNS Diagnose. In deinem Fall schickt es nicht nur eine Query (A), sonden 2 (A und AAAA), ohne dass du das erfährst.
Siehe auch
https://groups.google.com/g/comp.protocols.dns.bind/c/B3tgs8nb4Rg/m/fxM3qp48520J
Das beste Tool für DNS Diagnose ist "dig".
Da musst du auch nicht die Zeit separat messen.
Winfried
2
Antwort
von
vor 3 Jahren
Hallo Winfried,
Danke, Dein Hinweis hat einen Fehler in unserem Glue-Record offenbart, dieser wurde beim letzten DNS-Serverumzug nicht aktualisiert.
Der UDP-Fehler des Test-Tools stammte vom Zugriff auf die veraltete IP. Ich kann leider nicht mehr prüfen ob das die wirkliche Ursache war, oder die Telekom ihre DNS-Konfiguration in den letzten fünf Monaten optimiert hat. Andere DNS-Server, etwa Google & Cloudflare, hatten das Problem ja nicht.
Die o.g. Telekom-DNS arbeiten jedenfalls aktuell wieder normal schnell.
Michael
Antwort
von
vor 3 Jahren
Hallo Michael,
freut mich dass ich helfen konnte.
Ich kann leider nicht mehr prüfen ob das die wirkliche Ursache war, oder die Telekom ihre DNS-Konfiguration in den letzten fünf Monaten optimiert hat. Andere DNS-Server, etwa Google & Cloudflare, hatten das Problem ja nicht.
Ich kann leider nicht mehr prüfen ob das die wirkliche Ursache war, oder die Telekom ihre DNS-Konfiguration in den letzten fünf Monaten optimiert hat. Andere DNS-Server, etwa Google & Cloudflare, hatten das Problem ja nicht.
Es sieht ganz danach aus, dass das die Ursache war. Es war immer noch reproduzierbar. Dass andere Resolvers das nicht gestört hat, kann mehrere Ursachen haben. Zum Beispiel, dass dort vorzugsweise IPv6 verwendet wird. Oder dass die Nichterreichbarkeit des DNS Servers bereits in deren Cache war. Das war übrigens auch bei uns so. Nur jeweils die erste Anfrage lief in den Timeout. Die Resolver "lernen" welche DNS Server einer Zone am schnellsten antworten und welche nicht erreichbar sind. Von Zeit zu Zeit wird dann ein re-probing gemacht....
Winfried
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Frage
von