Schlagwort: DNS

WWW oder ohne WWW? Die richtige Webadresse für Ihre Website

Die Frage „WWW oder ohne WWW?“ wirkt auf den ersten Blick wie eine reine Geschmacksentscheidung. Technisch handelt es sich jedoch um zwei unterschiedliche Hostnamen: www.beispiel.de und beispiel.de sind nicht automatisch dieselbe Adresse. Für Besucherinnen und Besucher ist der Unterschied oft kaum sichtbar, für DNS, Webserver, Weiterleitungen, Cookies und Suchmaschinen kann er jedoch relevant sein.

Die gute Nachricht: Beide Varianten können zuverlässig funktionieren. Entscheidend ist nicht, welche Form grundsätzlich besser ist, sondern dass Sie eine Hauptadresse festlegen, sie konsequent verwenden und die jeweils andere Variante sauber weiterleiten. Dieser Ratgeber zeigt die wichtigsten Entscheidungskriterien, typische Fehler und einen praxistauglichen Ablauf für neue und bestehende Websites.

Was bedeutet „WWW oder ohne WWW?“

„WWW“ steht traditionell für „World Wide Web“ und wird als Subdomain vor der eigentlichen Domain verwendet. Bei der Domain beispiel.de ist www.beispiel.de also eine Subdomain. Die Variante ohne Präfix wird häufig als Root-Domain, Apex-Domain oder Naked Domain bezeichnet.

Beide Adressen können auf denselben Webauftritt zeigen, müssen es aber nicht. DNS-Einträge, Serverkonfiguration und Weiterleitungen legen fest, was beim Aufruf tatsächlich passiert. Wenn beide Varianten ohne Weiterleitung dieselben Inhalte ausliefern, können technische und redaktionelle Unklarheiten entstehen.

  • Mit WWW: https://www.beispiel.de
  • Ohne WWW: https://beispiel.de

Zusätzlich spielt das Protokoll eine Rolle. http://beispiel.de und https://beispiel.de sollten ebenfalls nicht dauerhaft gleichberechtigt nebeneinander bestehen. In der Praxis wählen Sie daher eine vollständige kanonische Adresse, etwa https://www.beispiel.de, und leiten alle anderen Varianten dorthin um.

Gibt es eine SEO-seitig bessere Variante?

Die Root-Domain beispiel.de und die Subdomain www.beispiel.de im technischen Vergleich
WWW ist eine Subdomain und nicht bloß eine andere Schreibweise derselben Adresse.

Die Grafik sollte zeigen, dass www.beispiel.de und beispiel.de technisch unterschiedliche Hostnamen sind. Dadurch wird verständlich, warum DNS, Server und Weiterleitungen bei der Auswahl berücksichtigt werden müssen.

Eine allgemeingültige SEO-Antwort zugunsten von WWW oder ohne WWW gibt es nicht. Suchmaschinen können beide Varianten verarbeiten. Für die Sichtbarkeit ist vor allem wichtig, dass Ihre Website eine klare bevorzugte URL verwendet und diese Entscheidung technisch konsistent umgesetzt wird.

Problematisch wird es, wenn dieselbe Seite unter mehreren Adressen erreichbar ist und keine eindeutige Signalisierung vorhanden ist. Dann können sich Verweise, externe Links, interne Links und Auswertungen auf verschiedene URL-Versionen verteilen. Eine Suchmaschine muss zwar nicht automatisch „doppelte Inhalte“ im strengen Sinne annehmen, doch unnötige Varianten erschweren die saubere Zuordnung.

Die Wahl selbst ist daher weniger wichtig als die konsequente Umsetzung. Verwenden Sie die gewählte Variante unter anderem in:

  • internen Links und der Navigation,
  • XML-Sitemap und strukturierten Daten,
  • kanonischen Linkelementen,
  • Weiterleitungen von alten oder alternativen URLs,
  • Social-Media-Profilen und Kampagnenlinks,
  • Analytics- und Search-Console-Konfigurationen,
  • Dokumenten, E-Mail-Signaturen und Printmaterialien.

Welche Variante passt zu welchem Website-Projekt?

Die Entscheidung sollte zu Ihrer technischen Umgebung, zur Markenkommunikation und zur langfristigen Planung passen. Für die meisten kleinen Unternehmenswebsites, Blogs und Vereinsseiten sind beide Varianten praktikabel. Wählen Sie die Adresse, die bereits etabliert ist oder sich in Ihrer Infrastruktur einfacher sauber betreiben lässt.

Wann WWW sinnvoll sein kann

Die WWW-Variante hat einen technischen Vorteil: Sie ist eindeutig als Hostname erkennbar. Das kann bei größeren Websites mit mehreren Subdomains, verteilten Systemen oder komplexer Infrastruktur übersichtlich sein. Dienste wie shop.beispiel.de, api.beispiel.de oder cdn.beispiel.de lassen sich in eine klar erkennbare Hostnamen-Struktur einordnen.

Auch bei Cookies kann die Trennung hilfreich sein. Cookies für www.beispiel.de müssen nicht automatisch für die Root-Domain oder andere Subdomains gelten. Das ist keine automatische Sicherheitsgarantie, ermöglicht aber eine differenziertere Konfiguration.

Wann die Variante ohne WWW sinnvoll sein kann

