DNS und Website-Erreichbarkeit prüfen: Der umfassende Ratgeber

Wenn eine Website nicht erreichbar ist, liegt die Ursache nicht immer beim Webserver. Häufig beginnt die Fehlersuche bei der Namensauflösung: Das Domain Name System (DNS) übersetzt eine Domain in eine IP-Adresse und entscheidet damit, welchen Server Browser, Mailprogramme und andere Dienste ansprechen. Wer DNS und Website-Erreichbarkeit prüfen möchte, sollte deshalb systematisch vorgehen und DNS, Netzwerk, TLS und Webserver getrennt betrachten.

Dieser Ratgeber zeigt, welche Prüfungen sinnvoll sind, wie typische Fehlermeldungen einzuordnen sind und wann eine Änderung am DNS tatsächlich wirksam wird. Die beschriebenen Schritte eignen sich für private Websites, Unternehmensseiten und technische Dokumentationen. Sie ersetzen keine individuelle Administration, helfen aber dabei, Probleme einzugrenzen und gezielt an den zuständigen Anbieter weiterzugeben.

Was DNS und Website-Erreichbarkeit miteinander verbindet

Eine Website-Erreichbarkeit besteht aus mehreren Stationen. Gibt eine Person beispielsweise www.beispiel.de in den Browser ein, muss zunächst ein DNS-Resolver die passende IP-Adresse ermitteln. Anschließend baut das Gerät eine Verbindung zu dieser Adresse auf. Bei HTTPS folgt außerdem die Prüfung des TLS-Zertifikats, bevor der Webserver eine HTTP-Antwort liefert.

Jede dieser Stationen kann unabhängig ausfallen:

• DNS-Auflösung: Die Domain liefert keine, eine falsche oder eine nicht mehr aktuelle IP-Adresse.
• Netzwerkverbindung: Der Zielserver ist nicht erreichbar, ein Port ist blockiert oder eine Firewall verwirft die Anfrage.
• TLS beziehungsweise HTTPS: Das Zertifikat ist abgelaufen, gilt nicht für den verwendeten Hostnamen oder die Zertifikatskette ist fehlerhaft.
• Webserver und Anwendung: Der Server antwortet mit einem Fehler wie 404, 500 oder 503.
• Lokale Umgebung: Ein lokaler DNS-Cache, eine Hosts-Datei, ein VPN oder ein Unternehmensfilter beeinflusst das Ergebnis.

Die erste wichtige Frage lautet daher nicht nur „Ist die Website erreichbar?“, sondern: In welcher Schicht tritt das Problem auf? Genau diese Einordnung verhindert unnötige Änderungen an DNS-Einträgen oder am Server.

Vorbereitung: Was Sie vor der Prüfung notieren sollten

Die Darstellung macht sichtbar, dass DNS nur eine Station der gesamten Verbindung ist. So lässt sich besser unterscheiden, ob die Namensauflösung, das Netzwerk oder der Webserver untersucht werden muss.

Bevor Sie einzelne Befehle ausführen, halten Sie die betroffenen Adressen und den Zeitpunkt fest. Prüfen Sie möglichst sowohl die Hauptdomain ohne Subdomain als auch die Variante mit www. Bei internationalen oder mehrsprachigen Websites können zusätzlich weitere Hostnamen relevant sein.

• die betroffene Domain, zum Beispiel beispiel.de,
• die genaue URL einschließlich http oder https,
• die verwendete Subdomain, etwa www, shop oder blog,
• die angezeigte Fehlermeldung und den ungefähren Beginn des Problems,
• ob die Störung bei allen Personen oder nur in einem Netzwerk auftritt,
• ob kurz zuvor DNS-, Hosting-, CDN- oder Zertifikatsänderungen vorgenommen wurden.

Diese Informationen sind auch für den Support eines Hosters oder Domainregistrars wertvoll. Eine präzise Fehlerbeschreibung mit Uhrzeit und betroffener URL ist hilfreicher als die pauschale Aussage, eine Website sei „offline“.

DNS und Website-Erreichbarkeit prüfen: Ein sinnvoller Ablauf

Arbeiten Sie von der Namensauflösung zur Anwendung. So lässt sich erkennen, ob ein Problem bereits vor dem Webserver entsteht.

