Service-Wüste IT-Hosting … im Zweifel ist erst mal der Kunde schuld … Szenen aus dem realen Leben

Es gibt ein paar Dinge im IT-Leben, die können einen aufregen. Im Besonderen Provider-Support. Nicht zuletzt, weil das Zeit kostet. Gerade musste ich das wieder erleben. Mit der Folge ungesund erhöhten Blutdrucks. Daher der nachfolgende Text:

Sei ca. 13:00 Uhr ist eine unserer bei Strato gehosteten Domänen nicht mehr oder nur erratisch erreichbar. Mal 0,8 Sek Antwortzeit, mal 120 Sekunden, mal interner Verbindungsfehler. Typische Antwortzeiten der letzten Monate lagen dagegen bei 0,8 bis 2,5 Sekunden – je nach Tageszeit. Was tut man in einer solchen Situation? Man ruft seinen Provider an. Man schildert das Problem. Erste Antwort:

“So etwas können wir leider nicht supporten.”

Man langt sich an den Kopf, man stöhnt innerlich und äußerlich und bemüht sich dann, dem Ansprechpartner klar zu machen, dass die Webseiten inkl. PHP seit Monaten bis heute 13:00 anstandslos liefen. Und: Kein Support gibts nicht … ob er denn Support-Mitarbeiter sei oder nicht?

Beim Stichwort PHP wurde besagter “Support”-Mitarbeiter dann plötzlich hellhörig und empfahl mir einen Umstieg auf PHP 7.2. Dann würde das wieder und schneller funktionieren. Auf die Rückfrage, ob ältere PHP-Versionen denn von Strato noch unterstützt würden, kam ein klares: Ja. Ob er denn auch Daten zu Performanceunterschieden vorliegen hätte und wie er mir erklären könne, warum der Einbruch abrupt geschehen sei. Ich wurde nach einigen Wortwechseln dann zu einem “Techniker” verbunden. Selbiger hatte dann den schlauen Gedanken, mal in die Error-Logs zu sehen. Und den weniger schlauen Gedanken, dass da wohl meine Skripte nicht laufen würden …. Da könne man nichts tun – ich müsse das selber debuggen.

Gleichzeitig flimmerten verschiedene Meldungen über den Schirm – Tenor: “Interner Proxy-Server …. – keine Antwort vom Upstream-Server.” Was ich dem Techniker pflichtbewusst mitgeteilt habe. 3 Minuten später lief meine Domäne dann wieder plötzlich sehr schnell, dann erneut Fehler und/oder bis zu 120 Sek. Responsezeit.

Ich habe mir zwischenzeitlich selbst die Error-Logs angesehen (aktuell bei Strato im Web-Kundenbereich übrigens in einer katastrophalen 1-zeiligen Darstellungsweise). Die Meldungen implizierten, dass die FastCGI-Server (wieso eigentlich trotz bekannter Schwachstellen FastCGI??) bei Strato keine Antwort von anderen Servern (File-Server) erhielten und die Skripts deshalb auf einen Timeout liefen. Keine der Meldungen deutete auf einen Skriptfehler hin. Es gab immer nur Timeout-Fehler. Ein ergänzender Blick in die Zugriffslogs zeigte zudem, dass es bis heute 13:00 keinerlei Probleme – außer typischen Angriffsversuchen auf vermutete (!) WordPress-Installationen – gab.

So gewappnet rief ich wieder an. Nun bekam ich nach einigem Hin und Her die Empfehlung, Security-Einstellungen (permanente SSL-Umlenkung und Filter) abzuschalten (!); solche Domän-Einstellungen würden manchmal “eine korrekte Ausführung von PHP-Skripten verhindern”.

Stirnrunzeln, innerliches Stöhnen, Nerven beruhigen, Hinweise auf den unglaublichen Kern der Botschaft und die Widersprüchlichkeit zu anderen Befunden absondern, Ausprobieren um des lieben Friedens willen und trotz Sinnlosigkeit: Brachte erwartungsgemäß gar nichts. Ich wurde dann auf erneuten Wunsch zu einem Techniker verbunden; die Verbindung brach dabei ab.

