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
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 :
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
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.