Timeouts/Latenzen bei Hetzners eigenen DNS

GwenDragon

GwenDragon

Registered User
Ich hab hier einen Minimal-vServer, der braucht manchmal bis zu 9 Sekunden zu Auflösung einer IP zum Hostname.
Hat Hetzer so einen hohen Load auf seinen NS, dass die Antwortzeit so lang ist?

Lässt sich gut nach verfolgen, wenn man sowas in der Shell in einer foo-Loop laufen lässt
host -v 91.15.42.30
Oft wechselt da die Auflösung zwischen dem dem NS .98 und .99 her, wenn es da nicht passt auch mal der .100 oder überhaupt SERVFAIL.
In jedem Fall dauert es bei derselben IP manchmal 3-8 Sekunden oder komplett fail.

host liefert aber über einen externen NS wie 8.8.8.8 so schnell wie gewünscht.
host -v 91.15.42.30 8.8.8.8

Die bei Hetzner übliche resolve.conf:
Code: 
search your-server.de
nameserver 213.133.98.98
nameserver 213.133.99.99
nameserver 213.133.100.100
nameserver 2a01:4f8:0:a0a1::add:1010
nameserver 2a01:4f8:0:a102::add:9999
nameserver 2a01:4f8:0:a111::add:9898

Sind die langsamen NS ein Problem in Hetzners Netzwerk? Was ist eure Meinung? Bevor ich den Support löcher was gerade los ist bei denen, möchte ich euch erst mal Fragen was ihr für Erfahrungen habt.
Ich freu mich auf Antworten.
 
Interessanterweise betrifft die extrem verzögerte Auflösung nur DTAG-IPs.
Wirklich rätselhaft.

Muss Montag mal weiter prüfen und einen Trace per dig machen.
 
Last edited:
@nevakee Danke. Ich lese da mal morgen rein.

Ansonsten Paketloss hab ich keinen bei zu TCom laut mtr rein in DC13 und raus, nur die grauenhaften Responses der Telekom-NS ans Hetzner-Netz.

Einzige Lösung sieht wohl so aus bei dem vServer die resolve.conf in andere namserver zu ändern.

Ich werde am Montag ein Ticket schrieben an Hetzner.
 
Last edited:
So, Ticket ist raus. Bin gespannt ob mal das Peering an T-Com und/oder die NS bei Hetzner schuld sind. Ich geb dann Bescheid wenn ich mehr weiß.
 
Ich kann bei sowas nur noch den Kopf schütteln:

Code: 
root@s44 ~ # nslookup 91.15.42.30
;; Got SERVFAIL reply from 213.133.98.98, trying next server
;; connection timed out; no servers could be reached

root@s44 ~ # time nslookup 91.15.42.30
;; connection timed out; no servers could be reached


real    0m21.018s
user    0m0.016s
sys     0m0.000s

root@s44 ~ # time nslookup 185.26.182.104
Server:         213.133.98.98
Address:        213.133.98.98#53

Non-authoritative answer:
104.182.26.185.in-addr.arpa     name = opera.com.

Authoritative answers can be found from:
182.26.185.in-addr.arpa nameserver = nic1.opera.com.
182.26.185.in-addr.arpa nameserver = nic2.opera.com.
182.26.185.in-addr.arpa nameserver = nic3.opera.com.
182.26.185.in-addr.arpa nameserver = nic4.opera.com.


real    0m0.016s
user    0m0.008s
sys     0m0.004s

# time nslookup 217.160.72.6
Server:         213.133.98.98
Address:        213.133.98.98#53

Non-authoritative answer:
6.72.160.217.in-addr.arpa       name = www.1und1.de.

Authoritative answers can be found from:


real    0m0.015s
user    0m0.012s
sys     0m0.000s
 
Last edited:
Manchmal ist der Hetzer-Support wirklich allerliebst.
wir haben unsere DNS-Server überprüft, können jedoch kein Problem feststellen.

Sollten Sie noch einmal langsame DNS antworten feststellen dann senden Sie uns bitte einen mit einem Programm wie MTR erstellten Trace über 1000 Pakete in Richtung unserer Nameserver.
Click to expand...

