Seit 2003 hatte ich diverse Root-Server bei einem großen deutschen Hoster angemietet – insgesamt bisher 6 (okay, einer war nur ein virtueller Server). Bei zwei aufgetretenen Defekten (Netzteil und Festplatte) und der Beantragung der IPv6-Tunnel und -Reverse-Delegationen gab es bisher nur positive Erfahrungen mit dem Server-Support dieses Hosters.

Den letzten Monat bemühte sich der Server-Support jedoch, dass sich dieses Bild wandelt, doch von Anfang an:

Anfang März 2010 wurde eine neue Servergeneration mit neuen Preisen angeboten und ich nutzte die Gelegenheit und bestellte einen Nachfolger für einen im Juni auslaufenden Root-Server. Da ich Einrichtungszeiten von mindestens einigen Tagen gewohnt war, überraschte mich die Bereitstellungszeit von nur 2 Stunden. Außerdem überraschte mich, dass die zugeteilte IP-Adresse aus einem Bereich war, der meines Wissens nach bisher nicht für Root-Server verwendet wurde. Aber egal, Adresse ist Adresse, sollte man meinen… Für diverse NNRPD-Instanzen waren noch weitere IP-Adressen notwendig, die dann allesamt wieder aus den bisher „typischen“ Adressbereichen für Root-Server kamen.

Anfang April 2010 stand dann der Umzug meines Primary-DNS auf den neuen Server an. Komischerweise scheiterten diese Umzugsversuche jedoch daran, dass der Secondary-DNS – auch im Netz das großen Hosters befindlich – die Zone-Files nicht von meinem neuen Primary-DNS abrufen konnte.

Verwunderte stellte ich fest, dass von der primären IP-Adresse des Systems aus (die aus dem mir ungewöhnlich erscheinenden IP-Adressbereich) tatsächlich keinerlei Kontakt zum Secondary-DNS (wohlgemerkt auch beim selben Hoster befindlich) möglich war. Auch weitere „neben“ dem Secondary-DNS stehende Hosts und der Router direkt „davor“ waren nicht erreichbar. Von jeder der zusätzlich bestellten IP-Adressen aus funktionierte es jedoch problemlos. Ich dachte mir also: „Okay, liegt halt eine temporäre Routingstörung zu dem einen Adressbereich vor, aber ich hab’s nicht eilig, warten wir mal ein paar Tage ab.“

Am 18. April lag das Problem noch immer vor. Ich entschloss mich, nun den bisher guten Server Support einzuschalten. Kann ja nur eine Kleinigkeit sein… denkste. Zwei Versuche mit dem Kontaktformular scheiterten, weil das System trotz ausgewähltem Thema darauf bestand, dass man ein Thema auswählt, also das ganze nochmal per Mail geschildert und zwei Traceroutes – einmal nicht funktionierend von der primären IP-Adresse und einmal funktionierend von einer zusätzlichen IP-Adresse – angehängt. Der Übersichtlichkeit halber habe ich den Hopcount bei den Traceroutes auf 10 beschränkt, da bereits mit Hop 5 das Problem deutlich wird… erster Fehler.

Am 22. April kam die erste Antwort, ich solle doch Traceroute nicht auf 10 Hops limitieren sondern bei 30 Hops belassen, dann würde es funktionieren. Okay, schicken wir das Ganze halt nochmal mit unbegrenzten Traceroutes. Natürlich hilft es nichts, 30 Hops zuzulassen.

Am 29. April kam die zweite Antwort, ich solle doch ICMP statt UDP verwenden. Hm, das mag dem Supporter geholfen haben, von sich aus per Traceroute Kontakt zu meinen Secondary-DNS aufzunehmen. Ich kann ihn von der primären IP-Adresse aus gar nicht erreichen, und selbst wenn ICMP funktionieren würde: Wie soll man einen DNS-Zone-Transfer per ICMP machen? Also habe ich das Problem in der Antwort nochmal genau geschildert, ich wurde ja wohl falsch verstanden…

Leider habe ich die nun folgende Antwort vom 30. April mit der Bitte um einen Shell-Zugang, um das Problem nachvollziehen zu können, erst am 18. Mai, als die Bitte wiederholt wurde, gesehen und selbigen Zugang sofort eingerichtet, da ich nun Hoffnung hatte, dass man das Problem endlich offensiv angehen möchte.

Am 19. Mai erhielt ich die Antwort, dass man das Problem von meinem System aus nicht nachvollziehen könne. Die mitgeschickten Ausgaben von Ping und Traceroute zeigten jedoch, dass sich der Supporter um eine Stelle in der IP-Adresse vertan hatte. Ich antwortete ihm nochmal, welche genauen Adressbereiche betroffen wären.

Am 20. Mai erhielt ich die Antwort, dass die Ursache für das Problem sei, dass ich keine Routen für 127/8 und 169.254/16 definiert hätte. Okay, diese Routen bringen zwar absolut nichts, aber sie schaden auch nichts (sollte man meinen). Also lege ich sie an, probiere es sicherheitshalber nochmal aus und teile dem Supporter mit, dass es auch mit den gewünschten Routen (natürlich) nicht geht.

