Erreichbarkeit Domain / TTL Probleme ?

magejo

magejo

Registered User
Hallo!

ich habe eine .COM-Domain, die auf die IP meines Servers verweist. Das klappt auch problemlos. - bis auf Ausnahmen, dessen Logik ich noch nicht nachvollziehen kann.

Ab und an ist die Domain nicht erreichbar - was sich paar Minuten hinzieht - bei einen Reload geht es danach am gleichen Anschluss wieder. Passiert das z.B. am iPhone, schalte ich WLAN ab und nutze das Mobilfunknetz - dann geht die Seite auch wieder. Gleiches passiert und klappt auch andersherum.

Das Problem tritt an unterschiedlichen DSL Anschlüssen auf (Vodafone, Telekom, 1&1) - wartet man einige Minuten ab und startet die Seite mittel Reload erneut, geht es wieder.

Woran kann es liegen? An der TTL der Domain selbst wohl kaum ?
Wo setzt man an?

Der Server geht übrigens zeitgleich jedesmal problemlos.
 
Wie manifestiert sich das Problem spezifisch? Lädt die Seite sich einfach tot oder kann die Domain nicht aufgelöst werden?
 
Du kannst auch prüfen ob die NS-Auflösung korrekt läuft:
dig +trace @999.999.999.999 DOMAIN.TLD
dig +trace @localhost DOMAIN.TLD
Zum prüfen anstatt 999.999.999.999 die IP eines offenen NS, deines Server-DNS, deines Routers, deines ISP-NS.
 
Irgendwie frage ich wohl gerade das Universum, oder?
Und was sagt nun dig mit einem Trace vom Server aus und deinem lokalen Rechner? Wenn du es öfters mnal alaufen lässt.

Meine Erfahrung war, dass die DN-Auflösung manchmal verschiedene Ergebnisse zeigt wenn nicht alle NS die aktuellen Daten gesynct haben.
Oder was schlimmer ist: jemand hat noch einen NS aufgesetzt mit anderen Daten aber deiner Domain.
 
Last edited by a moderator:
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6 <<>> @8.8.8.8 blxxxxxxxxxxxxxn.com ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62308
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;blxxxxxxxxxxxxxxxxxxn.com. IN ANY

;; ANSWER SECTION:
blxxxxxxxxxxxxxxxxxxxn.com. 3599 IN A 178.77.xxx.x


;; Query time: 192 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 28 11:20:17 2018
;; MSG SIZE rcvd: 94
 
Ist das ein Trace? Sehe ich nicht. Mich hätte eigentlich interessiert über welche NS die Auflösung bei verschiedenen DNS so läuft.
Dann belassen wir es dabei. Muss dir jemand anders helfen, wenn du nicht mehr antworten kannst.
 
Sorry, dig hatte ich noch nie in Nutzung:

; <<>> DiG 9.9.5-3ubuntu0.17-Ubuntu <<>> +trace @8.8.8.8 blog.mercedes-benz-passion.com
; (1 server found)
;; global options: +cmd
. 206156 IN NS m.root-servers.net.
. 206156 IN NS b.root-servers.net.
. 206156 IN NS c.root-servers.net.
. 206156 IN NS d.root-servers.net.
. 206156 IN NS e.root-servers.net.
. 206156 IN NS f.root-servers.net.
. 206156 IN NS g.root-servers.net.
. 206156 IN NS h.root-servers.net.
. 206156 IN NS i.root-servers.net.
. 206156 IN NS a.root-servers.net.
. 206156 IN NS j.root-servers.net.
. 206156 IN NS k.root-servers.net.
. 206156 IN NS l.root-servers.net.
. 206156 IN RRSIG NS 8 0 518400 20180907170000 20180825160000 41656 . VbJ2b/xlg35tbzBHSm0hmek+A8DZ2KLEZmvYb9Lty48B0GXCmJ1/HsBG EeZEV9hxL5vQ/PaH/QdE1hI0c3LqxWWDT0zTmTiYVBF6auCqKf+aW2AO kyWtCUFct1cvQfbAO7AxlOndeIblGvE6ooSXK3XbkrPG78dm06y0phc+ AKrBx4ZHu1qC3VNjNCQ5xyt/P7Im/Bp8kCtZyYzfItl02cwO1FbdS0aF V+ebd8DGusuvOzSuuwGuyT3MjAVwiYHJQjzcg/aVBSAS2qDeu4LVqO7N vWFuiq488gv4I9b1krvjjqh9Rt/fsLjio+7q+bKrNEqM7k1VjT+d+ymM Awtakg==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 500 ms

com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20180910050000 20180828040000 41656 . iUOMS1sDAQHMjI17fp2vDOm+wT6Z6v/iEeVyQ59m7OVPFzVB1cVTG7cy kDcD1yHmqILhnAiFV/CYg13cZ2XTe0+UEvw0mO7jqaPloc+4zWHf0NGM Ep8veQLjOgSmORUQTaRkPQ24OYI3kpF6+AkNCBfkq9IMdwmziq7HhiSo gJEjW7LrtwkWzaR+jHBGz4zHXoXM7bE4tiDXYJXSPHpLe5KjeFKzBimx QNV+2X6Vx7hz9jvbpjyYZqCLafckDW6++UcaS/veCe/80IpUpLffikM4 RUN6v3irTPgk5pRUdVrsPiHYfDsm/ed0wXdaENZbselhhPagGaWSXitD tVfU/Q==
;; Received 1190 bytes from 198.41.0.4#53(a.root-servers.net) in 114 ms

