Was ist DNS? Ein Einsteiger-Leitfaden, wie aus Domainnamen IP-Adressen werden

Wenn du google.com oder toolcluster.app in deinen Browser tippst, kommt im Bruchteil einer Sekunde eine Webseite von einem Server irgendwo auf der Welt zurück. Hältst du kurz inne, sind dabei gerade mehrere rätselhafte Dinge nacheinander passiert.

• Du tippst toolcluster.app, und ein Artikel erscheint von einem Server irgendwo auf der Welt. Aber woher kam genau die Adresse (die IP-Adresse)?
• Verbinde ein Smartphone mit dem WLAN, und Google und YouTube funktionieren einfach. Wer übersetzt im Hintergrund den Domainnamen in eine IP-Adresse?

Die meisten von uns nutzen das, ohne je darüber nachzudenken. Verfolgt man es aber zurück, findet man ein verteiltes Telefonbuch, das sich über das gesamte Internet spannt und still und leise hinter den Kulissen arbeitet.

Geräte im Internet können ohne eine IP-Adresse (die numerische Adresse im Netzwerk) nicht miteinander reden ─ siehe unseren vorherigen Artikel Was ist eine IP-Adresse?. Im Alltag tippen wir aber keine Zahlen wie 192.168.1.10; wir geben menschenfreundliche Namen wie toolcluster.app ein. Was beide miteinander verbindet, ist DNS (das Domain Name System).

In diesem Artikel arbeiten wir Folgendes auf:

• Was DNS eigentlich ist und warum es gebraucht wird (§1)
• Warum sich Domainnamen von rechts nach links sinnvoll lesen lassen (§2)
• Was hinter einer einzigen Namensauflösung passiert ─ die Reise in 7 Phasen (§3)
• Was DNS-Records wirklich sind (§4)
• Der DNS-Cache und die TTL, die still und leise 90 % des Internets tragen (§5)
• Die Ära des verschlüsselten DNS via DoH/DoT (§6)
• Wie CDNs und Apple Private Relay mit DNS zusammenhängen (§7)
• Ein paar Befehle, die du selbst ausführen kannst, um DNS auf deinem eigenen Rechner zu beobachten (§8)

Schritt für Schritt, mit Diagrammen und ohne Vorwissen.

1. Was ist DNS ─ das „Telefonbuch“ des Internets

1-1. Die Aufgabe, Namen mit Adressen zu verknüpfen

Ein Telefonbuch ist eine Möglichkeit, anhand des Namens einer Person eine Telefonnummer nachzuschlagen. Im Internet sind die entsprechenden Stücke:

• Domainname ─ die menschenfreundliche Zeichenkette, wie der Name der Person (toolcluster.app)
• IP-Adresse ─ die Nummer, die Maschinen tatsächlich zur Kommunikation nutzen, wie die Telefonnummer (203.0.113.5)

Das „Telefonbuch“, das diese beiden zusammenführt, ist DNS (das Domain Name System ─ das System, das das gesamte Internet nutzt, um „Namen → Adressen“ umzuwandeln).

1-2. Warum DNS notwendig ist

Wenn es nur um reine Erreichbarkeit ginge, könntest du einfach IP-Adressen tippen. Aber DNS existiert aus drei Gründen:

• Schwer zu merken: toolcluster.app lässt sich deutlich leichter behalten als 203.0.113.5
• Veränderlich: IP-Adressen ändern sich, sobald du Server umziehst oder den Cloud-Anbieter wechselst. Müssen Nutzer sich nur den Namen merken, kann sich die zugrundeliegende Adresse ändern, ohne dass sie es bemerken
• Auf viele Server verteilen: einen Namen mit mehreren IPs verknüpfen und Nutzer auf unterschiedliche Server rund um die Welt leiten (genau das machen CDNs, mehr dazu später)

1-3. DNS ist keine einzige riesige Datenbank