1. Die Domain in mehreren Netzwerken öffnen

Testen Sie die Website zunächst in einem normalen Browserfenster und, wenn möglich, über ein zweites Netzwerk. Eine Verbindung über Mobilfunk kann dabei als Vergleich dienen. Öffnet sich die Seite über Mobilfunk, aber nicht im Büro- oder Heimnetz, spricht das eher für einen lokalen Resolver, einen Filter, eine Firewall oder einen Routingfehler als für einen vollständigen Ausfall der Website.

Prüfen Sie außerdem die URL mit und ohne www. Beide Hostnamen können unterschiedliche DNS-Einträge und unterschiedliche Serverkonfigurationen besitzen. Auch die Weiterleitung von HTTP zu HTTPS sollte separat betrachtet werden.

2. Die DNS-Antwort des lokalen Systems ansehen

Unter Windows kann nslookup verwendet werden:

nslookup beispiel.de
nslookup www.beispiel.de

Auf macOS und Linux liefert dig detailliertere Informationen:

dig beispiel.de A
dig www.beispiel.de A
dig beispiel.de AAAA

Die Abfrage für A zeigt IPv4-Adressen, die Abfrage für AAAA IPv6-Adressen. Eine Domain kann mehrere Adressen zurückgeben. Das ist beispielsweise bei Lastverteilung, Hochverfügbarkeit oder einem CDN normal. Ein Ergebnis ohne Adresse, eine unerwartete Zieladresse oder eine Fehlermeldung wie SERVFAIL verdient dagegen eine genauere Untersuchung.

Notieren Sie auch, welcher DNS-Server die Antwort geliefert hat. Das Ergebnis kann vom Resolver des Internetanbieters, einem Unternehmensresolver oder einem öffentlichen Resolver stammen. Unterschiedliche Resolver können wegen Caching vorübergehend verschiedene Antworten liefern.

3. Autoritative Nameserver und DNS-Kette prüfen

Die maßgebliche DNS-Konfiguration liegt bei den autoritativen Nameservern der Domain. Mit dig können Sie zunächst deren Namen ermitteln:

dig beispiel.de NS
dig +trace beispiel.de

dig +trace verfolgt die Delegation von der Root-Zone über die zuständige Top-Level-Domain bis zu den autoritativen Nameservern. Die Ausgabe ist technisch und je nach System unterschiedlich formatiert. Entscheidend ist, ob die Delegation konsistent ist und ob die autoritativen Server eine plausible Antwort liefern.

Prüfen Sie danach einen autoritativen Nameserver direkt. Ersetzen Sie ns1.example.net durch den tatsächlich ermittelten Server:

dig @ns1.example.net beispiel.de A
dig @ns1.example.net www.beispiel.de A

Wenn die autoritative Antwort korrekt ist, aber ein einzelner lokaler Resolver noch einen alten Wert liefert, handelt es sich wahrscheinlich um Caching. Wenn bereits die autoritativen Server unterschiedliche oder falsche Antworten geben, liegt die Ursache eher in der DNS-Zone oder bei der Delegation.

4. DNS-Einträge auf typische Fehler prüfen

Für die Website sind vor allem folgende Eintragstypen relevant:

Eintrag	Aufgabe	Typische Fehler
A	Verweist auf eine IPv4-Adresse.	Alte Serveradresse, Tippfehler oder falscher Zielserver.
AAAA	Verweist auf eine IPv6-Adresse.	Fehlerhafte IPv6-Konfiguration, obwohl IPv6 bevorzugt wird.
CNAME	Verweist einen Hostnamen auf einen anderen Hostnamen.	Falsches Ziel, unerlaubter Einsatz an der Zone-Apex oder eine zusätzliche CNAME-Kette.
NS	Legt autoritative Nameserver fest.	Delegation beim Registrar passt nicht zur tatsächlich gepflegten DNS-Zone.
CAA	Kann festlegen, welche Zertifizierungsstellen Zertifikate ausstellen dürfen.	Eine gewünschte Zertifikatsausstellung wird unbeabsichtigt verhindert.