Zwischenzeitlich Check der Skripte. Originalzustand. Check Lauffähigkeit bei eingeschaltetem Fehlertracking in der php.ini einer Testdomäne. Kein Fehler. Erneuter Check der Strato-Error-Logs, wenn denn mal verzögert ein Seitenaufbau erfolgte – Zero Fehler.

Erneuter 4-ter Anruf. Der Kollege lies mich den Sachverhalt in Ruhe darstellen. Schließlich:

Er habe gerade das gleiche Problem mit einem anderen Kunden gehabt. Seit 20 Minuten wisse man nun auch, dass es ein größeres Problem intern bei Strato gebe. Man habe bisher vermutet, dass manche Kunden ihre Skripts modifiziert hätten. Nun wisse
man aber, dass das Problem bei Strato läge. “Tut uns leid – aber Sie können beruhigt sein, es liegt nicht an Ihren Skripten”.

Ach ….

Interessanterweise hatte auch die Telekom seit 13.00 Uhr ein flächendeckendes Problem. Da ich nicht weiß, ob man Ausschnitte von der Seite allestörungen.de kopieren darf: Dort ist Deutschland weitgehend und bis auf Thüringen zur Zeit (14:30 Uhr) rot eingefärbt. Sieht schlimm aus. Der Meldungspegel zu Störungen bewegt sich aktuell in Richtung 350 pro Viertelstunde.

Nun war Strato ja mal eine Telekom-Tochter und hatte (hat?) wohl auch einen Teil der internen Netzwerk-und Backbone-Infrastruktur bei der ehemaligen Mutter am Laufen. Ein Schelm, wer da nun einen Zusammenhang im Störungsaufkommen vermuten möchte … Am Strato-Support ging das jedenfalls spurlos vorbei.

Was haben wir gelernt? Fehler macht jeder – das ist OK. Probleme gibt es in der IT auch immer wieder. Auch das ist OK. Was aber nicht geht, sind folgende Dinge:

Erstmal den Support verweigern, die Schuld beim Kunden zu suchen, Abwimmeln und Techniker, die (vielleicht aus Zeitdruck) nicht genauer hinschauen und nicht genau hinhören.

Die Servicewüste Deutschland wächst – bei Strato offenbar in größerem Ausmaß, seit das Unternehmen eine Tochter der 1&1-Muttergesellschaft wurde. Die “ISO 27001”-Zertifizierung von Strato in Ehren – aber an der Support-Front ist Ebbe. Und das nach einer erst kürzlich erfolgten Preiserhöhung für die Hosting-Pakete.

Die Störungsmeldungen bei der Telekom haben gegen 15:00 Uhr den Höchstwert von 418 pro 15 Minuten passiert.

16:30 Uhr: Die Antwortzeiten meiner Domäne schwankten gerade zwischen 0,162 Sekunden und 120 Sekunden. Eben wieder ein Ausfall.

Nun, um 16:40 Uhr: 0,16 bis 0,26 Sekunden nach erstmaligem Laden der PHP-Skripte (< 1 Sek).

Jetzt 16:45 Uhr: Stabilität seit mehr als 5 Minuten … bei der Telekom fällt das Störungsaufkommen.

Sinkender Blutdruck …

Nützliche Webseiten zur Analyse von DNS-Problemen mit gehosteten Web-Domainen

Gestern rief meine Frau an, die sich z.Z. bei Bekannten in Norwegen aufhält; Firefox würde eine von ihr betreute norwegische Homepage eines Kunden nicht mehr anzeigen – weder auf dem Windows-Desktop noch auf ihrem Mobil-Telefon. Bei einem Kollegen ginge es aber anstandslos. Andere Webseiten konnte sie problemlos aufrufen; nur eben nicht die Seiten der von ihr betreuten norwegischen Web-Domaine.