Das ist das verbreitetste Missverständnis. Viele stellen sich „eine DNS-Zentrale irgendwo auf der Welt vor, die jede Domain verwaltet“. In Wirklichkeit ist DNS ein verteiltes, hierarchisches System, das sich über das gesamte Internet erstreckt.

dein Browser
        ↕
    DNS-Resolver (ein „Stellvertreter", der die Namensauflösung in deinem Auftrag übernimmt)
        ↕
   DNS-Serverflotte, weltweit verteilt
        ├── Root-Server (".")
        ├── TLD-Server (".app", ".com" usw.)
        └── Autoritative Nameserver (von jedem Domain-Inhaber betrieben)

Die einzigen Server, die zum Beispiel die Adresse für toolcluster.app wirklich kennen, sind die autoritativen Nameserver für toolcluster.app, irgendwo in einer Ecke der Welt. Jeder andere Server kann nur sagen „nicht ich, frag dort drüben“. DNS bedeutet im Kern, die Arbeit aufzuteilen und die Frage weiterzureichen, bis jemand die Antwort hat.

2. Die Hierarchie der Domainnamen ─ von rechts nach links lesen

2-1. Wie eine Postanschrift ─ rechts wird der Bereich „weiter“

Ein Domainname wie www.toolcluster.app funktioniert genau wie eine Postanschrift: je weiter rechts du gehst, desto größer der Geltungsbereich.

www . toolcluster . app .
└─┬─┘  └────┬─────┘ └┬┘ └← der abschließende „." wird meist weggelassen, steht aber für die Root
  Sub-       Second-   TLD
  domain     Level

Wie bei einer englischen Postanschrift, die „Hausnummer → Straße → Stadt → Bundesstaat → Land“ angibt, mit der größten Einheit rechts. Der häufig weggelassene abschließende Punkt (.) steht für die größte Einheit überhaupt: die Root.

2-2. Vier Ebenen, jede mit einem „Verantwortlichen“

Die DNS-Hierarchie hat vier Ebenen:

• Root (.): die absolute Spitze des Internets. Wird als 13 Server-Cluster weltweit betrieben
• TLD (Top Level Domain): .com, .app, .jp usw. Werden von Verisign, Google und anderen betrieben
• Second-Level-Domain: der toolcluster-Teil von toolcluster.app. Hier übernimmt der Käufer der Domain die Verantwortung
• Subdomain: der www-Teil von www.toolcluster.app. Der Inhaber kann sie frei aufteilen

Jede Ebene hat ihren eigenen Verantwortlichen (den autoritativen Nameserver ─ den Server, der die IPs der Domains in seinem Bereich „wirklich kennt“). Die Reise der Auflösung läuft so, dass man von der obersten Ebene nach unten geht und der Kette der Verantwortung folgt, bis die Antwort erreicht ist.

.                            ← Root (".")
├── com                      ← TLD
├── app                      ← TLD ★ ab hier die „.app"-Leute fragen
│    └── toolcluster         ← Second-Level ★ hier sitzt der autoritative NS
│         └── www            ← Subdomain
├── jp
└── ...

3. ★ Die Reise der Namensauflösung ─ 7 Phasen

Das ist das Herzstück des Artikels. Vom Moment, in dem du toolcluster.app tippst, bis dein Browser die IP-Adresse in der Hand hält ─ was passiert da eigentlich? Wir verfolgen es durch 7 Phasen.

3-1. Zeitleiste der 7 Phasen

Jede Phase dauert wenige Millisekunden bis einige hundert Millisekunden. Schlägt während 1 bis 6 irgendwo der Cache an, werden alle darunterliegenden Phasen übersprungen (mehr in §5).

1. 1Browser-Cache prüfenWurde diese Domain ganz kürzlich aufgelöst? Der Browser sieht zuerst in seiner internen Tabelle nach.
2. 2Den OS-Stub-Resolver fragenHat der Browser sie nicht, frage den kleinen DNS-Client, der ins Betriebssystem eingebaut ist (den Stub-Resolver). Auch das Betriebssystem hat einen eigenen Cache.
3. 3An den DNS-Resolver sendenHat auch das Betriebssystem sie nicht, geht die Frage an einen externen DNS-Resolver (den deines Internetanbieters, 8.8.8.8, 1.1.1.1 usw.).
4. 4Einen Root-Server fragenDer Resolver fragt die Root: „wer ist für .app zuständig?“
5. 5Den TLD-Server fragenDer Resolver fragt den .app-TLD-Server (von der Root benannt): „wer ist für toolcluster.app zuständig?“
6. 6Den autoritativen Nameserver fragenSchließlich fragt der Resolver den autoritativen NS von toolcluster.app: „wie lautet die IP für www.toolcluster.app?“
7. 7Die Antwort fließt zurück zum BrowserDie Antwort wandert zurück Resolver → Betriebssystem → Browser und wird dabei auf jeder Schicht zwischengespeichert.

Merksatz: „Browser → Betriebssystem → Resolver → Root → TLD → Autoritativ → Zurück„. Vom Moment, in dem du Enter drückst, bis die Antwort eintrifft, läuft jede Auflösung über diese 7 Stationen (die meisten werden vom Cache abgekürzt, der vollständige Weg ist aber dieser).

3-2. Iterativ vs. rekursiv ─ „wer wird hier herumgereicht?“

Schaust du dir diese 7 Phasen genau an, wirst du merken, dass es eigentlich zwei verschiedene Stile von Anfragen gibt.

• Rekursive Anfrage: du (Browser/Betriebssystem) fragst den DNS-Resolver „gib mir einfach die endgültige Antwort„. Der Resolver erledigt die Schritte 4–6 in deinem Auftrag
• Iterative Anfrage: der DNS-Resolver fragt jeden Upstream-Server „sag mir nur, wen ich als Nächstes fragen soll„. Der Resolver wird von Server zu Server weitergereicht und sammelt die Antwort Schritt für Schritt ein

Das einzige, was hier also herumgereicht wird, ist der Resolver. Du sagst einfach „Resolver, kümmere dich darum“. Genau dieser Entwurf macht das Internet so schnell, wie es sich anfühlt.

4. DNS-Record-Typen

DNS liefert nicht nur „Name → IP“. An eine Domain hängen alle möglichen verwandten Informationen als Records, jeder mit eigenem Typ. Hier sind die 8 wichtigsten.

A und AAAA sind das IPv4/IPv6-Paar, und moderne Sites richten typischerweise beide ein. CNAME bedeutet „Alias“, sodass du, indem du www.toolcluster.app als Alias von toolcluster.app einrichtest, nur eine IP aktualisieren musst und beide Namen automatisch mitziehen.

MX, TXT und NS tauchen auf, sobald sich Dienste außer dem Web an eine Domain hängen. Möchtest du E-Mail, setzt du MX; für Domain-Authentifizierung und Spoofing-Schutz packst du SPF/DKIM/DMARC in TXT-Records ─ das ist das Standardrezept.

5. DNS-Cache und TTL ─ der unbesungene Held des Internets

Würden wir die volle Reise in 7 Phasen aus §3 für jede einzelne Verbindung ausführen, würden die Root-Server unter hunderten Millionen Anfragen pro Sekunde zusammenbrechen. In der Praxis fängt der Cache fast alles ab, und die meisten Auflösungen enden schon in Phase 1, 2 oder 3.

5-1. Der Cache hat viele Schichten

interner Browser-Cache
        ↓ wenn miss
Cache des OS-Stub-Resolvers
        ↓ wenn miss
DNS-Resolver-Cache (ISP / 8.8.8.8 / 1.1.1.1)
        ↓ wenn miss
die eigentliche Reise: Root → TLD → autoritativ

Je mehr Schichten es gibt, desto weniger Last landet weiter oben (Root und TLD).

5-2. TTL ─ wann der Cache zu verwerfen ist

An jedem Record hängt eine TTL (Time To Live ─ die maximale Anzahl Sekunden, die der Record zwischengespeichert werden darf). Bei TTL = 300 kann der Cache 5 Minuten lang weiterverwendet werden; danach muss er verworfen und neu geholt werden.

• Setzt man die TTL länger → weniger Last weiter oben, IP-Änderungen brauchen aber länger, bis sie greifen
• Setzt man die TTL kürzer → Änderungen schlagen schnell durch, aber mehr Anfragen erreichen die oberen Schichten

Das klassische Rezept vor einem Server-Umzug lautet „erst die TTL auf 60 Sekunden senken, dann umziehen“ ─ und das nutzt genau diese Eigenschaft aus.

5-3. „DNS-Propagation“ ist eigentlich keine Verbreitung

Bei Site-Umzügen hört man oft den Satz „auf die DNS-Propagation warten“. Er wird häufig missverstanden: Tatsächlich heißt das nur „darauf warten, dass die Caches rund um die Welt ablaufen“. Der neue Record wird nicht buchstäblich um den Planeten gesendet.

• ✗ Häufiges Missverständnis: die neue IP wird an jeden DNS-Server der Welt verbreitet
• ✓ Realität: jeder Resolver holt sich beim autoritativen NS einfach neu, sobald die TTL seines alten Caches abläuft

Genau deshalb beschleunigt es die „Propagation“, die TTL vorher zu senken. Hat man den Mechanismus einmal verstanden, ist es offensichtlich; ohne ihn fühlt sich diese Phase an wie zurücklehnen und auf das Beste hoffen.

6. DoH / DoT ─ die Ära des verschlüsselten DNS

Bisher haben wir stillschweigend angenommen, dass „DNS-Anfragen unverschlüsselt durchs Netz fliegen“. Lange Zeit war das auch so. Aber in den 2020er-Jahren dreht sich das Bild.

6-1. Das Problem mit Klartext-DNS

Im Klartext sind deine DNS-Anfragen für jeden im selben Netzwerk sichtbar.

• Betreiber öffentlicher WLAN-Netze sehen klar, „was du gerade besuchen willst“ (die Domainnamen)
• Internetanbieter können einen Browserverlauf auf Domain-Ebene aufbauen
• Ein Man-in-the-Middle könnte Records fälschen und dich auf eine gefälschte Site umleiten (DNS-Spoofing)

6-2. Auftritt von DoH und DoT

Die Antwort ist DoH (DNS over HTTPS) und DoT (DNS over TLS). Beide verschlüsseln die DNS-Anfrage.

6-3. Heutige Verbreitung

Die großen Browser (Firefox / Chrome / Safari) nutzen unter passenden Bedingungen automatisch DoH. Auf Unternehmensseite bringt das eine neue Herausforderung mit sich: „wie steuern wir DoH?“ ─ denn Jugendschutzfilter und Intrusion-Detection-Systeme haben bisher DNS beobachtet.

Dieses Thema verdient einen eigenen Artikel, also halte hier nur die grobe Form fest: „DNS wird verschlüsselt, und das hat Konsequenzen.“

7. CDN und DNS ─ die elegante Lüge vom „nächstgelegenen Server“

Zum Abschluss zwei reale Anwendungen von DNS, die die Performance des modernen Webs tragen.

7-1. CDNs liefern „den nächstgelegenen“ via GeoDNS

Löst du google.com aus verschiedenen Ländern auf, bekommst du je nach Standort unterschiedliche IPs zurück. Der autoritative Nameserver schaut sich Quellort und Netzwerkpfad der Anfrage an und liefert die IP des nächstgelegenen Servers. Das nennt sich GeoDNS (DNS so betreiben, dass es geografisch optimale Antworten liefert). CDNs (Content Delivery Networks) wie Cloudflare und Akamai betreiben das in massivem Maßstab.

ein Nutzer in Tokio → IP des Tokioter Edge-Servers
ein Nutzer in New York → IP des New Yorker Edge-Servers

Gleiche Domain, verschiedene Antworten ─ so geht DNS heute weit über ein „einfaches Telefonbuch“ hinaus.

7-2. Apple Private Relay hängt ebenfalls an DNS

Auf iOS / macOS ist Apple Private Relay ein Dienst, der deine DNS-Anfragen und deinen Web-Verkehr auf zwei Relays aufteilt, sodass keine einzelne Partei sie miteinander in Verbindung bringen kann. Der Ausgangspunkt für „selbst Apple kann nicht sehen, was du surfst“ ist genau die Verschlüsselung und Trennung von DNS.

So geht DNS heute über reine Namensauflösung hinaus und wird zum Scharnier für sowohl Privatsphäre als auch Auslieferungsoptimierung.

8. DNS auf deiner eigenen Maschine beobachten

Hat man die Theorie verfolgt, lohnt es sich, selbst Hand anzulegen. Tiefere Nutzung verdient einen eigenen Artikel, hier zeigen wir nur die zwei minimal nötigen Befehle.

8-1. dig (Linux / macOS)

dig toolcluster.app

In der Ausgabe ist der relevante Teil alles unterhalb von ;; ANSWER SECTION:.

;; ANSWER SECTION:
toolcluster.app.    300    IN    A    203.0.113.5

300 ist die TTL, A der Record-Typ und 203.0.113.5 die IP. Sobald du diese drei Angaben lesen kannst, wird das Wissen aus §4 und §5 zum Muskelgedächtnis.

8-2. nslookup (Windows / plattformübergreifend)

nslookup toolcluster.app

Die Zeile Server: zeigt „den DNS-Resolver, den du gerade benutzt“; die Zeile Address: zeigt „die IP für die Domain“.

8-3. Den Cache leeren

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd): sudo systemd-resolve --flush-caches