Besondere Aufmerksamkeit verdient ein vorhandener AAAA-Eintrag. Ist IPv6 veröffentlicht, aber der Server über IPv6 nicht erreichbar, können manche Geräte zuerst die fehlerhafte IPv6-Verbindung verwenden. Ein Test muss daher beide Protokolle berücksichtigen. Ein unpassender AAAA-Eintrag kann die Website für einen Teil der Besucher ausfallen lassen, obwohl IPv4 funktioniert.

5. Verbindung zur IP-Adresse untersuchen

Wenn die DNS-Adresse bekannt ist, testen Sie die Verbindung zur Website. Mit curl können Sie HTTP-Header abrufen:

curl -I http://beispiel.de
curl -I https://beispiel.de

Die Option -I fordert normalerweise nur die Header an. Antworten wie 200 oder eine nachvollziehbare Weiterleitung mit 301 oder 302 zeigen, dass ein HTTP-Dienst antwortet. Ein Fehlercode wie 403, 404, 500 oder 503 bedeutet nicht automatisch, dass DNS fehlerhaft ist. Im Gegenteil: Der Server wurde in diesen Fällen meist bereits erreicht.

Mit folgenden Varianten lässt sich die Protokollfamilie getrennt betrachten:

curl -4 -I https://beispiel.de
curl -6 -I https://beispiel.de

Funktioniert IPv4, aber IPv6 nicht, konzentriert sich die weitere Fehlersuche auf den AAAA-Eintrag, die IPv6-Erreichbarkeit, die Firewall und die Serverkonfiguration. Fällt beides aus, kommen unter anderem ein gestoppter Webserver, ein Netzwerkproblem, ein falsches Ziel oder eine Sperre infrage.

DNS-Caching und TTL richtig einordnen

DNS-Antworten werden zwischengespeichert. Die Gültigkeitsdauer wird durch die TTL, also die „Time to Live“, beeinflusst. Nach einer Änderung kann deshalb ein Resolver noch den alten Wert aus seinem Cache liefern, während ein anderer bereits die neue Adresse kennt.

Die oft verwendete Formulierung „DNS-Änderungen brauchen immer 24 bis 48 Stunden“ ist zu pauschal. Die tatsächliche Dauer hängt von der vorherigen TTL, dem Zeitpunkt des Caches, der Delegation und weiteren Resolver-Regeln ab. Eine reduzierte TTL kurz vor einer geplanten Änderung kann die Wartezeit verkürzen, wirkt aber nicht rückwirkend auf bereits gespeicherte Antworten.

Für eine belastbare Prüfung vergleichen Sie mehrere Resolver und direkt die autoritativen Nameserver. Ein einzelner Test aus einem einzigen Netzwerk reicht bei einer kürzlich vorgenommenen Änderung nicht immer aus. Gleichzeitig sollte nicht jede abweichende Antwort als Fehler interpretiert werden: Während einer laufenden Umstellung können Unterschiede vorübergehend erwartbar sein.

HTTPS, Weiterleitungen und Browserfehler getrennt prüfen

Eine korrekte DNS-Antwort garantiert noch keine funktionierende Website. Danach muss der Hostname eine passende TLS- und Webserverkonfiguration besitzen.

• Zertifikatsname: Das Zertifikat muss den aufgerufenen Hostnamen abdecken, etwa die Domain oder die verwendete Subdomain.
• Gültigkeitszeitraum: Ein abgelaufenes oder noch nicht gültiges Zertifikat führt zu Browserwarnungen.
• Zertifikatskette: Fehlende Zwischenzertifikate können vor allem bei bestimmten Clients Probleme verursachen.
• HTTPS-Weiterleitung: Eine Weiterleitung von HTTP zu HTTPS sollte auf das gewünschte Ziel zeigen und keine Endlosschleife bilden.
• Virtuelle Hosts: Der Webserver muss den angeforderten Hostnamen der richtigen Website zuordnen.

Eine Fehlermeldung wie „DNS_PROBE_FINISHED_NXDOMAIN“ weist typischerweise auf einen nicht vorhandenen Domainnamen oder eine fehlende DNS-Antwort hin. „ERR_CONNECTION_REFUSED“ deutet eher darauf hin, dass die Zieladresse gefunden wurde, aber kein Dienst die Verbindung annimmt oder eine Firewall sie zurückweist. „502 Bad Gateway“ und „504 Gateway Timeout“ betreffen häufig einen Reverse Proxy, ein CDN oder einen nicht erreichbaren Backend-Dienst.