Die kurze Adresse ohne WWW wirkt in Anzeigen, auf Visitenkarten und in mündlicher Kommunikation oft kompakter. Für eine kleine Website mit überschaubarer Technik kann sie daher eine gute Wahl sein. Viele Marken verwenden sie aus Gründen der Einfachheit und Lesbarkeit.

Technisch sollte jedoch geprüft werden, ob die verwendete DNS-Infrastruktur die Root-Domain zuverlässig auf die gewünschte Zieladresse zeigen lässt. Bei modernen DNS-Diensten ist das meist lösbar, die konkrete Umsetzung hängt aber vom Anbieter ab. Eine Root-Domain kann nicht bei jedem DNS-Setup auf dieselbe Weise behandelt werden wie eine normale Subdomain.

Die wichtigsten Entscheidungskriterien

Bevor Sie sich festlegen, betrachten Sie nicht nur die sichtbare URL. Die folgenden Fragen helfen dabei, eine Entscheidung zu treffen, die auch bei späterem Wachstum Bestand hat.

Bestehende Sichtbarkeit und Verlinkungen

Wenn Ihre Website bereits veröffentlicht ist, sollte die bisherige Hauptvariante grundsätzlich beibehalten werden. Prüfen Sie, welche URLs in Suchergebnissen, externen Verweisen, Branchenprofilen, Presseartikeln und Marketingmaterialien verwendet werden. Ein Wechsel ist möglich, verursacht aber zusätzlichen Prüf- und Pflegeaufwand.

Besonders sorgfältig sollten Sie bei Websites mit vielen Backlinks, Landingpages oder internationaler Struktur vorgehen. Ein Wechsel der Hauptdomain ist zwar keine vollständige Änderung der Domain, dennoch müssen alle betroffenen Adressen korrekt weitergeleitet und überwacht werden.

Technische Infrastruktur

Fragen Sie Ihre Hosting- oder Technikverantwortlichen, welche Variante bereits als primärer Host eingerichtet ist. Relevant sind DNS-Einträge, Webserver, Reverse Proxy, Content-Management-System, CDN und TLS-Zertifikat. Beide Hostnamen müssen bei einer professionellen Einrichtung entweder abgedeckt sein oder die alternative Variante muss bereits vor dem Weiterleiten sicher erreichbar sein.

Ein Zertifikat für beispiel.de deckt nicht automatisch jede denkbare Subdomain ab. Umgekehrt gilt ein Zertifikat für www.beispiel.de nicht zwingend für die Root-Domain. Prüfen Sie daher, dass sowohl die Hauptadresse als auch die Weiterleitungsadresse unter HTTPS ohne Zertifikatswarnung erreichbar sind.

Geplante Subdomains und Dienste

Planen Sie später einen Shop, ein Kundenportal, eine API oder eine Medienplattform, kann die WWW-Variante für eine klare Hostnamen-Struktur sorgen. Das ist kein Muss, kann aber die Zuständigkeiten verständlicher machen. Bei kleinen Projekten ohne weitere Dienste ist dieser Gesichtspunkt weniger wichtig.

Cookies und Sicherheitsgrenzen

Cookies können für eine bestimmte Hostdomain oder für eine übergeordnete Domain gesetzt werden. Eine Website ohne WWW nutzt die Root-Domain bereits als zentrale Adresse; zusätzliche Subdomains sollten deshalb bewusst in die Cookie-Strategie einbezogen werden. Vermeiden Sie möglichst unnötig weit gefasste Cookies und prüfen Sie, welche Anwendungen tatsächlich Zugriff benötigen.

Die URL-Wahl ersetzt keine Sicherheitsmaßnahmen. HTTPS, aktuelle Software, sichere Authentifizierung, passende Cookie-Attribute und eine korrekte Serverkonfiguration bleiben unabhängig von WWW oder ohne WWW erforderlich.

So setzen Sie eine bevorzugte Variante technisch richtig um

Eine saubere Umsetzung besteht aus mehreren Bausteinen. Eine einzelne Einstellung im Content-Management-System reicht nicht immer aus. Gehen Sie systematisch vor und dokumentieren Sie die gewünschte Hauptadresse.

1. Eine kanonische Adresse festlegen

Entscheiden Sie sich für eine vollständige Zieladresse inklusive HTTPS, zum Beispiel https://www.beispiel.de oder https://beispiel.de. Diese Adresse sollte auf der Startseite, in der Sitemap, in der Dokumentation und in allen neuen Veröffentlichungen verwendet werden.

2. Die alternative Variante dauerhaft weiterleiten

Richten Sie eine serverseitige permanente Weiterleitung von der nicht bevorzugten Variante auf die entsprechende Ziel-URL ein. In der Regel wird dafür der HTTP-Statuscode 301 verwendet. Bei einer modernen Website sollten zusätzlich die HTTP-Varianten auf HTTPS weiterleiten.

Wichtig ist, dass die Weiterleitung möglichst direkt zum richtigen Ziel führt. Eine Kette wie http://beispiel.de zu https://beispiel.de und anschließend zu https://www.beispiel.de ist unnötig. Besser ist eine direkte Weiterleitung auf die endgültige Adresse. Bei einzelnen Unterseiten sollte der Pfad erhalten bleiben, sofern die Zielseite weiterhin existiert.

3. DNS und Webserver prüfen

