DNS und IP-Adresse: Unterschied, Zusammenspiel und Fehler

DNS und IP-Adresse erfüllen unterschiedliche Aufgaben: Eine IP-Adresse bezeichnet ein Ziel im Netzwerk, während das Domain Name System einen Namen wie example.de in technische Informationen wie eine Ziel-IP-Adresse auflöst. DNS sagt also unter anderem, wohin eine Anfrage gehen soll. IP sorgt dafür, dass Datenpakete an diese Adresse vermittelt werden.

Für den vollständigen Aufruf einer Website reichen DNS und IP allein nicht aus. Nach der Namensauflösung übernehmen weitere Protokolle Aufgaben: TCP oder QUIC bauen die Verbindung auf, HTTP beziehungsweise HTTPS übertragen die Webinhalte. Der Webserver muss außerdem erkennen, welche Domain angefragt wurde, und bei HTTPS muss das Zertifikat zum Hostnamen passen.

Gerade bei einer nicht erreichbaren Website ist diese Trennung entscheidend. Ein korrekter Domainname beweist weder eine korrekte DNS-Konfiguration noch einen funktionierenden Server. Dieser Artikel konzentriert sich deshalb auf DNS als Auflösungssystem, den Ablauf eines Website-Aufrufs und eine praktische Fehlerdiagnose. Für die grundlegende Abgrenzung von IP-Adresse und Domain findest Du einen ergänzenden Vergleich.

Was ist der Unterschied zwischen DNS und einer IP-Adresse?

Eine IP-Adresse ist eine numerische Adresse für ein Netzwerkziel. IPv4-Adressen sehen beispielsweise wie 203.0.113.10 aus. IPv6-Adressen sind länger und verwenden zusätzlich Buchstaben, etwa 2001:db8::10. IP-Adressierung und Paketvermittlung ermöglichen es Netzwerken, Daten zum passenden Ziel weiterzuleiten.

DNS ist dagegen weder eine einzelne IP-Adresse noch eine zentrale Tabelle. Es ist ein hierarchisches, verteiltes System aus Servern und Datenbeständen. Es beantwortet Anfragen zu Domainnamen und liefert je nach Eintrag etwa IP-Adressen, Mailserver oder Verweise auf andere Namen. Die Grundlagen von Namensraum, Resource Records und Caching sind in RFC 1034 beschrieben.

Die Kurzform lautet: Die Domain ist der lesbare Name, DNS ist das Auskunftssystem und die IP-Adresse ist das technische Netzwerkziel. Ohne DNS könnten bekannte und erreichbare IP-Adressen weiterhin angesprochen werden. Im Alltag wäre das jedoch kaum praktikabel, weil Menschen Adressen aus Zahlen und Zeichenfolgen verwalten müssten und sich diese ändern können.

Domain, DNS-Server und Webserver klar unterscheiden

Eine Domain wie example.de ist ein registrierter Name. Ein Hostname wie www.example.de benennt einen konkreten Namen innerhalb dieser Domain. Erst ein DNS-Record verknüpft diesen Hostnamen mit einem Ziel oder einer weiteren Information.

Ein rekursiver DNS-Resolver nimmt die Anfrage Deines Geräts entgegen und sucht die Antwort im Cache oder bei weiteren DNS-Servern. Autoritative Nameserver halten dagegen die maßgeblichen Daten einer Domainzone bereit. Ein Webserver liefert die Website aus und ist Teil der Hosting-Infrastruktur. Er muss nicht auf demselben System wie ein DNS-Server laufen.

Ein DNS-Server besitzt selbst eine oder mehrere IP-Adressen, damit Geräte ihn erreichen können. Diese Adresse des Resolvers oder Nameservers ist aber nicht identisch mit der Ziel-IP-Adresse, die der Resolver für Deine Website zurückliefert.

DNS ist außerdem nicht auf Websites beschränkt. MX-Records nennen Mailserver, TXT-Records können Verifizierungs- oder E-Mail-Sicherheitsinformationen enthalten und CNAME-Records verweisen einen Namen auf einen anderen Namen.

