Ein leiser Hilferuf: „Meine Verbindungen auf eine bestimmte Webseite brechen mehrfach am Tag ab“. Aha… Das kann ja so ziemlich alles sein. Spannend, spannend. Die Suche nach der Nadel im Heuhaufen. Ich mag seltene Wunder, genau meine Kragenweite. Dann mal rasch ans Werk. Meine Suche beginnt im Log des Webproxys. Da die Anfragen in dem Fall über den Webproxy laufen ist das die erste Stelle wo es ein Log mit verbindlichen Hinweisen geben kann. Und in der Tat, zum Zeitpunkt des Abbruchs findet sich folgender Auszug im Protokoll:
url=“https://portal..com/“ referer=““ error=“Host not found“
Aha. Host not found? Ein Fehler im DNS? Aber die Verbindung funktioniert doch, sie reist nur immer wieder mal ab. Oder doch eine Leitungsüberlastung? Ein Problem im Webproxy selbst? Ich halte mich in solchen Fällen zunächst an die Fakten. Da steht ein DNS Fehler. Also geht die Suche im nächsten Schritt im DNS weiter. Zeit für Mutmaßungen ist immer noch reichlich falls ich im DNS nichts finden sollte.
Nur wie sucht man so etwas im DNS? Naja, gehen wir mal der Reihe nach durch. Schritt eins sollte sein: Welche Nameserver sind denn überhaupt autoritativ zuständig für die Domain? Das kann man via DNS abfragen in dem man die root Nameserver prüft. Oder man geht den Weg über whois:
whois .com | grep „^Name Server“
Name Server: ns1..com
Name Server: ns3..com
Zwei Nameserver also. Soweit so gut. Also mal rasch abgefragt. Kurze „dig“ Erklärung:
- +short: Beschränke die Ausgabe aufs wesentliche
- @ns1..com: Frage bei diese DNS-Server an. Sinngemäß auch für ns3 anzuwenden
- portal..com: Der anzufragende Eintrag im DNS
Und hier die Aufrufe mit Ergebnis:
dig +short @ns1..com portal. <– Da kam nichts, also kein Ergebnis
dig +short @ns3..com portal. portal…com
Nochmals Aha… Bei ns3 kommt keine IP sondern ein Name? Ok, wer das nicht kennen sollte: Ist ein CNAME. Oder einfach das +short weg lassen. Dann sieht man das Ergebnis in voller Pracht. Aber auch egal, der interessante Punkt: ns3 liefert ein Ergebnis, ns1 nicht. Treffer, versenkt. Das nennt sich „lame server“ im DNS Umfeld und beschreibt die Tatsache, dass ein DNS Server nichts davon weiß, dass er autoritativ zuständig ist für eine Domain. Lame Server haben viele hässliche Seiteneffekte, einer davon kann Verbindungsabbrüche auslösen.
Also gut, jetzt noch rasch die Gegenseite auf das DNS-Problem aufmerksam gemacht. Sobald das bereinigt ist sollte die Verbindung wieder stabil laufen. Ich geh wieder zurück ans Tagesgeschäft. Hoffentlich kommt bald die nächste spannende Herausforderung. Ich freu mich schon 🙂