Beide Hostnamen müssen DNS-seitig sinnvoll behandelt werden. Der Hostname, der weiterleitet, muss den Server oder Dienst erreichen können, der die Weiterleitung ausliefert. Der Webserver muss außerdem wissen, für welche Hostnamen er zuständig ist und welche Antwort er jeweils liefern soll.

Bei einem Wechsel prüfen Sie auch Caching-Effekte. DNS-Änderungen und Weiterleitungen können abhängig von TTL, Browsercache, Proxy und CDN unterschiedlich schnell sichtbar werden. Testen Sie deshalb nicht nur in einem bereits verwendeten Browser, sondern auch mit einem privaten Fenster und mehreren Netzwerken.

4. Interne Verweise aktualisieren

Verlinken Sie innerhalb der Website direkt auf die bevorzugte Variante. Das gilt für Menüs, Logos, Breadcrumbs, Bilder, Downloads, strukturierte Daten und hreflang-Verweise. Interne Links sollten nicht unnötig über eine Weiterleitung laufen, da direkte Zieladressen für Wartbarkeit und Analyse sauberer sind.

5. Canonical und Sitemap kontrollieren

Das rel="canonical"-Element sollte auf die bevorzugte URL der jeweiligen Seite zeigen. Es ersetzt keine Weiterleitung, unterstützt aber die Signalisierung an Suchmaschinen. Die XML-Sitemap sollte ausschließlich die kanonischen, erreichbaren HTTPS-URLs enthalten. Prüfen Sie, ob Ihr CMS oder SEO-Plugin die gewünschte Variante tatsächlich ausgibt.

Typische Fehler bei der Umstellung

Viele Probleme entstehen nicht durch die Auswahl selbst, sondern durch unvollständige Umsetzung. Die folgenden Fälle treten besonders häufig auf.

  • Beide Varianten liefern denselben Inhalt: Ohne klare Weiterleitung und Canonical-Signale bleiben mehrere Adressen aktiv.
  • Weiterleitungen führen in Schleifen: Eine Regel im CMS und eine zweite Regel im Webserver können sich gegenseitig widersprechen.
  • Gemischte interne Links: Einige Seiten verweisen auf WWW, andere auf die Root-Domain. Das macht Crawling und Auswertung unnötig unübersichtlich.
  • HTTPS wird nicht vollständig berücksichtigt: Die WWW-Entscheidung ist korrekt, aber einzelne HTTP- oder Ressourcen-URLs bleiben bestehen.
  • Cookies funktionieren nach dem Wechsel nicht mehr: Anmeldungen, Warenkörbe oder Sitzungen können betroffen sein, wenn Host- und Cookie-Einstellungen nicht zusammenpassen.
  • Hardcodierte URLs bleiben unentdeckt: Bilder, Feeds, Skripte, Downloads oder PDF-Dateien enthalten weiterhin die alte Variante.
  • Analysewerkzeuge zeigen uneinheitliche Daten: Wenn Property-, Filter- oder Datenstrom-Einstellungen nicht angepasst werden, ist die Zeitreihe schwer vergleichbar.

Checkliste für einen sicheren Wechsel

Wenn Sie von WWW auf ohne WWW oder umgekehrt wechseln, planen Sie die Umstellung wie eine kleine technische Migration. Eine möglichst vollständige Checkliste sieht so aus:

  1. Inventarisieren Sie die bisher verwendeten Hostnamen und Protokolle.
  2. Legen Sie die neue Hauptadresse schriftlich fest.
  3. Prüfen Sie DNS, Hosting, Webserver, CDN und TLS-Zertifikate.
  4. Erstellen Sie Weiterleitungen mit erhaltenem Pfad und möglichst ohne Weiterleitungsketten.
  5. Aktualisieren Sie CMS-Einstellungen, Canonicals, Sitemap und strukturierte Daten.
  6. Ersetzen Sie interne Links und fest hinterlegte URLs.
  7. Prüfen Sie Login, Formulare, Warenkorb, Downloads, Feeds und Medien.
  8. Aktualisieren Sie externe Profile, Kampagnen und wichtige Dokumente.
  9. Kontrollieren Sie Suchmaschinen- und Analysewerkzeuge.
  10. Testen Sie Statuscodes, Weiterleitungen, Zertifikate und wichtige Seitentypen.
  11. Überwachen Sie nach dem Wechsel Crawling, Fehlermeldungen und Zugriffe auf alte URLs.

Behalten Sie alte Weiterleitungen dauerhaft bei, sofern die früheren URLs weiterhin aufgerufen oder von außen verlinkt werden. Entfernen Sie sie nicht nur deshalb, weil die neue Adresse inzwischen bekannt ist.

Wie lässt sich die Umsetzung prüfen?

Eine Prüfung sollte verschiedene URL-Kombinationen abdecken: HTTP und HTTPS, mit WWW und ohne WWW sowie Startseite und wichtige Unterseiten. Für jede nicht bevorzugte Variante sollte eine eindeutige permanente Weiterleitung zur passenden kanonischen Adresse erfolgen. Die Zielseite sollte anschließend den erwarteten Erfolgsstatus liefern.