Häufige Ursachen und passende nächste Schritte

Falsche IP-Adresse nach einem Umzug

Nach einem Hostingwechsel bleibt der A- oder AAAA-Eintrag gelegentlich auf den alten Server zeigen. Vergleichen Sie die aktuelle DNS-Antwort mit den vom neuen Hostinganbieter mitgeteilten Zielwerten. Kontrollieren Sie dabei auch www und weitere produktive Subdomains.

Domain ist beim falschen DNS-Anbieter delegiert

Die DNS-Zone wird nicht unbedingt dort verwaltet, wo die Domain registriert ist. Maßgeblich sind die beim Registrar hinterlegten NS-Einträge. Werden Änderungen im falschen Verwaltungsbereich vorgenommen, bleiben sie wirkungslos. Prüfen Sie daher die Delegation, bevor Sie einzelne Records bearbeiten.

IPv6 wurde veröffentlicht, aber nicht vollständig eingerichtet

Ein AAAA-Eintrag sollte nur auf eine tatsächlich erreichbare und korrekt abgesicherte IPv6-Adresse zeigen. Prüfen Sie Firewallregeln, Routing, Webserverbindung und die TLS-Konfiguration für IPv6. Entfernen Sie einen veralteten Eintrag nicht unüberlegt, sondern stimmen Sie die Änderung mit der verantwortlichen Administration ab.

CNAME, Weiterleitung und DNS-Zone widersprechen sich

Eine Subdomain kann entweder direkt auf eine Adresse zeigen oder per CNAME auf einen anderen Hostnamen verweisen. Unzulässige Kombinationen und lange Verkettungen erschweren die Fehlersuche. Prüfen Sie, ob das Ziel existiert und ob der Zielanbieter die gewünschte Domain kennt.

CDN, Proxy oder Firewall blockiert Anfragen

Bei einem CDN ist die veröffentlichte IP-Adresse häufig nicht die des Ursprungsservers. Ein Fehler kann deshalb zwischen Browser und CDN, zwischen CDN und Origin oder nur im Cache entstehen. Prüfen Sie die Konfiguration beider Seiten und achten Sie auf unterschiedliche Antworten für HTTP und HTTPS. Sicherheitsregeln, Ratenbegrenzungen und regionale Sperren können außerdem einzelne Netzwerke betreffen.

Werkzeuge für eine nachvollziehbare Prüfung

Für eine erste Analyse reichen meist Bordmittel. nslookup ist auf vielen Systemen verfügbar und leicht zu bedienen. dig eignet sich besser für detaillierte DNS-Antworten, TTL-Werte, Nameserver und Abfragen gegen bestimmte Resolver. curl zeigt, ob HTTP oder HTTPS antwortet und welche Statuscodes zurückgegeben werden.

Zusätzlich können Browserentwicklertools, Serverprotokolle und die Statusseiten des Hosting- oder CDN-Anbieters helfen. Öffentliche DNS-Prüfdienste können Antworten aus verschiedenen Regionen vergleichen. Verlassen Sie sich jedoch nicht blind auf einen einzelnen Dienst: Prüfen Sie, welcher Resolver tatsächlich gefragt wird und ob die Daten möglicherweise bereits zwischengespeichert sind.

Für die Dokumentation sollten Sie Befehle, Zeitpunkt, Netzwerk, verwendeten Resolver und Ergebnis festhalten. Entfernen oder schwärzen Sie interne Adressen und vertrauliche Zugangsdaten, bevor Sie Ausgaben weitergeben.

Wann professionelle Unterstützung sinnvoll ist

Holen Sie Unterstützung hinzu, wenn die Domaindelegation unklar ist, mehrere Anbieter beteiligt sind oder eine produktive Website dauerhaft ausfällt. Das gilt besonders für Shops, Buchungsseiten, Kundenportale und Systeme mit getrennten Frontend- und Backend-Diensten. Auch Änderungen an Nameservern, DNSSEC, Mailrouting oder Firewallregeln sollten nur von Personen vorgenommen werden, die die Auswirkungen beurteilen können.