Es gibt deutlich mehr zu dig, aber das ist Stoff für einen anderen Artikel. Für diesen reicht: „eine Zeile tippen, lernen, wie man die Antwort liest„.

Zusammenfassung ─ die Essenz in 4 Zeilen

Das war ein langer Artikel, aber die Essenz passt in 4 Stichpunkte.

• DNS = der Umsetzer von Namen in Adressen. Es läuft auf einem Netz von Servern, das sich über die ganze Welt erstreckt
• Domainnamen sind hierarchisch, von rechts nach links zu lesen, und jede Ebene hat einen Verantwortlichen (den autoritativen Nameserver)
• Cache und TTL tragen rund 90 % des Internets. „DNS-Propagation“ ist keine Verbreitung; es ist warten, bis die TTLs ablaufen
• DoH/DoT und CDN zu kennen, ist es, was dich verstehen lässt, wie sich das moderne Internet verhält

Hast du dieses Skelett im Kopf, werden die Planung eines Site-Umzugs, das Eingrenzen seltsamer Latenzprobleme und das Lesen DNS-bezogener Nachrichten zu derselben Art von Aufgabe.

Für die Netzwerkadresse selbst siehe Was ist eine IP-Adresse?; für die Brücke zwischen Betriebssystem und Software siehe Warum funktioniert Software nicht ohne Installation?; und für das Zurücksetzen des angesammelten Betriebssystem-Zustands siehe Warum hilft ein Neustart?. Liest man das zusammen, fügt sich das „unsichtbare Klempnerwerk“ von PC und Internet zu einem einzigen, dreidimensionalen Bild zusammen.