Das sind so Themen, die einen durchaus eine Weile beschäftigen können, da in einer solchen Situation potentiell mehrere Provider ins Spiel kommen. Da ist einerseits mal der Internet-Provider der Verwandtschaft in Norwegen; über den erhält der dortige Router in der Standardkonfiguration automatisch DNS-Server-Adressen zugewiesen. Der Kunde hingegen hatte seinen Web-Space bei einem sog. “norwegischen Web-Hotel” – also bei einem kleineren norwegischen Web-Server-Provider – gehostet. (Der Vertrag ist außerhalb von unserer Verantwortung und Beratung geschlossen worden).

Natürlich war hinter der ganzen Angelegenheit ein DNS-Problem zu vermuten. Allerdings war auch klar, dass das ein etwas ungewöhnliches Problem sein musste, da es nur domain-spezifisch auftrat. Ich beschreibe nachfolgend kurz das Vorgehen zur Analyse mit Hilfe von im Internet verfügbaren Diensten und einiger nützlicher Webseiten. Das Ergebnis war für mich zudem etwas überraschend; man lernt ja nie aus.

Zunächst ließ ich checken, welche DNS-Server dem Router in Norwegen zugeordnet waren; dann, ob diese Server überhaupt ihren Dienst taten. Letzteren Schritt konnte ich nicht von Deutschland aus mit einem der üblichen Linux-Kommandos “dig”, “host” oder dem alten “nslookup” erledigen. Grund: Der Provider verweigert den Zugriff auf seinen DNS-Server aus dem Ausland.
Also musste meine Frau die Windows-Variante von “nslookup” in der MS Windows Eingabe-Aufforderung benutzen. (Die Syntax – s. “nslookup /?” – ist sehr linux-ähnlich). Ergebnis: Die DNS-Server des Providers funktionierten zwar, konnten den Namen der Problem-Domaine aber tatsächlich nicht in eine IP-Adresse auflösen – andere Domainnamen hingegen schon.