Geben Sie dem Support eine strukturierte Zusammenfassung: betroffene Hostnamen, Zeitpunkt, DNS-Antworten, verwendete Netzwerke, HTTP-Statuscodes und bereits geprüfte Protokollfamilien. So lassen sich Rückfragen reduzieren und die zuständige Ebene schneller bestimmen.

FAQ

Woran erkenne ich, dass DNS die Ursache ist?

Typische Hinweise sind eine nicht auflösbare Domain, NXDOMAIN, SERVFAIL oder eine falsche IP-Adresse. Wenn der Server bereits mit einem HTTP-Status antwortet, funktioniert die DNS-Auflösung grundsätzlich; die Ursache liegt dann eher bei Webserver, Anwendung, TLS oder einer vorgeschalteten Infrastruktur.

Wie prüfe ich A- und AAAA-Einträge?

Verwenden Sie beispielsweise dig beispiel.de A und dig beispiel.de AAAA oder unter Windows nslookup -type=A beispiel.de und nslookup -type=AAAA beispiel.de. Vergleichen Sie die Ergebnisse mit den vorgesehenen Serveradressen und prüfen Sie IPv4 und IPv6 getrennt.

Warum sehen verschiedene DNS-Checker unterschiedliche Ergebnisse?

Resolver befinden sich an unterschiedlichen Standorten und besitzen eigene Caches. Nach einer Änderung laufen diese Caches nicht gleichzeitig ab. Auch eine inkonsistente Delegation oder unterschiedliche autoritative Antworten kann Abweichungen verursachen. Entscheidend ist der Vergleich mit den autoritativen Nameservern.

Kann ich den DNS-Cache lokal leeren?

Ja, viele Betriebssysteme und Browser halten DNS-Informationen lokal vor. Die konkreten Schritte unterscheiden sich jedoch nach Betriebssystem und Version. Das Leeren des lokalen Caches beseitigt keine veraltete Antwort bei einem externen Resolver und ersetzt daher keinen Vergleich mehrerer DNS-Server.

Was bedeutet ein HTTP-Statuscode 503?

Ein Statuscode 503 bedeutet, dass der angesprochene Dienst vorübergehend nicht verfügbar ist. DNS hat in diesem Fall meist bereits funktioniert. Mögliche Ursachen sind Wartung, Überlastung, ein gestopptes Backend oder eine fehlerhafte Proxy-Konfiguration.

Warum funktioniert die Domain ohne „www“, aber nicht mit „www“?

Die beiden Hostnamen können unterschiedliche A-, AAAA- oder CNAME-Einträge besitzen. Außerdem muss der Webserver beide Hostnamen kennen und das TLS-Zertifikat beide Varianten abdecken. Prüfen Sie DNS und HTTPS deshalb für jede verwendete Adresse separat.

Ist ein DNS-Propagationsproblem immer die wahrscheinlichste Erklärung?

Nein. Nach einer Änderung ist Caching zwar möglich, aber ebenso kommen eine falsche Delegation, ein Tippfehler, ein fehlerhafter AAAA-Eintrag oder ein nicht erreichbarer Server infrage. Ein strukturierter Vergleich autoritativer und rekursiver Antworten grenzt diese Ursachen besser ein.

Fazit: Schrittweise statt zufällig prüfen

DNS und Website-Erreichbarkeit prüfen bedeutet, mehrere technische Ebenen voneinander zu trennen. Beginnen Sie mit der betroffenen URL, vergleichen Sie A- und AAAA-Antworten, kontrollieren Sie die autoritativen Nameserver und testen Sie anschließend HTTP, HTTPS sowie IPv4 und IPv6. Berücksichtigen Sie TTL und Caching, ohne jede Verzögerung vorschnell als Propagation zu bezeichnen.

Eine dokumentierte Prüfung spart Zeit: Sie zeigt, ob die Domain korrekt delegiert ist, ob der richtige Server antwortet und ob das Problem erst bei TLS, Webserver, Anwendung oder Netzwerk entsteht. Je genauer diese Grenze bestimmt ist, desto gezielter können Sie selbst handeln oder die zuständige technische Stelle einbeziehen.