DNS verstehen: So funktioniert das Internet-Telefonbuch
Im letzten Jahr habe ich eine Domain übernommen, deren Mail-Setup seit Jahren niemand angefasst hatte. SPF zeigte auf einen längst gelöschten Provider, MX-Records auf zwei Server, von denen einer nicht mehr existierte. Mails kamen unregelmäßig an. Die Diagnose war nicht "kaputtes DNS", sondern "DNS hat genau das gemacht, was drinstand — und drinstand falsches".
DNS ist konzeptuell einfach und im Detail überraschend tief. Dieser Artikel ist der Versuch, das Konzept und die wichtigsten Record-Typen so zu erklären, dass die typischen Probleme am Anfang gar nicht erst entstehen.
Was DNS macht und was es nicht macht
DNS löst Namen zu Werten auf. "Was ist die IP von matti.services?" — DNS antwortet. Das ist die Hauptaufgabe.
Was DNS nicht ist: ein Routing-Mechanismus, eine Authentifizierung oder eine Datenbank für aktuelle Zustände. DNS ist gecached an vielen Stellen — beim Resolver, beim Browser, beim Betriebssystem. Eine Änderung an einem Record ist also nicht "sofort live", sondern braucht je nach TTL Minuten bis Stunden, bis sie überall ankommt.
Die Records, die du wirklich brauchst
A — IPv4-Adresse. matti.services A 5.75.x.y.
AAAA — IPv6-Adresse. Sollte heute Standard sein, ist es bei vielen Hostern aber nicht.
CNAME — Alias auf einen anderen Namen. www.matti.services CNAME matti.services. Wichtig: CNAMEs dürfen nicht für die Apex-Domain (also matti.services ohne Subdomain) verwendet werden, weil sie mit anderen Records am gleichen Namen kollidieren. Manche Provider bieten "ALIAS" oder "ANAME" als Workaround — im Hintergrund nichts anderes als ein vom Provider regelmäßig aufgelöser A-Record.
MX — Mailserver. matti.services MX 10 mail.matti.services. Die Zahl ist die Priorität — niedrigere Zahlen werden zuerst probiert.
TXT — beliebiger Text. Wird genutzt für SPF, DMARC, Domain-Verifikation. Kein magischer Typ, einfach Text-Records.
NS — Nameserver. Sagt der Welt, welcher Server für diese Domain authoritativ ist.
TTL — der Grund, warum DNS-Änderungen schief gehen
Jeder Record hat eine TTL ("Time To Live") in Sekunden. Resolver cachen den Record für diese Dauer.
Wenn du eine Migration planst (Server-Wechsel, neuer Mail-Provider), ist die häufigste Falle: TTL nicht vorher reduziert. Wenn der A-Record auf TTL 86400 (24h) steht und du wechselst, dauert es bis zu einen Tag, bis die Änderung weltweit gilt.
Mein Vorgehen:
- Ein paar Tage vor der Migration: TTL aller relevanten Records auf 300 (5 Min) setzen
- Migration durchführen, Records ändern
- Nach 24h verifizieren, dass alles läuft
- TTL wieder hochsetzen (3600 oder 86400)
Niedrige TTLs überall lassen ist verlockend, kostet aber Performance — Resolver fragen häufiger an, was bei viel Traffic spürbar wird.
DNS-Probleme debuggen
dig ist das Standard-Tool. Wer nslookup benutzt: bitte aufhören, das ist seit zwei Jahrzehnten obsolet.
dig matti.services
dig matti.services MX
dig matti.services TXT
+short für minimale Ausgabe. @8.8.8.8 um einen bestimmten Resolver zu fragen, statt den eigenen.
dig +short matti.services @1.1.1.1
Wichtig: wenn du gerade Records geändert hast und Cloudflare/Google Public DNS schon den neuen Wert zeigen, dein Browser aber nicht — das ist OS-Level-Caching. systemd-resolve --flush-caches oder ein Reboot.
Für die ganze Resolver-Kette: dig +trace matti.services. Zeigt, wie der Lookup von der Root-Zone bis zum authoritativen Server läuft. Hilfreich, wenn du wissen willst, ob die Delegation richtig ist.
Authoritative vs. Recursive
Es gibt zwei Arten von DNS-Servern:
Authoritative — kennt die Records für eine bestimmte Domain. Cloudflare-DNS für matti.services ist authoritative.
Recursive Resolver — kennt selbst nichts, fragt sich durch die Hierarchie und cached Antworten. 8.8.8.8, 1.1.1.1, 9.9.9.9 sind public recursive resolvers.
Wer einen Mail- oder Web-Server betreibt, will einen recursive Resolver lokal haben statt den ISP-Resolver — geringere Latenz, kein Mit-Lesen durch ISP, robuster gegen Ausfälle.
DNSSEC — sinnvoll, aber Vorsicht
DNSSEC signiert DNS-Antworten, damit ein Resolver verifizieren kann, dass sie nicht manipuliert wurden. Klingt gut. In der Praxis: kann katastrophal schiefgehen, wenn ein Schlüssel-Rollover nicht korrekt läuft. Eine kaputte DNSSEC-Konfiguration macht die Domain für DNSSEC-validierende Resolver komplett unauffindbar.
Wer DNSSEC einsetzt, sollte das Setup verstehen. Bei Hostern, die das auf Knopfdruck anbieten und automatisch verwalten (Cloudflare), ist das Risiko überschaubar. Bei Self-managed Bind-Servern: nur mit klarem Recovery-Plan.
Der häufigste Bug
Ein TXT-Record wird falsch gequotet. Statt:
v=spf1 include:_spf.google.com ~all
steht da:
"v=spf1 include:_spf.google.com ~all"
Mit Anführungszeichen drum herum, doppelt im DNS. SPF-Validatoren matchen nicht. Mails landen im Spam.
Solche Fehler findet man am schnellsten mit Online-Validatoren wie dnsviz.net oder mxtoolbox.com — die zeigen Inkonsistenzen, die dig allein nicht aufdeckt.