Kontrollieren Sie außerdem:

  • ob keine Zertifikatswarnung erscheint,
  • ob keine Weiterleitungsschleife entsteht,
  • ob Pfade, Parameter und Sprachversionen korrekt behandelt werden,
  • ob Canonical und Sitemap dieselbe Variante verwenden,
  • ob interne Links direkt auf die Hauptadresse zeigen,
  • ob Anmeldung und Sitzungen nach dem Wechsel funktionieren,
  • ob wichtige Seiten weiterhin in Analyse- und Suchwerkzeugen erfasst werden.

Bei umfangreichen Websites ist eine automatisierte Prüfung der URL-Bestände hilfreich. Für kleine Websites genügt oft eine manuelle Kontrolle der wichtigsten Vorlagen und Seitentypen. Entscheidend ist, nicht nur die Startseite zu testen.

WWW oder ohne WWW bei WordPress

In WordPress wird die bevorzugte Adresse typischerweise in den Feldern für die WordPress-Adresse und die Website-Adresse hinterlegt. Diese Einstellungen sollten normalerweise übereinstimmen und die gewünschte HTTPS-Variante enthalten. Änderungen sollten Sie nicht unüberlegt direkt in der Datenbank durchführen, besonders wenn Sie keinen Zugriff auf ein funktionierendes Backup oder die Serverkonfiguration haben.

Nach der Änderung müssen absolute URLs in Inhalten, Widgets, Menüs und Medien überprüft werden. Caching-Plugins, CDN-Konfigurationen und Sicherheitsplugins können zusätzlich eigene Regeln für Hostnamen oder HTTPS enthalten. Leeren Sie Caches kontrolliert und prüfen Sie anschließend Weiterleitungen sowie die wichtigsten Funktionen.

Bei WordPress-Multisite, WooCommerce, Membership-Systemen oder mehreren Sprachversionen steigt der Prüfaufwand. Hier sollten Sie vor der Umstellung eine Sicherung erstellen und die Änderung möglichst zuerst in einer Testumgebung oder zu einem planbaren Wartungszeitpunkt vorbereiten.

FAQ

Ist WWW oder ohne WWW besser für Google?

Keine der beiden Varianten ist grundsätzlich besser. Suchmaschinen können sowohl WWW- als auch Root-Domains verarbeiten. Entscheidend sind eine konsistente Hauptadresse, funktionierende Weiterleitungen, eindeutige Canonicals, direkte interne Links und eine aktuelle Sitemap.

Kann ich beide Varianten gleichzeitig verwenden?

Technisch können beide Varianten erreichbar sein, empfehlenswert ist das für dieselben Inhalte jedoch nicht. Legen Sie eine Variante als Hauptadresse fest und leiten Sie die andere dauerhaft dorthin weiter. So vermeiden Sie unnötige technische und analytische Uneinheitlichkeit.

Verliere ich beim Wechsel von WWW auf ohne WWW meine Rankings?

Ein sauber geplanter Wechsel muss nicht zu einem dauerhaften Verlust führen. Dennoch ist es eine technische Migration, bei der vorübergehend Schwankungen möglich sind. Entscheidend sind direkte permanente Weiterleitungen, vollständige interne Anpassungen, konsistente Canonicals und eine Kontrolle der wichtigen URLs.

Benötige ich für WWW und ohne WWW zwei Zertifikate?

Das hängt vom Zertifikat und vom Hosting ab. Beide Hostnamen müssen sicher erreichbar sein, auch wenn einer nur weiterleitet. Prüfen Sie deshalb ausdrücklich, ob das eingesetzte Zertifikat sowohl die Hauptadresse als auch die Weiterleitungsadresse abdeckt. Ein Zertifikat für eine einzelne Subdomain deckt die Root-Domain nicht automatisch ab.

Beeinflusst die Entscheidung die Ladezeit?

WWW oder ohne WWW verursacht allein keinen nennenswerten grundlegenden Geschwindigkeitsvorteil. Eine zusätzliche Weiterleitung kostet jedoch einen weiteren Abrufschritt. Besucher sollten möglichst direkt die endgültige Adresse erhalten; interne Links und Kampagnenlinks sollten deshalb die Hauptvariante verwenden.

Kann ich später noch von einer Variante zur anderen wechseln?

Ja, ein späterer Wechsel ist möglich. Je etablierter die Website ist, desto sorgfältiger sollte er vorbereitet werden. Prüfen Sie vorab Backlinks, hardcodierte URLs, Cookies, Integrationen, Zertifikate, Redirects und Analysewerkzeuge. Planen Sie anschließend eine Nachkontrolle der wichtigsten Seiten ein.

Was ist bei E-Mail-Adressen zu beachten?

Webadresse und E-Mail-Domain sind miteinander verbunden, aber nicht identisch. Eine Änderung der Website-URL ändert nicht automatisch E-Mail-Adressen wie kontakt@beispiel.de. Prüfen Sie dennoch Signaturen, Links in E-Mails, Autokonfigurationen und externe Dienste, wenn sich die verwendete Domainstruktur insgesamt verändert.

Reicht ein Canonical-Tag als Lösung aus?

Nein. Ein Canonical-Tag ist ein wichtiges Signal, aber kein Ersatz für eine klare Host-Konfiguration und permanente Weiterleitungen. Wenn eine alternative URL nicht als eigenständige Adresse bestehen soll, sollte sie serverseitig auf die bevorzugte Version weiterleiten.

Fazit: Entscheidend ist die Konsequenz