Was passiert nach der Eingabe einer Domain?

Wenn Du www.example.de im Browser eingibst, prüft dieser zunächst lokale Informationen. Dazu können ein Browser-Cache, der Cache des Betriebssystems oder ein Eintrag in der lokalen hosts-Datei gehören. Die hosts-Datei kann einen Namen direkt einer IP-Adresse zuordnen und DNS für diesen Namen übergehen.

Findet das Gerät keine noch gültige lokale Antwort, fragt es den eingestellten rekursiven Resolver. Dieser verwendet gegebenenfalls seinen eigenen Cache. Andernfalls ermittelt er über die DNS-Hierarchie den zuständigen autoritativen Nameserver und fragt dort die maßgeblichen Records ab.

Ein A-Record liefert eine IPv4-Adresse, ein AAAA-Record eine IPv6-Adresse. Ein CNAME kann zunächst auf einen weiteren Hostnamen zeigen, der wiederum aufgelöst wird. Danach verbindet sich der Browser mit einer passenden Ziel-IP. TCP oder QUIC und anschließend HTTP oder HTTPS übernehmen weitere Teile der Kommunikation.

Bei HTTPS prüft der Browser zusätzlich den angefragten Hostnamen und das TLS-Zertifikat. Der Webserver erhält ebenfalls den Hostnamen und kann damit bei einer gemeinsam genutzten IP die richtige Website auswählen. Erst dann werden Inhalte wie HTML, Bilder und Skripte ausgeliefert.

Wie Domains und IP-Adressen zusammenhängen können

Zwischen Namen und IP-Adressen besteht keine feste Eins-zu-eins-Beziehung. DNS entkoppelt den vertrauten Namen von der jeweils eingesetzten Infrastruktur. Das erleichtert Umzüge, Lastverteilung und den Betrieb mehrerer Websites auf einem Server.

Die folgenden vier Konstellationen erklären, warum ein einzelner IP-Test oft nicht genügt und warum sich eine DNS-Antwort im Lauf der Zeit ändern kann.

Bei mehreren Domains auf einer IP muss der Webserver anhand des Hostnamens entscheiden, welche Website ausgeliefert wird. Der direkte Aufruf einer IP-Adresse kann daher eine Standardseite, eine falsche Website oder gar keine passende Antwort liefern.

Auch HTTPS macht den IP-Aufruf als Website-Test unzuverlässig. Zertifikate sind bei Websites meist für Domainnamen ausgestellt; deshalb kann beim Aufruf über eine rohe IP eine Warnung erscheinen. Zertifikate können technisch zwar auch IP-Adressen enthalten, das ist bei gewöhnlichen Webauftritten jedoch deutlich seltener als eine domainbasierte Konfiguration. Ein SSL- oder TLS-Zertifikat ersetzt DNS daher nicht.

Funktioniert das Internet ohne DNS?

IP-Netzwerke können grundsätzlich auch ohne DNS Daten an bekannte, erreichbare IP-Adressen übertragen. DNS ist nicht die Voraussetzung dafür, dass IP-Pakete geroutet werden. Praktisch würden aber viele Dienste nicht mehr wie gewohnt funktionieren, weil Anwendungen, Links und Nutzende überwiegend Domainnamen verwenden.

Websites auf gemeinsam genutzten IP-Adressen wären über die reine Adresse oft nicht eindeutig auswählbar. HTTPS-Prüfungen, E-Mail-Zustellung über MX-Records und viele Verifizierungen wären ebenfalls beeinträchtigt. Ein Internet ohne DNS wäre daher nicht einfach das heutige Internet mit mehr Zahlen, sondern deutlich eingeschränkter.

Beim üblichen Forward DNS wird ein Name aufgelöst: A-Records liefern IPv4-, AAAA-Records IPv6-Adressen. Reverse DNS beginnt dagegen mit einer IP-Adresse und fragt über PTR-Records nach einem zugeordneten Namen. Beide Richtungen sind unabhängig: Ein A-Record erzeugt nicht automatisch einen PTR-Record. Reverse DNS wird häufig vom Inhaber des IP-Adressbereichs verwaltet und kann etwa für Mailserver relevant sein.