Am 21. Mai erhielt ich nun die Antwort, dass man nochmals nach der Ursache gesucht habe, aber leider das Problem weiterhin nicht nachvollziehen könne. Ich solle das System doch neu installieren, um eventuelle Konfigurationsfehler auszuschließen und mich – wenn es danach wieder auftritt – erneut melden. Da es bei allen zusätzlichen IP-Adressen kein Problem gibt, nur bei der primären IP-Adresse, ist für mich klar, dass es nicht an der Konfiguration liegen kann. Insbesondere, da die Netzkonfiguration im wesentlichen identisch zu meinen anderen Servern beim selben Hoster ist. Ich antworte dem Support also, dass die Fehlersuche auf meinem Server nichts bringen wird, da aus den bisherigen Analysen bereits erkennbar sei, dass das Problem nicht auf dem Server zu suchen ist und bitte ganz konkret darum, auf dem Router direkt vor den nicht erreichbaren IP-Bereichen (der selbst über die primäre IP-Adresse auch nicht anpingbar ist) nach der Ursache zu suchen. Wahrscheinlich erschlägt man damit alle Probleme auf einmal.

Am 22. und 24. Mai erfolgten weitere Shell-Logins vom Server-Support und .bash_history zeigte, dass man sich jeweils die Routing-Tabelle auf dem Server ansah. Dann folgte wieder eine E-Mail, mit dem Hinweis darauf, dass ich die Routing-Tabelle auf dem Server verändert hätte (ich wurde ja am 20. Mai darum gebeten, diese zu verändern) und ich solle doch den Server neu installieren, damit ein Konfigurationsfehler ausgeschlossen werden kann. Wenn das Problem dann immernoch bestehe, würde man die Sache an die Netzwerker übergeben.

Aha, aus den bisherigen Antworten konnte man erahnen, dass ich nicht mit Netzwerkern zu tun hatte, aber nun gaben sie es offen zu.

Ich wollte mir natürlich die unnötige Neuinstallation – die keinerlei Änderung herbeiführen würde – sparen, daher habe ich testweise in das Rescuesystem (das ja richtig konfiguriert sein müsste) gebootet und dort die Verbindung zum Secondary DNS geprüft – natürlich auch mit negativem Ergebnis. Hoffentlich gibt sich der Support nun damit zufrieden und eskaliert das Problem endlich an jemanden, der tatsächlich Ahnung von Routing hat.

Am 25. Mai dann wieder eine Mail vom Support, ich solle doch bitte Traceroutes aus dem Rescue-System heraus machen und schicken. Blöd, dass Traceroute beim Rescue-System nicht installiert ist, aber das kann ich mir ja von einem anderen System per SCP holen. Sicherheitshalber machte ich die Traceroutes mit UDP und auch noch ICMP, damit man mir nicht – wie ganz zu Anfang – einfach rät, ICMP statt UDP zu benutzen.

Am 26. Mai stellte ich mittags fest, dass sich zweimal ein Support-Mitarbeiter auf dem Server eingeloggt hat. Dabei hat er sich die Routingtabelle und die Ausgabe von ifconfig angesehen, die beiden dort erscheinenden IPv6-Tunnel (zum IPv6-Gateway des Hosters und zu mir nach Hause) heruntergefahren, per traceroute verfiziert, dass das Routingproblem weiterhin besteht, und dann die beiden IPv6-Tunnel wieder gestartet. Am Abend des 26. erhielt ich eine Mail, in der nach den Ausgaben von route -n und ifconfig gefragt wird (hm, hat man sich doch mittags schon selbst angesehen), da diese sich augenscheinlich verändert hätten. Ja, natürlich haben die sich verändert, schließlich wurde ich am 20. gebeten, unnütze Änderungen vorzunehmen, und habe diese nach der Mail vom 24. wieder rückgängig gemacht.

Am 27. Mai fand noch vor 9 Uhr morgens erneut ein Login eines Support-Mitarbeiters auf dem Server statt. Es wurden erneut die IPv6-Tunnel heruntergefahren, ein traceroute versucht und dann die IPv6-Tunnel wieder hochgefahren. Nach 11 Uhr fand erneut ein Login statt, den ich erst gegen halb 12 bemerkt habe. Diesmal hat der Support-Mitarbeiter mittels mtr ein paar Ziele zu erreichen versucht, und siehe da: Plötzlich funktioniert alles einwandfrei. Nach 14 Uhr bekam ich dann eine E-Mail vom Support, in der man mir nun endlich nach nochmaliger Untersuchung die Behebung des Problems meldete und – ich hätte das nicht mal erwartet – eine angenehme Gutschrift ankündigte.

Liebes Server-Support-Team, es freut mich, dass das Problem dann doch noch gelöst werden konnte. Ich war schon kurz davor aufzugeben und meinen DNS-Kram auf einen anderen Root-Server (von einem anderen Anbieter) umzuziehen. Schön wäre es natürlich, wenn andere mit einer solch konkreten Problemmeldung sich zukünftig nicht erst wochenlang über viele hingehaltene Stöckchen kämpfen müssten. Ich wette, die eigentliche Problembehebung war, nachdem meine Meldung endlich an die richtige Stelle weitergegeben wurde, vergleichsweise schnell erledigt.