Bei der Frage „WWW oder ohne WWW?“ gibt es keinen universell richtigen Gewinner. Die WWW-Variante kann bei komplexen Hostnamen-Strukturen übersichtlich sein, während die kurze Root-Domain in der Kommunikation kompakt wirkt. Für SEO und Nutzerfreundlichkeit ist vor allem wichtig, dass Sie eine Variante bewusst auswählen und überall konsequent verwenden.

Für eine neue Website genügt meist eine einfache Entscheidung anhand von Markenauftritt, Hosting und geplanter Infrastruktur. Bei einer bestehenden Website ist die bisherige Variante oft die pragmatischste Wahl. In beiden Fällen gilt: HTTPS aktivieren, alternative URLs dauerhaft weiterleiten, interne Verweise aktualisieren und die technische Umsetzung regelmäßig kontrollieren. So bleibt die Webadresse für Menschen, Systeme und Suchmaschinen eindeutig.

IP-Adresse einer Website ermitteln: Methoden, Befehle und wichtige Grenzen

Die IP-Adresse einer Website zu ermitteln, ist in vielen Fällen unkompliziert: Ein DNS-Dienst übersetzt den Domainnamen in eine oder mehrere IP-Adressen. Je nach Betriebssystem können Sie dafür die Eingabeaufforderung, ein Terminal, die DNS-Informationen des Browsers oder einen seriösen Online-Dienst verwenden.

Wichtig ist jedoch die richtige Einordnung des Ergebnisses. Die angezeigte IP-Adresse gehört nicht zwingend direkt zum eigentlichen Webserver. Ein Content-Delivery-Netzwerk, ein Reverse-Proxy, ein Load-Balancer oder ein Sicherheitsdienst kann zwischen Domain und Ursprungsserver liegen. Dieser Ratgeber zeigt, wie Sie eine IP-Adresse zuverlässig ermitteln, die Ausgabe verstehen und typische Fehlinterpretationen vermeiden.

Was bedeutet die IP-Adresse einer Website?

Eine Domain wie beispiel.de ist für Menschen leichter zu merken als eine Zahlenfolge. Computer und Netzwerke verwenden dagegen IP-Adressen, um Ziele im Internet zu adressieren. Das Domain Name System, kurz DNS, übernimmt die Übersetzung zwischen beiden Angaben.

Bei einer Website können zwei IP-Versionen relevant sein:

  • IPv4: Eine Adresse besteht aus vier durch Punkte getrennten Zahlenblöcken, zum Beispiel in der Form 203.0.113.25.
  • IPv6: Eine Adresse besteht aus mehreren hexadezimalen Blöcken, die durch Doppelpunkte getrennt werden, zum Beispiel in der Form 2001:db8::25.

Eine Domain kann gleichzeitig eine IPv4- und eine IPv6-Adresse besitzen. Ebenso kann DNS mehrere Adressen zurückgeben, etwa zur Lastverteilung, für Ausfallsicherheit oder für unterschiedliche Netzwerke. Deshalb ist eine einzelne gefundene IP-Adresse nicht immer die vollständige Antwort.

IP-Adresse einer Website ermitteln: die schnellsten Methoden

Für eine erste Abfrage benötigen Sie meist kein spezielles Programm. Entscheidend ist, dass Sie nur den Domainnamen eingeben und nicht die komplette Webadresse mit Protokoll und Unterseiten. Aus https://www.beispiel.de/kontakt wird für die DNS-Abfrage in der Regel www.beispiel.de.

Windows: nslookup verwenden

Beispielhafte nslookup-Abfrage in der Windows-Eingabeaufforderung
Eine nslookup-Abfrage zeigt die zu einer Domain gefundenen DNS-Adressen.

Achten Sie in der Ausgabe auf den abgefragten Hostnamen und die gefundenen A- beziehungsweise AAAA-Einträge. Die Darstellung hilft dabei, IPv4- und IPv6-Adressen nicht miteinander zu verwechseln.

Unter Windows ist nslookup bereits Bestandteil des Systems. Öffnen Sie die Eingabeaufforderung oder PowerShell und geben Sie ein:

nslookup beispiel.de

In der Ausgabe finden Sie zunächst den verwendeten DNS-Server und anschließend die Antwort für die abgefragte Domain. Zeilen mit einer IPv4-Adresse beziehen sich auf einen A-Datensatz. IPv6-Adressen werden über AAAA-Datensätze ausgegeben.

Sie können auch gezielt nach einem Record-Typ fragen:

nslookup -type=A beispiel.de
nslookup -type=AAAA beispiel.de

Bei einer Subdomain müssen Sie diese vollständig angeben:

nslookup shop.beispiel.de

Das ist wichtig, weil beispiel.de, www.beispiel.de und shop.beispiel.de auf unterschiedliche Ziele zeigen können.

Windows PowerShell: Resolve-DnsName

PowerShell bietet mit Resolve-DnsName eine ausführlichere Alternative:

Resolve-DnsName beispiel.de

Für einen bestimmten Record-Typ eignet sich zum Beispiel:

Resolve-DnsName beispiel.de -Type A
Resolve-DnsName beispiel.de -Type AAAA

Die Ausgabe macht häufig besser sichtbar, ob mehrere Antworten vorhanden sind und welche Art von DNS-Eintrag jeweils gefunden wurde.

Linux und macOS: dig oder host