Ein Gegentest mit verschiedenen anderen, öffentlich zugänglich DNS-Servern in Norwegen (http://public-dns.info/nameserver/no.html) ergab dann, dass einige dieser DNS-Server die Namensauflösung vornahmen, einige wenige aber nicht.

Für andere Länder findet man öffentlich zugängliche DNS-Server übrigens mit

http://public-dns.info/nameserver/LANDESKUERZEL.html

Ein ähnliches Ergebnis lieferte dann eine Stichprobe für deutsche DNS-Server: die allermeisten DNS-Server führten die Namensauflösung für die betroffene norwegische Web-Domaine durch, einige aber auch hierzulande nicht. Dadurch misstrauisch geworden, überprüfte ich als nächstes, was denn die Datenkrake Google zu der ganzen Sache meinte.

So kann man beispielsweise mal

host xyz.no 8.8.8.8 oder host xyz.no 8.8.4.4

ausführen (xyz ist natürlich durch den korrekten Domainnamen zu ersetzen). die IP-Adressen entsprechen öffentlichen DNS-Servern von Google.

Und siehe da – auch Google verweigerte die Namensauflösung mit der Meldung “SERVFAIL”; das Ergebnis erhielt ich natürlich auch über https://dns.google.com.

Interessant – aber ein Seitenaspekt – ist in einer solchen Situation auch, wie eigentlich eine Domaine nach außen im Internet erscheint, wer darauf verlinkt und ob die zugeordnete IP von mehreren anderen Web-Domainen geteilt wird. Hierzu kann man mal einen Blick auf den Web-Dienst

http://domainstats.io/

werfen und dort seinen Domainnamen eingeben (oder gleich http://domainstats.io/domainname). Man erhält dann in der Mitte der Seite mit vielen Analyse-Ergebnissen auch eine Info zur IP – und wie oft die geteilt wird.
Ein Klick auf die Zahl oder aber die Eingabe von

http://domainstats.io/IP-ADRESSE

in der HTTP-Adresszeile des Browsers liefert dann mehr und übersichtliche Informationen über die Web-Domainen zur gleichen IP-Adresse.

Für uns interessant war das Ergebnis trotz keiner direkten DNS-bezogenen Auskunft trotzdem. Denn auf diesem Wege erfuhren wir, dass die betreute Domaine (inzwischen?) auf einem US-amerikanischen Server gehostet und dass die Web-Server-IP mit 48 anderen Domainen (meist norwegische Domainen) geteilt wird. Davon wusste weder unser Kunde etwas, noch bislang wir.

Im Klartext: Der Web-Hoster in Norwegen kooperiert offenbar mit einem amerikanischen Provider – und nutzt dessen Hosting-Dienste – wohl um selbst Kosten zu sparen. Inkl. der an die Domaine angeschlossene Mail-Dienste. Ohne allerdings den Kunden über dieses Faktum zu informieren …

Off Topic: Dass in den USA ein anderer Datenschutz gehandhabt wird als in der EU ist wohl auch Norwegern inzwischen bekannt … Aber, was solls, Norwegen ist ja selbst auch nicht in der EU und sein Geheimdienst betreibt angeblich auch Supercomputeranlagen zur Dechiffrierung kryptierter Information
http://www.golem.de/news/spionage-supercomputer-soll-norwegen-beim-entschluesseln-helfen-1404-106115.html
http://www.spiegel.de/netzwelt/web/steelwinter-supercomputer-norwegens-geheimdienst-kooperiert-mit-nsa-a-966541.html
https://netzpolitik.org/2014/steelwinter-nsa-verkauft-supercomputer-an-norwegischen-geheimdienst/
Unabhängig davon gilt wohl: Augen auf bei der Provider-Wahl für Web-Hosting in Norwegen …. Man sollte sich als Betroffener vorab informieren, wo die eigenen Daten letztlich wirklich gehostet werden – und dann entscheiden, ob man das für gut hält …

Nun war es endgültig an der Zeit, sich darüber zu informieren, aus welchen Gründen es z.B. bei Google Probleme mit der Namensauflösung geben kann. Weiter half dabei die Seite
https://developers.google.com/speed/public-dns/docs/troubleshooting
Sie liefert einige nützliche Informationen und verweist auf weitere Seiten, die eine übersichtliche Analyse der DNS-Situation für eine Web-Domaine liefern können; für eine solche Analyse müsste man auch als Linuxer einigen Aufwand betreiben und sich viele Optionen der Kommandos nslookup, dig, host zu eigen machen :

http://intodns.com/

Das dortige Toolset analysiert zwar nur Haupt- und keine Sub-Domainen; das reicht ja aber in der Regel. Ich kann jedem nur raten, sich das ausführliche Ergebnis mal für die eigene Domainen anzusehen und über evtl. monierte Punkte nachzudenken und diesbzgl. auch ggf. seinen Provider zu kontaktieren.

Interessant war auch im Fall des norwegischen Hosters wieder eine Abweichung von deutschen Gepflogenheiten festzustellen – hierzulande werden zumindest bei den großen Providern die autoritativen DNS-Nameserver zu einer .de-Domaine in getrennten Netz-Segmenten und unabhängig von den Web-Servern betrieben. Eine Zusammenstellung der Anforderungen (im Jahr 2012) findet man z.B. hier
http://www.inmotionhosting.com/support/community-support/dns-nameserver-changes/nameserver-requirements-to-de-domain-name,
http://manage.resellerclub.com/kb/
answer/1132
,
https://de.godaddy.com/help/about-de-domains-5825.
Der TÜV stellt im Rahmen von Firmenzertifizierungen noch weitergehende Anforderungen wie z.B. echte unabhängige Internet-Uplinks etc.. Im Falle des norwegischen (besser amerikanischen Hosters war ein Nameserver mit dem Webserver identisch. Ein zweiter lag im selben C-Segment.

In Norwegen ist übrigens die Organisation NORID für die übergeordneten Domain-Services zuständig. Allerdings erfährt man aus den “whois”-Einträgen anders als bei der DENIC nicht direkt die IP-Adressen der autoritativen Name-Server für eine Domaine. Hier helfen auf die Schnell die Informationen von intodns.com. Oder:

host -C domain-name

Es lohnt sich generell, mal die man-Seiten zu nslookup, host und dig bzgl. der möglichen Optionen zu scannen.

Im Falle unserer norwegischen Problem-Domaine spuckte intodns.com zwar einige kleinere Warnhinweise aus – nichts davon erschien mir aber die fehlende Namensauflösung erklären zu können. Aber Google weist ja freundlicherweise auch auf

http://dnsviz.net/

hin. Die dortigen DNS-Tools untersuchen die Einhaltung von DNSSEC-Standards. Es geht dabei um die Signierung von DNS-Informationen mit Hilfe kryptografischer Schlüssel und Zertifikate. Siehe für eine Kurzdarstellung:
https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

Eine wesentlich ausführlichere und gute Einführung liefert folgender Artikel von U. Wisse, der unter den Webseiten von Heise publiziert wurde :
http://www.heise.de/netze/artikel/Domain-Name-System-absichern-mit-DNSSEC-903318.html

Nachvollziehbare Kritik zum DNSSEC-Verfahren findet man z.B. hier:
http://www.golem.de/news/imho-dnssec-ist-gescheitert-1506-114940.html

Interessant finde ich, dass das ganze DNSSEC-System allein von US-amerikanischen Root-Zonen-Servern und der dortigen DNSSEC-Schlüssel-, genauer Zertifikats-Verwaltung abhängig ist. Als neutrale Verfikationsinstanz für die Zertifikatsechtheit fungiert wiederum ein amerikanisches Unternehmen. Das aber nur nebenbei …

Der Einführung von Hrn. Wisser entnimmt man, dass schon kleine Fehler beim Aufsetzen der DNSSEC-Informationen auf DNS-Servern, die DNSSEC unterstützen, zur Nicht-Erreichbarkeit einer Web-Domaine führen können. Das Gleiche gilt, wenn Umzüge von Domainen zu Providern stattfinden, die z.B. DNSSEC nicht unterstützen – der originale Provider aber auf seinen Servern noch DNSSEC-Einträge vorhält. Darauf weist auch die oben genannte Google-Seite hin.

Tja, was soll ich noch mehr sagen: “http://dnsviz.net/” lieferte gestern substanzielle Fehler bzgl. der verfügbaren DNSSEC Information zu unserer Problem-Domaine. Kein Wunder, dass Google und andere DNSSEC-fähige DNS-Server die Namensauflösung verweigerten. Viele andere DNS-Server prüfen DNSSEC-Information übrigens nicht – was einen Teil des obigen Befunds erklärt.

Der norwegische Hosting-Provider unseres Kunden hat inzwischen auf seinen Webseiten zugegeben, dass für einige “Konten” Fehler beim Update von DNSSEC-Informationen aufgetreten seien. Die würden behoben. Tatsächlich liefert dnsviz heute keine Fehler mehr. Der irritierte Kunde ist jetzt auch wieder glücklich – ich habe nebenbei etwas über DNSSEC gelernt – und auch darüber, wie sehr der Betrieb von DNSSEC von Amerika abhängig ist. Gelernt habe ich ferner, dass DNS-Probleme durch DNSSEC-Fehlern von Hosting-Providern verursacht sein können.

Dass Provider wiederum Provider nutzen, ist dagegen keine neue Erkenntnis. Dass Hosting-
Provider in Nicht-EU-Ländern gehostete Websites aber auf Server in ein anderes Land – hier: die USA – verschieben, ohne dass der Kunde etwas davon erfährt, war ein anderes interessantes Lehrstück. Ich hoffe, derlei ist in Deutschland unmöglich.

Ansonsten: Viel Spaß beim Anwenden der oben angegebenen Analyseseiten auf die von euch betreuten Web-Domainen.

P.S.: DNS-Analysen im Rahmen von Penetrationstests
Wer sich mehr für DNS-Analysen z.B. im Rahmen von Penetrationstests interessiert, sollte auch mal einen Blick auf folgende Seite werfen: http://resources.infosecinstitute.com/dns-hacking/
Auch “dnsrecon” und “dnsenum” sind interessante Tools, die in Penetrationstests aber mit Bedacht eingesetzt werden muss (s. https://w3dt.net/tools/dnsrecon). Brute Force-Einsätze sind zu unterlassen, wenn keine entsprechenden Einwilligungen des Netzbetreibers vorliegen.