mercedes-benz-passion.com. 172800 IN NS ns1.corpinter.net.
mercedes-benz-passion.com. 172800 IN NS ns2.corpinter.de.
mercedes-benz-passion.com. 172800 IN NS ns3.corpinter.net.
mercedes-benz-passion.com. 172800 IN NS ns4.corpinter.de.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20180901044508 20180825033508 46475 com. lYz9DxGlAM+QMcHa6AjjWj3UHjFRLGHnJ3oN8UG6iTeoxwvPXMK+l+Tt ZJk3lHD/pYmWk4T4xQe2RdFQl9ccdkbLbunYoJVoApa94GVJ/7Nk74zs rB32keLDIklgdG+hhkfFLn8o1hIAAFtRBjIhQBcL9YiVjGY26yt/zlYw 3P8=
CM43QVE9T1F6U8ST86KDJQ93LAK1J211.com. 86400 IN NSEC3 1 1 0 - CM44IML7B2T3LLS3E7R0HH5LLAIGUFHS NS DS RRSIG
CM43QVE9T1F6U8ST86KDJQ93LAK1J211.com. 86400 IN RRSIG NSEC3 8 2 86400 20180904103802 20180828092802 46475 com. quyne2ePG5AvTPQdCx82dGO4V+xcTADfABQnt4wWy5OgXekD7XaSxE7w lQl1gqrWn2UeLh77zlROudvGI2Offjsarzdjk6RtUbT62McLE/JYMYs6 C5Xnd9GlZj1ulfuJ0zJltWk4wlex+mBMrwQS2gSkhBsnGgZndKF1Tb9a sqs=
;; Received 701 bytes from 192.48.79.30#53(j.gtld-servers.net) in 47 ms

blog.mercedes-benz-passion.com. 3600 IN A 178.77.113.6
mercedes-benz-passion.com. 3600 IN NS ns4.corpinter.de.
mercedes-benz-passion.com. 3600 IN NS ns1.corpinter.net.
mercedes-benz-passion.com. 3600 IN NS ns2.corpinter.de.
mercedes-benz-passion.com. 3600 IN NS ns3.corpinter.net.
;; Received 320 bytes from 141.113.8.53#53(ns2.corpinter.de) in 9 ms
 
Mal ins Blaue geschossen:

Auf Grund des Bekanntheitsgrades des Blogs und des derzeitigen politischen wie wettbewerblichen Drucks auf den im Blog thematisierten Automobilherstellers, welcher vorsätzlich gegen geltendes Recht und Kartellabsprachen verstösst, würde ich durchaus auch Dinge wie (D)DoS (z.B. überlastete Loadbalancer oder Firewalls) oder Engpässe der Router/Switche im RZ in Betracht ziehen.

Nur so als potentielle Ursachenquelle in den Raum geworfen...
 
Auf Grund des Bekanntheitsgrades des Blogs und des derzeitigen politischen wie wettbewerblichen Drucks auf den im Blog thematisierten Automobilherstellers
Click to expand...
Soweit auf den ersten Blick ersichtlich geht es hier um einen HostEurope VPS mit Apache2.x Webserver inklusive Keep-alive und und dem aktuellen Wordpress 4.9.8. Ich *denke* dass es da einfachere Überlastungsmethoden geben sollte als den DNS-Server zu attackieren.
Ein regulärer SYNFlood, Slowloris, Memoryflood oder die Vorschlaghammer-Methode Packet-Flood sollten jeweils einfacher und effizienter sein. Ich kann aber das ohne Angriff natürlich nur vermuten. DNS-Server zu überlasten ist deutlich schwerer.

Aus jahrelanger Erfahrung mit DDOS-Leiden kann ich aber nur berichten dass die Nameserver wohl nicht grundlos deutlich seltener Ziel von Angriffen geworden sind als die Webserver / Loadbalancer / Filter-Gateways.

oder Engpässe der Router/Switche im RZ in Betracht ziehen.
Click to expand...
Aufgrund der allgemeinen Resilienz von DNS und den 4 unterschiedlichen Nameserver welche scheinbar von Keyweb betrieben werden halte ich das für recht unwahrscheinlich.

Ich würde mal aus dem Stegreif behaupten dass entweder deine NS-Zone defekt ist (dazu den Anbieter kontaktieren, sieht aber unwahrscheinlich aus) oder dass es trotz Beschreibung kein Problem der DNS-Auflösung sondern des Verbindungsaufbaus zum Server ist.
Insbesondere einige Apache-Konstellationen und PHP-Session Konfigurationen führen zu strikt serieller Abarbeitung der Verbindungen von einem Client und wenn eine Verbindung hängt, hängt alles von dem Client.
 
Dass es eben nicht am DNS liegt, wollte ich genau mit meinem Beitrag andeuten.

Wenn es sich tatsächlich um einen VPS (vServer) handelt, dann kommen mehrere dutzend potentielle Problemquellen in Frage und vermutlich werden wir den/die tatsächlichen Ursachen nur schwer, vermutlich eher gar nicht, ausfindig machen.

Das Projekt des OP gehört einfach auf echtes, skalierbares, performantes Blech und nicht auf stinkende vServer.


Wenn es sich beim OP hingegen um echtes Blech handelt, dann wird die Ursache vermutlich eher in den letzten Posts von d4f oder mir zu finden sein, eventuell auch eine Kombination von darin genannten Ursachen.
 
You must log in or register to reply here.
Back
Top