Auf vielen Linux-Systemen und macOS-Geräten ist dig verfügbar. Die einfache Abfrage lautet:

dig beispiel.de

Übersichtlicher ist die Kurzform:

dig +short beispiel.de

Damit werden meist nur die ermittelten Adressen angezeigt. Für IPv4 und IPv6 können Sie die Abfrage trennen:

dig A beispiel.de +short
dig AAAA beispiel.de +short

Das Programm host ist ebenfalls praktisch:

host beispiel.de

Wenn ein Befehl nicht vorhanden ist, können Sie alternativ die DNS-Werkzeuge Ihrer Distribution installieren oder einen vertrauenswürdigen DNS-Dienst im Browser verwenden.

Online-DNS-Abfragen nutzen

Online-Dienste zeigen DNS-Einträge über eine Weboberfläche an. Das kann hilfreich sein, wenn Sie keine Kommandozeile verwenden möchten oder Antworten aus verschiedenen Regionen vergleichen wollen. Suchen Sie dort gezielt nach den Eintragstypen A und AAAA.

Beachten Sie dabei einige Grenzen:

  • Der Dienst verwendet seinen eigenen Resolver und nicht unbedingt den DNS-Server Ihres Anschlusses.
  • Zwischengespeicherte Antworten können sich von einer lokalen Abfrage unterscheiden.
  • Bei unbekannten Websites sollten Sie keine sensiblen internen Hostnamen oder vertraulichen Domains an externe Dienste übermitteln.
  • Ein Online-Ergebnis zeigt ebenfalls nur die öffentlich sichtbare DNS-Struktur und nicht automatisch den Ursprungsserver.

Die Ausgabe richtig lesen

Eine DNS-Antwort enthält mehr Informationen als nur eine IP-Adresse. Wer die einzelnen Bestandteile versteht, kann Fehler schneller erkennen.

A- und AAAA-Datensätze

Ein A-Datensatz verbindet einen Hostnamen mit einer IPv4-Adresse. Ein AAAA-Datensatz verbindet ihn mit einer IPv6-Adresse. Wenn nur ein A-Datensatz vorhanden ist, bedeutet das nicht automatisch, dass die Website fehlerhaft eingerichtet ist. Möglicherweise wird IPv6 nicht angeboten oder ist für den jeweiligen Dienst nicht vorgesehen.

Umgekehrt kann eine Website mehrere A- oder AAAA-Einträge besitzen. Das ist bei großen Diensten, geografischer Verteilung oder redundanten Systemen üblich. Eine Abfrage zu einem späteren Zeitpunkt oder über einen anderen Resolver kann deshalb eine andere Reihenfolge liefern.

CNAME und Weiterleitungen innerhalb von DNS

Statt direkt eine IP-Adresse zu hinterlegen, kann ein Hostname auf einen anderen Hostnamen verweisen. Dafür wird häufig ein CNAME verwendet. Beispielhaft könnte www.beispiel.de auf webanbieter.example.net zeigen. Erst die weitere DNS-Auflösung liefert anschließend die A- oder AAAA-Adressen.

Ein CNAME ist keine HTTP-Weiterleitung. Der Browser wird dabei nicht mit einem sichtbaren Sprung auf eine andere URL geschickt. Es handelt sich um eine technische Zuordnung innerhalb des DNS.

TTL und DNS-Cache

Die TTL, also die Time to Live, gibt an, wie lange Resolver eine DNS-Antwort grundsätzlich zwischenspeichern dürfen. Während dieser Zeit kann ein Gerät oder DNS-Server die alte Adresse verwenden, ohne erneut beim zuständigen Nameserver nachzufragen.

Nach einer DNS-Änderung sehen daher nicht alle Nutzer sofort dieselbe Adresse. Unterschiede können durch lokale Caches, Router, Unternehmensnetzwerke oder öffentliche Resolver entstehen. Ein Neustart des Browsers allein leert nicht immer alle DNS-Zwischenspeicher.

Warum die ermittelte IP nicht immer der echte Server ist

Die IP-Adresse, die Sie über DNS erhalten, ist die öffentlich erreichbare Adresse für den abgefragten Hostnamen. Sie muss nicht mit der internen oder ursprünglichen Serveradresse des Website-Betreibers identisch sein.

Content-Delivery-Netzwerke und Reverse-Proxys

Viele Websites verwenden einen Reverse-Proxy oder ein Content-Delivery-Netzwerk. Der Besucher verbindet sich dann zunächst mit einem vorgeschalteten Netzwerk. Dieses kann Inhalte ausliefern, Anfragen filtern, TLS-Verbindungen terminieren und die Anfrage anschließend an einen Ursprungsserver weitergeben.

In diesem Fall zeigt die DNS-Abfrage typischerweise die Adresse des vorgeschalteten Dienstes. Das ist nicht zwingend ein Fehler, sondern oft ein bewusstes Sicherheits- und Leistungsdesign. Ein Reverse-Proxy kann den Ursprungsserver vor direkten Anfragen abschirmen.

Load-Balancing und wechselnde Antworten

Ein Load-Balancer verteilt Anfragen auf mehrere Server. DNS kann dabei mehrere Adressen liefern oder je nach Standort und Resolver unterschiedliche Ziele zurückgeben. Eine einzelne Abfrage ist deshalb nur eine Momentaufnahme.

