Der Klassiker aus meinem Support-Leben: Ein Kunde ruft an, seine Website sei „weg". Ich öffne den Browser — Seite lädt. Er öffnet seinen — Fehler. Ich frage nach Details: „Was steht da genau?" Antwort: „Es kann die Seite nicht finden." Zehn Minuten später haben wir es: Sein Router hatte als DNS-Server einen toten Resolver eingetragen, der seit zwei Monaten keine Antwort mehr lieferte. Die Website war nie weg. Sein DNS war es.

DNS ist das unsichtbare Fundament, auf dem jeder Netzwerkdienst steht. Wenn es funktioniert, merkt niemand etwas. Wenn es kaputt ist, sieht alles kaputt aus — Website weg, Mail weg, VPN weg. Dieser Artikel erklärt die Auflösung Schritt für Schritt mit echten Latenzen, die ich auf meinem Setup gemessen habe, dazu einen Spickzettel der wichtigsten Record-Typen, die TTL-Fallen, an denen Umzüge scheitern, und warum DNSSEC mehr ist als ein Buzzword.

Der Weg einer DNS-Abfrage: drei Fragen, drei Server

Wenn dein Browser bitcalc.net aufruft, weiß er nicht, welche IP dahintersteckt. Er fragt zuerst den Stub-Resolver — das ist der winzige Client in deinem Betriebssystem, der in /etc/resolv.conf oder der systemd-resolved-Konfiguration steht. Der Stub-Resolver macht nur eines: Er leitet die Anfrage an einen rekursiven Resolver weiter, den dein Provider oder dein Router konfiguriert hat. Und dieser Resolver übernimmt die eigentliche Arbeit.

Der rekursive Resolver kennt die Antwort nicht auswendig. Er muss sie sich erarbeiten — und zwar mit drei iterativen Fragen, die er an drei verschiedene Server stellt:

  1. Frage an einen Root-Server: „Wer ist zuständig für .de?" Die 13 logischen Root-Server (Buchstaben A bis M) kennen nur die Top-Level-Domains. Antwort: Die Nameserver der DENIC für .de. Das dauert bei mir gemessen 10 bis 30 Millisekunden.
  2. Frage an einen TLD-Server: „Wer ist zuständig für bitcalc.net?" Der .de-Server der DENIC kennt die autoritativen Nameserver jeder .de-Domain. Antwort: ns1.kasserver.com und ns2.kasserver.com. Wieder 10 bis 30 Millisekunden.
  3. Frage an den autoritativen Server: „Was ist die IP von bitcalc.net?" Der Auth-Server liest den A-Record aus seiner Zone und liefert die IP. Je nach Serverstandort 5 bis 20 Millisekunden.

Zusammengezählt ist eine komplett kalte Auflösung also 50 bis 150 Millisekunden — auf einer guten Leitung oft weniger als der TLS-Handshake, der danach kommt. Das Entscheidende: Der Resolver speichert jede Antwort im Cache und beantwortet die nächste Anfrage für dieselbe Domain in 0,1 bis 1 Millisekunde. Deshalb fühlt sich die zweite Anfrage so viel schneller an als die erste.

DNS-Auflösung im Detail: Stub-Resolver, rekursiver Resolver, Root-, TLD- und Auth-Server mit gemessenen Latenzen und Cache-Stufen

Ein Detail, das viele überrascht: Der Resolver fragt die Server nicht in deinem Auftrag mit deiner IP — er fragt mit seiner eigenen. Für die autoritativen Server bist du nur ein weiterer Resolver von vielen. Deshalb sehen die Logs deines Domain-Hosters Millionen von Anfragen, obwohl nur eine Handvoll Leute die Domain nutzt.

Die Record-Typen: der Spickzettel

Jede Zone ist eine Tabelle von Einträgen, und jeder Eintrag hat einen Typ. Die meisten Admins kennen A und AAAA — aber im Alltag begegnen dir mindestens zehn. Hier ist der Spickzettel, den ich mir selbst immer gewünscht hätte:

DNS-Record-Spickzettel: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV und DS mit Zweck und Beispiel

Drei davon verdienen besondere Aufmerksamkeit:

CNAME ist eine Weiterleitung, kein Alias im engeren Sinn. www → bitcalc.net heißt: „Frag noch mal nach, was bitcalc.net ist." Der Browser macht eine zweite Anfrage. Wer einen CNAME auf eine Domain legt, die selbst ein CNAME ist, baut eine Kette — und jede Kette kostet Zeit und kann brechen. CNAME auf die Apex-Domain geht übrigens nicht (dort muss ein A-Record stehen), was viele Neulinge verwirrt.

TXT-Records sind heute das Rückgrat der E-Mail-Absicherung. SPF (v=spf1 mx -all) sagt, welche Server für die Domain senden dürfen. DKIM bringt einen öffentlichen Schlüssel in die Zone. DMARC (eine TXT mit Politik) sagt Empfängern, was sie mit Mails machen sollen, die SPF und DKIM nicht bestehen. Ohne diese drei landet legale Mail heute schnell im Spam — dazu unten mehr beim Reverse-DNS.

Der DS-Record ist die Kette zu DNSSEC. Er enthält einen Hash des öffentlichen Schlüssels der Kind-Zone (DNSKEY). Damit verknüpft die Eltern-Zone (.de) die Kind-Zone (deine Domain) mit der Vertrauenskette. Mehr dazu im DNSSEC-Abschnitt.

TTL: die unsichtbare Falle bei Umzügen

Jede DNS-Antwort trägt eine TTL (Time To Live) in Sekunden — die Zeit, die Resolver die Antwort cachen dürfen. TTL 300 heißt: fünf Minuten. TTL 3600: eine Stunde. Klingt harmlos, bis du eine Website umziehst.

Vor drei Jahren habe ich eine Kunden-Website auf einen neuen Server umgezogen. Neue IP, neuer A-Record, alles gesetzt. Und dann? Ein Teil der Besucher sah stundenlang die alte Seite, ein anderer Teil schon die neue. Der Kunde rief an, ob „der Umzug noch läuft". Der Umzug war fertig — aber die TTL des alten Records stand auf 3600, und Resolver auf der Welt hielten die alte IP noch bis zu einer Stunde im Cache. Dazu kamen Resolver, die TTLs ignorieren oder verlängern. Realistisch dauerte es 24 bis 48 Stunden, bis wirklich jeder die neue IP sah.

Die Lehre, die ich seitdem bei jedem Umzug anwende:

  • Zwei bis drei Tage vorher: TTL des A-Records auf 60 Sekunden senken. So können Resolver die alte Antwort maximal eine Minute behalten.
  • Am Umzugstag: A-Record auf die neue IP ändern, Webserver starten, prüfen.
  • Zwei bis drei Tage nachher: TTL wieder auf 3600 oder mehr erhöhen — kürzere TTLs bedeuten mehr Anfragen an deine Nameserver und etwas mehr Latenz für alle.

Und umgekehrt: Wenn du eine Migration vorbereitest und wissen willst, was heute im Cache hängt, hilft ein Blick auf die TTL in deiner dig-Antwort. Der Wert sagt dir, wie lange du auf die nächste Generation von Clients warten musst.

Eigener Resolver: systemd-resolved, Unbound und der Pi-hole-Effekt

Standardmäßig fragt dein System den Resolver deines Providers — der in der Regel gut ist, aber dessen Cache teilst du dir mit einer halben Stadt. Wer seine Auflösung selbst in der Hand haben will, hat drei Optionen:

systemd-resolved ist auf den meisten modernen Distributionen schon aktiv und cached lokal. Für die allermeisten Desktops reicht das. Der Haken: Der Cache ist klein, und die Konfiguration über resolvectl ist gewöhnungsbedürftig.