FAQ

F1. Was kann ich tun, wenn DNS langsam wirkt?

A. Die ersten beiden Verdächtigen sind Cache und Wahl des Resolvers. Hilft das Leeren des lokalen Caches (ipconfig /flushdns unter Windows, jeweilige Pendants anderswo) nicht weiter, macht der Wechsel des DNS-Resolvers auf einen öffentlichen Anbieter wie 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) oder 9.9.9.9 (Quad9) die Sache oft schneller. Das lässt sich auch im heimischen Router umstellen. Beachte außerdem: Sites mit langer TTL können sich aus serverseitigen Gründen „für alle gleich langsam“ anfühlen, daher hilft es zu prüfen, ob auch andere dieselbe Trägheit erleben.

F2. Was ist die hosts-Datei? In welchem Verhältnis steht sie zu DNS?

A. Die hosts-Datei ist ein lokales Adressbuch, das das Betriebssystem vor DNS konsultiert. Auf Mac/Linux liegt sie unter /etc/hosts; unter Windows unter C:\Windows\System32\drivers\etc\hosts. Trägst du eine Zeile wie 127.0.0.1 myapp.local ein, geht der Verkehr zu myapp.local auf deinen eigenen Rechner, ganz ohne dass DNS überhaupt beteiligt wäre. Genutzt wird sie häufig während der Entwicklung oder zum Blockieren bestimmter Sites. Da sie vor DNS liegt, kann ein versehentlicher Eintrag dich grübeln lassen „warum erreiche ich diese Site nicht?“.

