Aktuelles

Die Website, die es nicht gab: Eine DNS-Odyssee in vier Fehldiagnosen

Ein Kunde kann seine eigene Website nicht erreichen – klassischer Support-Fall, denkt man. Falsch gedacht. Diesmal konnte ich sie nicht erreichen, der Kunde problemlos. Willkommen zu einer Geschichte über DNS-Cache-Voodoo, ein Protokoll, das 2026 immer noch als "die neue Technik" gilt, und ein Hosting-Panel, das seinen eigenen Job nicht macht.

Akt 1: Der Klassiker, der keiner war

ERR_NAME_NOT_RESOLVED im Browser. SSH-Verbindung zum FTP-Server: Host does not exist. Sogar ein simples ping kapitulierte. Jede andere Seite im Internet? Kein Problem. Nur diese eine Vereins-Website wollte partout nicht existieren – zumindest nicht für mich.

Die erste Vermutung war die naheliegendste und, wie sich zeigen sollte, die uninteressanteste: lokaler DNS-Cache. Also der volle Standard-Katalog:

C:\>ipconfig /flushdns
Windows-IP-Konfiguration
Der DNS-Auflösungscache wurde geleert.

Router zweimal neu gestartet. Hosts-Datei kontrolliert (sauber, nur localhost). Alles Standardprogramm, alles ergebnislos. Die Seite blieb für mich so unauffindbar wie ein Parkplatz in der Münchner Innenstadt am Samstagvormittag.

Akt 2: Der Resolver-Test, der beinahe in die Irre führte

Der nächste logische Schritt: einen fremden DNS-Server direkt befragen, unter Umgehung von Router und Provider.

C:\>nslookup www.kundendomain.de 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1
Name:    www.kundendomain.de
Address:  2a00:1169:xxx:xxxx::

Ein Treffer! Die Domain existiert also doch, zumindest laut Cloudflare. Nur: eine IPv6-Adresse, keine IPv4. Das wirkte zunächst wie eine Randnotiz. War es nicht.

Nach Umstellung der DNS-Server am Netzwerkadapter auf 1.1.1.1 / 8.8.8.8 lieferte nslookup plötzlich brav ein Ergebnis. Browser und FTP-Client? Weiterhin komplette Verweigerung. Der Grund: nslookup fragt direkt beim angegebenen Server nach und ignoriert dabei den kompletten Windows-Resolver-Pfad, über den Browser, FTP-Clients und praktisch jede andere Anwendung tatsächlich laufen. Ein Tool, das die eigene Diagnose durch zu viel Eigenständigkeit sabotiert – sehr sympathisch.

Akt 3: Der eigentliche Übeltäter meldet sich

Der Beweis kam mit dem simpelsten Befehl von allen:

C:\>ping www.kundendomain.de
Ping-Anforderung konnte Host "www.kundendomain.de" nicht finden.
Überprüfen Sie den Namen, und versuchen Sie es erneut.

ping nutzt – anders als nslookup – den echten Windows-Resolver. Und der hatte ein handfestes Problem: Auf dem Entwicklungsrechner war IPv6 still und heimlich deaktiviert. Kein einziger IPv6-Eintrag in ipconfig /all, nicht einmal eine harmlose Link-Local-Adresse. Und da die Kundendomain, wie sich mit einer gezielten Typ-A-Abfrage bestätigte, ausschließlich einen AAAA-Record besitzt und keinen A-Record, blieb für ein IPv4-only-System schlicht: nichts. Niente. Ein Loch im Adressraum.

C:\>nslookup -type=A www.kundendomain.de 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1
Name:    www.kundendomain.de

Keine Adresse. Kein Trostpreis. Nichts. Die Domain existiert für die Hälfte des Internets schlicht nicht.

Vergleich: Warum "bei mir geht's nicht" nicht gleich "Cache-Problem" bedeutet

Symptom	Naheliegende Vermutung	Tatsächliche Ursache in diesem Fall
Nur eine Domain betroffen, alle anderen funktionieren	Lokaler DNS-Cache / Router-Cache	Fehlender A-Record bei dieser einen Domain – IPv4-Fallback existiert schlicht nicht
nslookup liefert ein Ergebnis, Browser scheitert trotzdem	Browser-Bug oder erneuter Cache-Fehler	nslookup umgeht den OS-Resolver-Pfad komplett – kein verlässlicher Test für "geht's wirklich"
Kunde erreicht die Seite, ich nicht	Etwas an meinem Netzwerk / Provider	Kunde hatte zufällig funktionierendes IPv6, ich hatte es lokal deaktiviert
DNS-Panel zeigt bei allen Domains identische Einträge	Also müssten sie auch alle gleich funktionieren	Panel zeigt nur Platzhalter/Templates, nicht die tatsächlich ausgelieferten Werte

Akt 4: Das Hosting-Panel, das seinen Job outsourct – an den Kunden

Zugriff auf die Nameserver-Einstellungen offenbarte den eigentlichen Treppenwitz: Die A- und AAAA-Records zeigten im Provider-Kundenpanel schlicht "Ziel: Internet-Provider". Kein Wert, keine IP, nur ein Firmenname als Platzhalter für "wird automatisch verwaltet". Bei einem baugleichen Account eines anderen Kunden sahen die Einträge optisch identisch aus – nur dass dort im Hintergrund tatsächlich ein A-Record ausgeliefert wurde. Das Panel zeigt also nicht den Ist-Zustand, sondern eine Behauptung.

Die Krönung: Es gäbe im Panel sogar ein Feld, um manuell eine IPv4-Adresse einzutragen. Als Hosting-Kunde. Für einen Server, den man nicht betreibt, dessen IP man nicht kennt, und dessen korrekte Zuordnung eigentlich exakt der Job ist, für den man monatlich bezahlt. Ein kleiner Hinweis aus dem SPF-Record (ip4:92.205.64.114) lieferte zumindest einen plausiblen Kandidaten – Mail- und Webserver laufen bei Shared Hosting meist auf derselben Adresse. Aber "meist" ist kein Ersatz für "verifiziert", und ein Kunde sollte nicht die IP-Adresse seines eigenen Hosters erraten müssen.

Stunden später...

Am Ende zwei Fehler, die sich gegenseitig maskiert haben: Auf meiner Seite ein deaktiviertes IPv6 – schnell behoben. Beim Kunden ein fehlender A-Record, verursacht durch eine kaputte Automatik im eigenen Hosting-Panel des Anbieters – nicht von mir behebbar, nur meldbar. Die Lehre daraus, mal wieder: Wenn "nur eine einzige Seite" nicht erreichbar ist, obwohl der Rest des Internets tadellos funktioniert, lohnt sich fast nie der erste Verdächtige (Cache, Router, Provider), sondern fast immer der unwahrscheinlichste: ein fehlender DNS-Record, den seit Jahren niemand mehr angeschaut hat, weil "es doch immer lief".

IPv6 gibt es seit 1998. Es ist Jahrgang 2026. Wir könnten aufhören, uns zu wundern, wenn es plötzlich der entscheidende Faktor ist.

18.07.2026