Unbound ist der Klassiker für den eigenen rekursiven Resolver auf einem Server. Er fragt die Root-Server direkt, cached aggressiv und kann DNSSEC validieren. Auf meinem Raspberry Pi läuft Unbound neben Pi-hole: Pi-hole blockt Werbung und Tracking-Domains, Unbound löst alles andere selbst auf. Seitdem sind die DNS-Antworten in meinem Haushalt konsistent schnell — und ich weiß genau, welcher Server was aufgelöst hat, wenn wieder einmal etwas „nicht geht".

Der Cache-Effekt ist messbar: In meinem Setup liegt die Trefferquote bei etwa 80 Prozent. Heißt: Vier von fünf Anfragen beantwortet Unbound aus dem Cache in unter einer Millisekunde, ohne dass ein Paket das Haus verlässt. Die verbleibenden 20 Prozent gehen iterativ nach draußen. Der durchschnittliche Nutzer merkt den Unterschied kaum — aber der Admin merkt, dass er beim Debuggen einen Resolver hat, den er versteht und dessen Logs er lesen kann.

Reverse-DNS: warum Mail ohne PTR im Spam landet

Bis hierher ging es um die Frage „Welche IP gehört zu diesem Namen?" — Forward-DNS. Beim Reverse-DNS drehst du die Frage um: „Welcher Name gehört zu dieser IP?" Dafür gibt es eigene Zonen: in-addr.arpa für IPv4, ip6.arpa für IPv6. Die IP wird rückwärts geschrieben: Aus 192.168.10.5 wird der Lookup 5.10.168.192.in-addr.arpa. Die vierte Oktett steht vorne — genau umgekehrt zur Schreibweise, die du gewohnt bist. Mit dem bitcalc Subnetz-Rechner kannst du dir den Hostbereich einer Reverse-Zone direkt ausrechnen lassen, wenn du zum Beispiel die PTR-Records für ein ganzes /24 anlegen willst — Netzadresse und Reihenfolge sind schnell verwechselt.

Warum ist das wichtig? Die meisten Mailserver prüfen bei eingehender Mail, ob die IP des Absenders einen passenden PTR-Record hat. Fehlt er oder zeigt er auf einen fremden Namen, gilt die Mail als verdächtig und landet im Spam — auch wenn SPF, DKIM und DMARC perfekt sind. Ich habe einmal einen Mailserver betreut, dessen Reverse fehlte, weil der Hoster die PTR-Einträge nur auf Anfrage setzt. Ergebnis: Jede zweite Mail an GMX und Outlook verschwand im Spamordner. Ein Ticket an den Hoster, 24 Stunden später war das Problem weg.

Für IPv6 gilt dasselbe, nur mit mehr Nibbles: Jede Hex-Ziffer der Adresse wird ein Label in ip6.arpa. Wer IPv6-Adressen von Hand in Reverse-Zonen umrechnet, macht garantiert irgendwann einen Fehler — der bitcalc Zahlensystem-Konverter hilft, die Hex-Gruppen sauber auseinanderzuhalten, und die 4-Bit-Grenzen sind plötzlich offensichtlich.

DNSSEC: die Signaturkette, die niemand fälscht

Normales DNS hat ein Sicherheitsproblem: Die Antworten sind nicht authentifiziert. Ein Angreifer, der eine DNS-Antwort abfängt oder einen DNS-Cache vergiftet, kann dir eine falsche IP unterschieben — und dein Browser merkt nichts, weil er keinen Grund hat, der Antwort zu misstrauen. Das ist der Mechanismus hinter vielen DNS-Hijacking-Angriffen.

DNSSEC löst das, indem jede Zone ihre Antworten kryptografisch signiert (RRSIG-Records) und die Vertrauenskette von der Root-Zone über die TLD bis zu deiner Domain läuft. Der Anker: Die Root-Zone ist seit 2010 signiert, .de seit 2011. Deine Domain veröffentlicht einen DS-Record in der .de-Zone, der den öffentlichen Schlüssel deiner Zone verankert. Ein Resolver, der DNSSEC validiert, prüft bei jeder Antwort die Signaturkette — und weist Antworten zurück, die nicht bis zum Anker passen.