DNS-Fehler und Serverprobleme systematisch unterscheiden

Eine Fehlermeldung im Browser benennt selten zuverlässig die Ursache. Prüfe deshalb nicht nur, ob eine Website „erreichbar“ ist, sondern unterscheide Namensauflösung, Verbindung, Host-Konfiguration und TLS. Mit nslookup example.de oder dig example.de A +short prüfst Du die IPv4-Auflösung; für IPv6 fragst Du einen AAAA-Record ab.

Für einen Webtest eignet sich curl -I https://example.de. Um gezielt eine bestimmte Ziel-IP zu testen und trotzdem Hostname sowie HTTPS-Kontext beizubehalten, kannst Du curl --resolve example.de:443:203.0.113.10 https://example.de verwenden.

Unterschiedliche DNS-Antworten bedeuten nicht automatisch einen Fehler bei den autoritativen Nameservern. Sie können auch durch lokale Caches, Resolver-Caches, noch gültige TTL-Werte oder unterschiedliche Resolver entstehen. Erst ein Vergleich mit mehreren Resolvern und gegebenenfalls den autoritativen Servern grenzt die Ursache weiter ein.

Funktioniert der Aufruf mit curl --resolve über die neue IP, während der normale Domainaufruf noch auf die alte Adresse führt, spricht das für DNS oder einen Cache. Liefert auch der gezielte Test einen Fehler, liegt die Ursache eher bei Webserver, Firewall oder TLS-Konfiguration.

Eine nachvollziehbare Prüfung beginnt mit einer DNS-Abfrage und endet nicht beim Ping. Die DNS-Fehlerdiagnose von Google Public DNS beschreibt ebenfalls, wie sich Resolver-Antworten und autoritative Daten getrennt untersuchen lassen.

Dokumentiere bei Problemen immer den getesteten Hostnamen, die erhaltene IP-Adresse, den verwendeten Resolver und die konkrete Fehlermeldung. Damit lässt sich später nachvollziehen, ob sich DNS, Serverzustand oder Zertifikatskonfiguration geändert haben.

DNS-Änderungen und Hosting-Wechsel vorbereiten

Nach einer DNS-Änderung können verschiedene Nutzer vorübergehend unterschiedliche IP-Adressen erhalten. Der Hauptgrund ist verteiltes Caching: Resolver speichern Antworten für die im DNS-Record festgelegte Time to Live, kurz TTL. Ein Resolver mit einer noch gültigen alten Antwort liefert weiter die bisherige IP, während ein anderer bereits die neue kennt.

Plane einen Hosting-Wechsel deshalb als Übergang zwischen zwei funktionsfähigen Systemen. Sichere vorab die gesamte DNS-Zone mit A-, AAAA-, CNAME-, MX- und TXT-Records. Prüfe, ob nur Ziel-Records geändert werden oder ob auch die autoritativen Nameserver wechseln. Bei einem Nameserver-Wechsel können fehlende Mail-, Verifizierungs- und Subdomain-Einträge Dienste beeinträchtigen, obwohl die Hauptwebsite funktioniert.

Teste die neue Website vor der Umstellung möglichst mit dem korrekten Hostnamen auf der neuen IP. Bereite TLS-Zertifikat und HTTPS-Weiterleitungen vor und halte das bisherige System während der Cache-Übergangsphase erreichbar. Bei einem Content Delivery Network können Antworten zudem bewusst je nach Infrastruktur oder Standort variieren.

Halte fest, welcher Anbieter für Domain, DNS-Zone, CDN, Hosting und Zertifikat zuständig ist. Diese Übersicht verhindert, dass bei einer Störung an der falschen Stelle geändert wird, und erleichtert die Abstimmung mit technischen Dienstleistern.

Quellen zur Einordnung: Die DNS-Grundlagen und Begriffe basieren auf RFC 1034, RFC 1035 und RFC 8499. Grundlagen zu IPv6 beschreibt RFC 8200.