Natürlich sind die IPs der NS intern schnell per ICMP erreichbar.

Code: 
# mtr -rwc 1000 -i 0.2 -rw 213.133.98.98
Start: Mon Sep 23 14:03:03 2019
HOST:    ****************                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- static.46-4-155-177.clients.your-server.de  0.0%  1000    0.3   0.3   0.2  20.2   1.4
  2.|-- core21.fsn1.hetzner.com                     0.7%  1000    0.4   2.0   0.3  61.2   5.1
  3.|-- ex9k2.dc1.fsn1.hetzner.com                  0.0%  1000    0.4   0.4   0.3  25.5   1.4
  4.|-- ns1-coloc.hetzner.de                        0.0%  1000    0.3   0.2   0.2   3.0   0.1

Ist der Loss bei ping über TCP 53 vernachlässigbar? Oder ein Indiz für ein problem?

Code: 
root@sv2 ~ # mtr -rwc 100 -P 53 -t -rw 213.133.98.98
Start: Mon Sep 23 14:13:28 2019
HOST: *******************                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- static.46-4-155-177.clients.your-server.de  0.0%   100    0.3   0.6   0.3   7.6   0.9
  2.|-- core21.fsn1.hetzner.com                     3.0%   100    0.6   2.2   0.3  34.0   5.2
  3.|-- ex9k2.dc1.fsn1.hetzner.com                  0.0%   100    0.4   0.5   0.3   5.0   0.6
  4.|-- ns1-coloc.hetzner.de                        0.0%   100    0.3   0.3   0.2   2.8   0.3
 
Last edited:
Nanu, auf einmal wollen die Hetzner-NS wieder schnell antworten.

Kann sein, dass heute was gefixt wurde bei Hetzners Netzerwerk-Infrastruktur. Aber ob das nun wirklich "Störung am Switch fsn1-dc4-sw_712 " war, weiß ich nicht.

oder das hier:
https://forum.hetzner.com/thread/22547-anbindung-an-telekom-wieder-schlechter-ohne-doublepayment-option/?postID=262022#post262022 said:
Es werden einige DNS-Resolver von Hetzner bei der Telekom blockiert.
Click to expand...
 
GwenDragon said:
Dann interpretiere ich das "Loss%" bei core21 also falsch. Würde aber gern wissen wieso dann da ein Wert steht, wenn keine Request verloren gehen.
Click to expand...

Der Traceroute funktioniert technisch so, dass man ein Paket an die Zieladresse losschickt mit TTL-Value 1. Der erste Router, den dieses Paket erreicht, kann das Paket dann nicht mehr weiter routen und generiert (so ist der Plan) eine ICMP-Nachricht "Time to live exceeded".
Dann schickt man wieder ein Paket, aber diesmal mit TTL 2, welches dann am übernächsten Router abläuft und dieser diese ICMP-Nachricht generiert - und so weiter. Über die Quelladresse der ICMP-Antworten weiß man dann, welchen Weg ein Paket auf Layer 3 nimmt.

Die Generierung dieser ICMP-Nachrichten geschieht bei den meisten Routern auf der normalen CPU, die nicht besonders viel Fuffu hat.
Und wenn der Router gerade was besseres mit der Rechenzeit anfangen kann, wird auf solche vergleichsweise unwichtigen ICMP-Nachrichten verzichtet und wichtige ICMP-Nachrichten bevorzugt.
Dann siehst du vermeintlichen Packetloss oder extrem hohe Latenzen an diesem Hop - in diesem Fall ja sogar beides.

Aber: Das bezieht sich nur auf die Generierung von ICMP-Nachrichten für Pakete, die nicht weitergeroutet werden.
Alle anderen Pakete (mit höherer TTL) betrifft das nicht, da diese auf den Routing-Fabrics direkt verarbeitet werden - die werden ohne Verzögerung und ohne Verluste weiter geroutet, auch wenn die CPU gerade ausgelastet ist.
Solange also nicht gleichzeitig auch an den nachfolgenden Hops identischer Packetloss auftritt, ist das nichts, worüber man sich Sorgen machen muss.
Das sieht man auch daran, dass das Ziel konstant niedrige Latenzzeiten und konstant keinen Packetloss hat ;-)