Was DNSSEC kostet: Rechenzeit auf dem Resolver (vernachlässigbar auf moderner Hardware), mehr Zonen-Pflege (Schlüsselrotation), und gelegentlich echte Kopfschmerzen, wenn eine Zone schlecht signiert ist. Ich habe eine Kundin gehabt, deren Domain nach einem Hosterwechsel ohne DS-Record in der .de-Zone dastand — die Folge war nicht „alles kaputt", sondern ein subtiler Wechselbad-Effekt: Manche Resolver validierten (und scheiterten), andere nicht. Das ist das Heimtückische an DNSSEC-Fehlern: Sie treffen nicht alle gleichzeitig, und sie äußern sich selten als klare Fehlermeldung.

Zum Prüfen gibt es zwei Befehle, die ich ständig nutze:

# Signaturkette anzeigen
dig +dnssec bitcalc.net A

# Komplette Auflösungskette Schritt für Schritt
dig +trace bitcalc.net A

dig +trace ist übrigens das beste Debugging-Werkzeug überhaupt: Es zeigt dir jede Stufe der Auflösung einzeln — Root, TLD, Auth — mit den jeweiligen Antwortzeiten. Wenn die Website „weg" ist, siehst du damit in 10 Sekunden, ob der Resolver, die TLD oder der Auth-Server das Problem ist. Der DS-Record deiner Zone lässt sich mit dem bitcalc Hash-Generator gegenprüfen: Der DS-Eintrag enthält einen SHA-256-Hash des DNSKEY — wenn dein Hoster dir einen Key liefert, kannst du den Hash selbst nachrechnen, statt zu vertrauen.

Die fünf häufigsten DNS-Fehler im Admin-Alltag

Zum Abschluss die Fehler, die ich am häufigsten sehe — und meist selbst gemacht habe:

  • Falscher Resolver konfiguriert: Ein toter oder überlasteter DNS-Server im Router oder in /etc/resolv.conf lässt alles langsam oder kaputt erscheinen. dig +short example.com mit verschiedenen Resolvern testet das in Sekunden.
  • CNAME-Ketten: Drei CNAMEs hintereinander — jede Stufe eine zusätzliche Anfrage, jede Stufe eine zusätzliche Fehlerquelle.
  • TTL bei Migrationen nicht gesenkt: Der Klassiker aus dem Umzugs-Abschnitt. TTL runter, dann umziehen, dann TTL wieder hoch.
  • Vergessene PTR-Records: Mail landet im Spam, Monitoring schlägt fehl, und niemand weiß warum.
  • DNSSEC nach Hosterwechsel: Neuer Anbieter, neuer DNSKEY, aber der DS-Record in der Eltern-Zone bleibt alt — oder verschwindet ganz. Nach jedem Wechsel die Validierung testen, nicht nur den A-Record.
Reverse-Zonen im Griff behalten: Willst du PTR-Records für ein ganzes /24 anlegen, rechne Netz- und Hostbereich vorher mit dem bitcalc Subnetz-Rechner durch — in-addr.arpa dreht die Oktett-Reihenfolge um, und genau da passieren die Tippfehler. Für IPv6-Zonen hilft der Zahlensystem-Konverter bei den Hex-Nibbles.

Fazit

DNS ist kein Zauberwerk. Eine Auflösung ist ein kleiner, klar strukturierter Dialog: Resolver fragt, Root verweist, TLD verweist, Auth antwortet — und der Cache macht alles danach fast kostenlos. Wer die Record-Typen kennt, TTLs bewusst setzt und dig +trace im Ärmel hat, verliert vor keiner „Website ist weg"-Meldung mehr die Nerven. Und wer zusätzlich Reverse-DNS und DNSSEC im Blick behält, hat Mail, die ankommt, und Zonen, die niemand fälscht.

Die Website meines Kunden von damals war übrigens nie weg. Sein Router zeigte auf einen Resolver, der seit zwei Monaten tot war. Ein Eintrag in der Router-Konfiguration, eine Minute Arbeit — und das Fundament war wieder da. Das ist DNS im Alltag: Meistens unsichtbar, aber wenn es wackelt, wackelt alles.