Wenn Sie eine Störung untersuchen, sollten Sie die Domain über verschiedene Netzwerke und zu verschiedenen Zeitpunkten prüfen. Zusätzlich ist festzustellen, ob nur die Hauptdomain oder auch einzelne Subdomains betroffen sind.

Gemeinsam genutzte IP-Adressen

Auf einer IP-Adresse können mehrere Websites betrieben werden. Das ist bei gemeinsam genutztem Hosting üblich. Die Zuordnung der angeforderten Website erfolgt zusätzlich über den Hostnamen, den der Browser bei der HTTP- oder HTTPS-Verbindung übermittelt.

Aus einer IP-Adresse lässt sich daher meist nicht zuverlässig ableiten, welche einzelne Person oder welches Unternehmen einen Server betreibt. Auch die Zuordnung eines Hostnamens zu einer Adresse kann sich ändern.

IP-Adresse einer Website ermitteln und den DNS-Pfad nachvollziehen

Wenn Sie nicht nur die Endadresse, sondern den Auflösungsweg verstehen möchten, können Sie die DNS-Kette genauer untersuchen.

Mit dig zeigt diese Abfrage zusätzliche Informationen:

dig beispiel.de

Für eine nachvollziehbare Auflösung über die Nameserver ist unter Unix-ähnlichen Systemen häufig dieser Befehl geeignet:

dig +trace beispiel.de

Die Ausgabe beginnt bei den Root-Nameservern und folgt anschließend den zuständigen Ebenen bis zur Domain. Das kann helfen, Delegationsprobleme oder unerwartete Nameserver zu erkennen. Die Darstellung ist allerdings technisch und für eine einfache IP-Abfrage meist nicht erforderlich.

Zusätzlich können Sie die autoritativen Nameserver der Domain abfragen:

dig NS beispiel.de +short

Die Nameserver verwalten die maßgeblichen DNS-Einträge. Der Resolver, den Ihr Gerät normalerweise verwendet, liefert dagegen häufig eine zwischengespeicherte Antwort.

Reverse-DNS: Von der IP-Adresse zum Hostnamen

Eine Vorwärtsabfrage übersetzt einen Hostnamen in eine IP-Adresse. Bei einer Reverse-DNS-Abfrage wird umgekehrt geprüft, ob zu einer IP-Adresse ein PTR-Eintrag existiert.

Mit nslookup können Sie beispielsweise eine Adresse prüfen:

nslookup 203.0.113.25

Mit dig ist die Form ebenfalls möglich:

dig -x 203.0.113.25

Ein Reverse-DNS-Name ist jedoch nicht automatisch der Domainname der Website. Ein Betreiber kann einen technischen Hostnamen hinterlegen, mehrere Domains können dieselbe Adresse nutzen oder es kann gar kein PTR-Eintrag vorhanden sein. Forward- und Reverse-DNS müssen nicht spiegelbildlich übereinstimmen.

Häufige Fehler bei der Abfrage vermeiden

Die komplette URL verwenden

DNS-Werkzeuge benötigen normalerweise keinen Pfad wie /blog/artikel und kein Protokoll wie https://. Verwenden Sie den Hostnamen. Bei einer URL mit Port sollten Sie den Port getrennt betrachten; er gehört nicht zum DNS-Namen.

www und die Hauptdomain verwechseln

beispiel.de und www.beispiel.de sind unterschiedliche Hostnamen. Sie können dieselbe IP-Adresse besitzen, müssen es aber nicht. Prüfen Sie deshalb genau den Namen, den Sie tatsächlich aufrufen möchten.

Eine lokale Hosts-Datei übersehen

Auf einem Computer kann die Hosts-Datei eine lokale Zuordnung enthalten. Diese kann die normale DNS-Auflösung überschreiben. Das ist in Entwicklungsumgebungen und Unternehmensnetzen nützlich, kann aber bei der Fehlersuche irritieren.

Wenn nur ein bestimmtes Gerät eine unerwartete Adresse anzeigt, vergleichen Sie die Antwort mit einem anderen Netzwerk oder einem anderen Gerät. Prüfen Sie außerdem lokale Sicherheitssoftware, VPN-Verbindungen und DNS-Einstellungen.

IP-Adresse mit Standort oder Betreiber gleichsetzen

IP-Geolokalisierung liefert nur eine technische Schätzung und kann je nach Datenbank unterschiedlich ausfallen. Sie ist kein zuverlässiger Nachweis für den tatsächlichen Standort eines Servers, einer Person oder eines Unternehmens. Auch die Registrierung einer IP-Adresse bedeutet nicht automatisch, dass dort eine bestimmte Website betrieben wird.

Praktische Entscheidungshilfe: Welche Methode passt?

Ziel Geeignete Methode Worauf achten?
Schnelle Einzelabfrage unter Windows nslookup A- und AAAA-Einträge getrennt prüfen
Ausführliche Windows-Informationen Resolve-DnsName Record-Typ und mehrere Antworten beachten
Schnelle Abfrage unter Linux oder macOS dig +short oder host Subdomain exakt eingeben
DNS-Kette analysieren dig +trace Technische Ausgabe und Delegationen auswerten
Keine Kommandozeile verfügbar Seriöser Online-DNS-Dienst Resolver, Cache und Datenschutz berücksichtigen