Wenn der Router an Hop 2 (bzw. TTL 2) keine Zeit für ICMP-Nachrichten hat, wird er dennoch Pakete mit TTL 3, 4, 5... weiter-routen.
Und da von Linux generierte Pakete in der Regel ein TTL-Value von 64 egress am Interface haben, werden die echten DNS-Anfragen durch sowas nicht aufgehalten.
Zusammenfassend kann man also sagen, dass die langsamen Antwortzeiten der DNS-Server höchstwahrscheinlich nicht durch Netzwerkprobleme zwischen dem Kundenserver und dem DNS-Server zustande kommen.

Nichtsdestotrotz ist dieses Ersuchen von Hetzner (was du pejorativ als "herzallerliebst" beschreibst) sinnvoll und richtig - denn da DNS als UDP-Basierter Dienst anfällig auch für geringen Packetloss ist, sollte sichergestellt sein, dass nirgendwo auf der Strecke zwischen deinem Server und dem DNS-Resolver Packetloss auftritt. Das kann auch zwischen deinem Switch und dem Router auftreten. Und bevor Hetzner da im Nebel stochert, sollte man zumindest die Basis-Rahmenbedingungen abstecken ;-)
 
Router müssen Pakete routen; ob sie auf ICMP antworten, ist dafür egal. Paketverluste an einem Router im MTR sind irrelevant, solange die Pakete das Ziel erreichen.

Die Geräte von Juniper beispielsweise priorisieren von Haus aus ICMP auf die Control Plane sehr niedrig. Junos OS macht damit was es möchte, eine exakte Beschreibung des Verhalten der Control Plane für ICMP von Juniper existiert nicht in der Doku. (Nicht nur) deswegen eignet sich ein Ping-Check auch nicht fürs Monitoring eines Routers :)

Deine Probleme liegen sicher nicht im Hetzner-Netz selbst, sondern in der Verbindung zwischen den Resolvern und der Telekom. Für dich sind sie daher via MTR nicht feststellbar.

// Da war jemand schneller; das kommt davon, wenn man den Tab zu lange offen lässt :)
 
@Lord Gurke Danke für deine ausführliche Erläuterung des Routings der Pakete bei ICMP.
Mir war nicht klar wie ich die Verzögerungen zwischen Hetzner-Resolvern und Client-Netz bei der Auflösung hätte mit den normalen Netzwerk-Tools prüfen können. Ich geben zu bei solchen Problemen fehlt mir die Erfahrung mit Trafficanalyse.

@PHP-Friends Auch dir ein Danke für die Antwort. Mir war nicht klar, dass die Router so ein Verhalten zeigen und Monitoring per ICMP wenig aussagt.
Dass es eben bei Hetzner-Resolvern Probleme geben könnte, war ja nur eine Vermutung, und die einzige Möglichkeit wo ich hätte einwirken können, notfalls durch andere IPs für Resolver.

Mittlerweile haben sich die Verzögerungen zwischen den Hetzner-Resolvern und Telekom gegeben ohne dass ich was an der Netzwerkkonfiguration der drei Server, auf denen ich das Problem über Tage (seit 19.10.) nachvollziehen konnte, geändert habe.
Das Problem lag wohl auf Seite der DTAG.

Ich bin nicht diejenige, welche die Verantwortung solcher Probleme dem Serverhoster zuschiebt, ich suche auch immer zuerst und länger bei mir nach dem Denkfehler oder der Fehlkonfiguration (in diesem Fall gab es aber keine).

Ein herzliches Danke an Alle, die mich hier mit Tips und Hintergrundinformationen unterstützt haben.
 
Laut des Posts eines Kunden im Hetznerforum (war eine Antwort des Hetzner-Supports auf dessen Ticket) blockierte die DTAG tatsächlich diverse Hetzner-IPs auf ihre DNS.
Kann ja wohl nicht angehen, als Kundin der Telekom bin ich verärgert von so einem Verhalten andere Anbieter zu benachteiligen oder zu sperren.
 
You must log in or register to reply here.
Back
Top