F3. Was passiert zwischen dem Kauf einer Domain und ihrem Erscheinen im Web?

A. Es sind grob 3 Schritte. (1) Domain kaufen bei einem Registrar (Namecheap, Cloudflare Registrar usw.); die TLD-Datenbank wird mit deiner Registrierung aktualisiert. (2) Im Kontrollpanel des Registrars die autoritativen Nameserver (NS) angeben ─ entweder eigene betreiben oder einen Managed-DNS-Dienst wie Cloudflare DNS oder Route 53 nutzen. (3) Auf diesen autoritativen NS A- oder CNAME-Records konfigurieren, die auf die IP deines Servers zeigen. Ab diesem Zeitpunkt holen sich Resolver weltweit den neuen Record, sobald ihre TTLs ablaufen.

F4. 8.8.8.8 vs. 1.1.1.1 ─ welchen sollte ich nehmen?

A. Beide sind stabile, kostenlose öffentliche DNS-Resolver. Außerhalb regionaler Unterschiede ist die Geschwindigkeit meist ein Unentschieden, sodass die Wahl auf Richtlinien und Zusatzfunktionen hinausläuft. 8.8.8.8 (Google) bringt massive Infrastruktur und einen langen Track Record; 1.1.1.1 (Cloudflare) setzt auf Datenschutzversprechen wie „Logs werden innerhalb von 24 Stunden gelöscht“. Möchtest du Filterung (Erwachseneninhalte blockieren usw.), sind 1.1.1.3 (Cloudflare for Families) und 9.9.9.9 (Quad9, blockiert Malware-Domains) Optionen. Für Zuhause oder den persönlichen Gebrauch ist 1.1.1.1 eine sichere Standardwahl; im Geschäftsumfeld, wo du SLAs und Support möchtest, ist es pragmatischer, sich auf das DNS deines ISPs oder einen kostenpflichtigen Dienst zu stützen.

F5. Bricht die Aktivierung von DoH die Unternehmenssicherheit?

A. Halb wahr; halb längst adressiert. Ältere Unternehmenssicherheit beruhte darauf, „DNS zu beobachten, um verdächtige Domains zu blockieren“, und DoH versteckt DNS tatsächlich in HTTPS, was diesen Ansatz schwächt. Moderne Unternehmensumgebungen kompensieren das aber über Endpoint-Agenten auf dem PC oder indem sie DoH durch einen internen Resolver erzwingen. Im privaten Gebrauch besteht kein großes Risiko, aber auf einem firmeneigenen PC aktiviere DoH nicht auf eigene Faust ─ es kollidiert wahrscheinlich mit der Unternehmensrichtlinie.