Für eine normale Prüfung reichen meist zwei Abfragen: eine nach A und eine nach AAAA. Bei einer Fehlersuche sollten Sie zusätzlich die Subdomain, den verwendeten Resolver und den Zeitpunkt dokumentieren.

Datenschutz und Sicherheit

Eine öffentliche DNS-Abfrage ist grundsätzlich ein normaler Bestandteil der Internetnutzung. Trotzdem sollten Sie das Ergebnis nicht überinterpretieren und keine unnötigen Informationen sammeln. Die IP-Adresse allein ist kein Beweis für eine Sicherheitslücke, eine Verantwortlichkeit oder eine bestimmte Person.

Wenn Sie eine eigene Website verwalten, prüfen Sie regelmäßig, welche Hostnamen öffentlich auflösbar sind. Interne Systeme sollten nicht versehentlich über öffentliche DNS-Zonen bekannt gemacht werden. Für administrative Aufgaben gehören außerdem Zugriffskontrollen, aktuelle Software und eine saubere Trennung zwischen öffentlichen und internen Diensten zur grundlegenden Sicherheitsvorsorge.

Bei fremden Systemen sollten Sie sich auf passive DNS-Abfragen beschränken, sofern keine ausdrückliche Erlaubnis für weitergehende Prüfungen vorliegt. Das Ermitteln einer öffentlich sichtbaren Adresse ist etwas anderes als das Scannen oder gezielte Testen eines Servers.

FAQ

Kann ich jede Website über ihre IP-Adresse öffnen?

Nicht unbedingt. Bei gemeinsam genutztem Hosting benötigt der Server den Hostnamen, um die richtige Website auszuwählen. Außerdem können HTTPS-Zertifikate, Weiterleitungen und Sicherheitsregeln den direkten Aufruf über die IP-Adresse verhindern oder eine Warnung auslösen.

Warum zeigt eine Domain mehrere IP-Adressen?

Mehrere Adressen können der Lastverteilung, Redundanz, regionalen Auslieferung oder der Unterstützung verschiedener Netzwerke dienen. Prüfen Sie sowohl A- als auch AAAA-Einträge und betrachten Sie die Antwort als aktuelle DNS-Sicht, nicht als unveränderliche Eigenschaft der Website.

Warum unterscheiden sich die Ergebnisse auf zwei Geräten?

Mögliche Gründe sind unterschiedliche DNS-Resolver, zwischengespeicherte Antworten, VPNs, Unternehmensnetzwerke, eine lokale Hosts-Datei oder ein wechselndes DNS-System. Vergleichen Sie die Abfragen mit demselben Hostnamen und notieren Sie Zeitpunkt und verwendeten Resolver.

Ist die IP-Adresse der Domain auch die IP-Adresse des Webservers?

Sie ist die öffentlich aufgelöste Zieladresse für diesen Hostnamen. Bei Reverse-Proxys, Content-Delivery-Netzwerken und Load-Balancern gehört sie möglicherweise zu einem vorgeschalteten Dienst. Der Ursprungsserver kann eine andere, nicht öffentlich sichtbare Adresse besitzen.

Was ist der Unterschied zwischen IPv4 und IPv6?

IPv4 und IPv6 sind unterschiedliche Internetprotokolle mit unterschiedlichen Adressformaten. Eine Website kann beide Varianten anbieten oder nur eine davon. Mit A fragen Sie IPv4 ab, mit AAAA IPv6.

Wie finde ich heraus, wem eine IP-Adresse gehört?

WHOIS- oder RDAP-Informationen können Hinweise auf die zuständige Organisation eines Adressbereichs liefern. Das ist jedoch nicht zwangsläufig der Website-Betreiber. Hosting, Reseller, Datenschutzangaben und vorgeschaltete Netzwerke können die Zuordnung zusätzlich erschweren.

Wie lange dauert eine Änderung der IP-Adresse?

Das hängt unter anderem von der eingestellten TTL, lokalen Caches und den verwendeten DNS-Resolvern ab. Während der Übergangszeit können verschiedene Nutzer noch unterschiedliche Antworten erhalten. Ein einzelner Test bestätigt daher nicht immer, dass die Änderung bereits überall sichtbar ist.

Fazit

Die IP-Adresse einer Website zu ermitteln, gelingt mit nslookup, Resolve-DnsName, dig, host oder einem geeigneten Online-DNS-Dienst. Für eine vollständige Prüfung sollten Sie die exakte Subdomain sowie A- und AAAA-Einträge abfragen und mehrere Antworten berücksichtigen.

Die wichtigste Einschränkung lautet: Die gefundene Adresse beschreibt den öffentlichen DNS-Zugang, nicht automatisch den tatsächlichen Ursprungsserver. CDN-Dienste, Reverse-Proxys, Load-Balancer, Caches und gemeinsam genutztes Hosting können das Ergebnis beeinflussen. Wer diese Zusammenhänge berücksichtigt, kann DNS-Abfragen sinnvoll für Fehlersuche, Administration und technische Dokumentation einsetzen, ohne aus einer IP-Adresse unzulässige Schlussfolgerungen zu ziehen.

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

Schematische Darstellung der einzelnen Pru00fcfschritte von DNS bis Webserver
Die Fehlersuche folgt dem Weg von der Domainauflösung bis zur Webserverantwort.

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.