Der komplette Leitfaden zu DNS-Datensatztypen: Von A-Records bis Troubleshooting

DNS zu bearbeiten ist eine der wirkungsvollsten Operationen im Betrieb: Sie ändern ein paar Zeilen Text und können eine ganze Seite lahmlegen oder still den gesamten eingehenden Mailverkehr verlieren — und wenn etwas bricht, kann es Stunden dauern, bis Sie überhaupt sicher sind. Die meisten berühren je nur A-Records und CNAMEs und entdecken dann, dass ihr Verständnis an der Oberfläche bleibt, wenn sie das erste Mal eine MX-Fehlkonfiguration oder eine durch CAA blockierte Zertifikatsausstellung beißt. Diese Anleitung geht die Record-Typen durch, die zählen, wie TTL-Caching wirklich funktioniert, und einen wiederverwendbaren Troubleshooting-Workflow.

Was DNS-Auflösung tatsächlich tut

DNS ist im Kern eine verteilte Key-Value-Datenbank: Der Schlüssel ist ein Domainname, und die Werte sind Records verschiedener Typen. Wenn Sie example.com in einen Browser tippen, geschieht ungefähr Folgendes:

Browser und Betriebssystem prüfen zuerst ihre lokalen Caches; ein Treffer bedeutet gar keinen Netzwerkverkehr.
Bei einem Miss geht die Abfrage an einen rekursiven Resolver — meist von Ihrem ISP oder Unternehmen betrieben oder ein öffentlicher wie 8.8.8.8 oder 1.1.1.1.
Der Resolver startet bei den Root-Servern, fragt die .com-TLD-Server, dann die autoritativen Server von example.com, cacht die Antwort und gibt sie Ihnen zurück.

Die entscheidende Einsicht: Ihr Laptop spricht fast nie direkt mit autoritativen Servern. Dazwischen liegen Caching-Schichten. Diese eine Tatsache erklärt die zwei klassischen DNS-Phänomene — Änderungen wirken nicht sofort weltweit (alte Caches sind nicht abgelaufen), und verschiedene Regionen sehen im selben Moment verschiedene Antworten (ihre Caches sind in verschiedenen Zuständen). Behalten Sie diese Kette im Kopf; TTL und Troubleshooting bauen direkt darauf auf.

A-Records: IPv4-Adressen

Der A-(Address-)Record ist das Arbeitstier — er mappt einen Namen auf eine IPv4-Adresse:

example.com.    300    IN    A    93.184.216.34

Ein einzelner Name kann mehrere A-Records halten, und Resolver geben alle zurück; Clients laufen typischerweise per Round-Robin durch die Liste. Das ist die grobste Form des Load Balancings, mit einem Haken: DNS-Round-Robin hat kein Health Checking. Stirbt eine Maschine, bekommt ein Bruchteil Ihrer Nutzer noch immer die tote Adresse. Produktions-Load-Balancing gehört zu einem echten LB oder CDN, nicht zu einem Haufen A-Records.

AAAA-Records: IPv6-Adressen

AAAA-Records sind strukturell identisch mit A-Records, außer dass sie auf eine IPv6-Adresse zeigen. Der Name ist ein Scherz über die Größe: IPv6-Adressen sind 128 Bits, viermal die 32 Bits von IPv4 — daher vier A:

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Das übliche Muster ist, sowohl A als auch AAAA zu veröffentlichen. IPv6-fähige Clients bevorzugen AAAA; alles andere fällt auf A zurück. Veröffentlichen Sie nur einen A-Record, und Nutzer in reinen IPv6-Netzen erreichen Sie womöglich gar nicht.

CNAME-Records: Aliase

Ein CNAME-(Canonical Name-)Record sagt „dieser Name ist nur ein Alias für jenen anderen Namen“, und die Auflösung folgt dem Alias:

www.example.com.    300    IN    CNAME    example.com.

Fragen Sie nach dem A-Record von www.example.com, sieht der Resolver den CNAME, zieht los, den A-Record von example.com aufzulösen, und gibt die ganze Kette zurück. Der Alltags-Anwendungsfall ist, Subdomains auf Drittanbieterdienste zu zeigen — ein CDN oder eine gehostete Plattform, die Ihnen einen Hostnamen reicht.

MX-Records: Wohin E-Mail geliefert wird

MX-(Mail Exchange-)Records sagen der Welt, welche Server E-Mail für Ihre Domain annehmen. Sie tragen ein zusätzliches Prioritätsfeld — niedrigere Zahlen gewinnen:

example.com.    300    IN    MX    10 mail.example.com.
example.com.    300    IN    MX    20 backup-mx.example.com.

Absender versuchen zuerst Priorität 10 und fallen bei Fehlschlag auf 20 zurück. Zwei Regeln lassen Menschen stolpern: Das MX-Ziel muss ein Hostname sein (der selbst über A/AAAA-Records auflöst), keine IP-Adresse — und es darf kein CNAME sein. Mehr zu beidem im Abschnitt über Fehlkonfigurationen.

TXT-Records: Verifizierung und Richtlinientext

TXT-Records lassen Sie beliebigen Text an einen Namen hängen. In der Praxis dienen sie zwei dominanten Zwecken: Domaininhaberschafts-Verifizierung und Anti-Spoofing-Richtlinie für E-Mail:

example.com.    300    IN    TXT    "v=spf1 include:_spf.example.net ~all"
example.com.    300    IN    TXT    "google-site-verification=abc123..."
_dmarc.example.com. 300 IN  TXT    "v=DMARC1; p=quarantine"

SPF (welche Server Mail für Sie senden dürfen), DKIM-Public-Keys, DMARC-Richtlinie und jede „beweise, dass du diese Domain besitzt“-Prüfung von SaaS-Plattformen leben alle in TXT-Records. Ein Name kann viele TXT-Records gleichzeitig halten; sie stören sich nicht.

NS und SOA: Delegation und Zonenverwaltung

NS-(Name Server-)Records deklarieren, welche autoritativen Server für diese Zone verantwortlich sind:

example.com.    172800    IN    NS    ns1.dns-provider.com.

Wenn Sie bei Ihrem Registrar „Nameserver ändern“, aktualisieren Sie die NS-Records, die die Parent-Zone für Sie hält. Der Grund, warum eine DNS-Provider-Migration „ein bis zwei Tage zum Propagieren braucht“, ist, dass NS-Records typischerweise lange TTLs tragen und überall Resolver auf gecachten Kopien sitzen.

SOA (Start of Authority) ist der eine Record, den jede Zone genau einmal haben muss. Er hält administrative Metadaten: den primären Nameserver, den Admin-Kontakt, eine Seriennummer (Sekundärserver vergleichen Serien, um Zonenupdates zu erkennen), plus Refresh-, Retry-, Expiry- und Negative-Caching-Timer. Sie werden die SOA selten von Hand bearbeiten, aber sie in dig-Ausgaben ständig sehen.

CAA und SRV: Seltener, aber nützlich

CAA-(Certification Authority Authorization-)Records deklarieren, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen:

example.com.    300    IN    CAA    0 issue "letsencrypt.org"

Mit CAA in Kraft werden Ausstellungsanfragen jeder nicht gelisteten CA verweigert — eine echte Verteidigung gegen Fehlausstellung. Der klassische Stolperstein: Sie haben CAA auf eine CA an der Hauptdomain eingeschränkt, und Monate später scheitert eine Zertifikatsanfrage einer anderen CA für eine Subdomain mysteriös. CAA-Records werden den Baum hinab vererbt, die Parent-Richtlinie gilt also, sofern die Subdomain sie nicht überschreibt.

SRV-(Service-)Records beschreiben „welcher Host und Port diesen Dienst bereitstellt“, mit Prioritäts-, Gewichtungs- und Port-Feldern:

_sip._tcp.example.com.    300    IN    SRV    10 60 5060 sipserver.example.com.

SRV begegnet Ihnen in SIP, XMPP und Minecraft-Server-Setups. Gewöhnliche Webseiten brauchen es nie, aber wenn Sie einen Namen mit Unterstrich-Präfix wie _service._protocol.domain sehen, wissen Sie nun, was es ist.

Um zu sehen, welche Records eine Domain aktuell veröffentlicht, ohne ein Terminal zu öffnen, zeigt das DNS-Lookup-Tool die aufgelösten Records für eine Domain direkt.

Warum CNAME nicht mit anderen Records koexistieren kann

Das ist die am häufigsten verletzte DNS-Regel: Ist ein Name einmal ein CNAME, darf er keinen anderen Record-Typ halten (DNSSEC-Interna beiseite). Die Logik ist solide — ein CNAME bedeutet „alles an diesem Namen ist durch jenen anderen Namen definiert“, ein gleichzeitiger A-Record würde also einen unlösbaren Widerspruch erzeugen, welche Antwort autoritativ ist.

Die berühmte Konsequenz: Ihre Apex-Domain (example.com) kann kein CNAME sein. Der Apex muss SOA- und NS-Records tragen, und ein CNAME kann nicht mit ihnen koexistieren — also ist example.com CNAME cdn.example.net ungültig. Deshalb zeigen so viele CDN-Setups www auf den Anbieter und lassen die nackte Domain als unbequemen Sonderfall.

Workarounds: Nutzen Sie A/AAAA-Records, die auf die IPs des Dienstes zeigen (Sie sind für Updates verantwortlich, wenn sie sich ändern), oder nutzen Sie eine Anbieter-Erweiterung namens CNAME Flattening, ALIAS oder ANAME, bei der der autoritative Server das Ziel dynamisch auflöst und A-Records zurückgibt, als hätte der Apex sie. Diese Erweiterungen sind anbieterspezifisch, nicht Teil des DNS-Standards — Namen, Semantik und Randfälle unterscheiden sich zwischen Anbietern, und Konfigurationen portieren nicht unbedingt beim Wechsel.

TTL und Caching-Verhalten

Jeder Record trägt eine TTL (Time To Live), gemessen in Sekunden: wie lange die Antwort gecacht werden darf. Die 300 in den obigen Beispielen bedeutet fünf Minuten. Hat ein rekursiver Resolver die Antwort einmal, serviert er die gecachte Kopie, bis die TTL abläuft, ohne den autoritativen Server erneut zu fragen.

TTL ist ein Kompromiss:

Lange TTL (z. B. 86400 Sekunden, ein voller Tag): weniger Last auf autoritativen Servern, schnellere Wiederholungsauflösung — aber Änderungen rollen langsam aus.
Kurze TTL (60–300 Sekunden): Änderungen werden in Minuten wirksam, auf Kosten von mehr Abfrageverkehr und etwas höherer Auflösungslatenz.

Die wertvollste Betriebsgewohnheit in dieser ganzen Anleitung: Senken Sie vor einer geplanten Migration die TTL mindestens eine volle alte TTL-Periode im Voraus. Ist die aktuelle TTL 86400, senken Sie sie mindestens einen Tag vorher auf 300, warten Sie, bis die Caches der Welt die Kurz-TTL-Version halten, schneiden Sie dann die IP um — der Wechsel schließt in Minuten ab. Ist alles stabil, erhöhen Sie die TTL wieder. Haben Sie je einen Record geändert und von der halben Team „bei mir geht’s“ und von der anderen „noch kaputt“ gehört, sahen Sie alte TTLs in Echtzeit ablaufen.

Häufige Fehlkonfigurationen

Die DNS-Fehler, die im Feld tatsächlich passieren, sind eine kurze Liste:

CNAME am Apex: ungültig; die meisten DNS-Anbieter verweigern das Speichern, aber manche UIs lassen es durch und erzeugen bizarre Auflösungs- und Mailausfälle. Nutzen Sie A/AAAA oder das ALIAS-artige Feature Ihres Anbieters.
MX zeigt auf einen CNAME: von den RFCs ausdrücklich verboten. Zeigen Sie MX auf einen Hostnamen mit eigenen A/AAAA-Records, wie mail.example.com.
TTL vor einer Migration nicht senken: Sie ändern die IP, merken dann, dass die alte Antwort einen Tag gecacht ist, und können nur warten. Siehe den vorigen Abschnitt für die richtige Reihenfolge.
CNAME mit anderen Records am selben Namen gemischt: z. B. ein CNAME plus ein TXT-Record auf blog.example.com. Es verletzt die Koexistenzregel und verhält sich unvorhersehbar.
Veraltete Daten beim alten Anbieter während eines Nameserver-Wechsels: Halten Sie Records auf alten und neuen autoritativen Servern während des Übergangsfensters identisch, sonst lösen manche Nutzer veraltete Daten auf.
CAA zu restriktiv: Nur eine CA ist autorisiert, und eine spätere Zertifikatsanfrage einer anderen CA scheitert aus Gründen, die niemand mit DNS verbindet.

Troubleshooting-Workflow: dig, nslookup und Propagation

DNS-Troubleshooting läuft auf eine Frage hinaus: Sind die autoritativen Daten falsch, oder sind die Caches nur veraltet? Ein wiederverwendbarer Workflow:

Fragen Sie den autoritativen Server direkt, jeden Cache umgehend, um die „Wahrheit“ zu sehen:

dig @ns1.dns-provider.com example.com A +short

Ist die autoritative Antwort selbst falsch, korrigieren Sie die Konfiguration bei Ihrem DNS-Anbieter.

Fragen Sie öffentliche rekursive Resolver, um zu sehen, was gecacht ist:

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com MX

Vergleichen Sie Schritt 1 und 2: autoritativ korrekt, aber rekursiv veraltet heißt, Caches sind noch nicht abgelaufen — warten Sie die TTL ab oder prüfen Sie weiter. Beide stimmen überein, passen aber nicht zu Ihrer Erwartung, heißt die Konfigurationsänderung ist nie wirklich gelandet.

Lesen Sie die vollständige Antwort und den TTL-Countdown: Ein schlichtes dig example.com A (ohne +short) zeigt die verbleibende TTL — sie sinkt bei jeder Abfrage — und welcher Server antwortete. dig +trace example.com läuft die ganze Delegationskette von Root bis autoritativ durch und zeigt genau, welche Ebene sich falsch verhält. Auf Systemen ohne dig (Standard-Windows) decken nslookup example.com und nslookup -type=MX example.com dasselbe Gelände ab.
Prüfen Sie die Propagation über Regionen: Resolver in verschiedenen Geografien halten verschiedene Cache-Zustände. Ohne Terminal gibt Ihnen das DNS-Lookup-Tool einen schnellen Blick auf die aktuellen Record-Werte; kombinieren Sie es mit dem Vergleich autoritativ-vs-rekursiv, um zu entscheiden, ob Sie nur Propagationsverzögerung beobachten.
Gehen Sie bei Mailproblemen die MX-Kette durch: Hat der MX-Zielhostname tatsächlich einen A-Record? Ist die IP, auf die er auflöst, der Mailserver, den Sie erwarten? Das IP-Adress-Lookup-Tool sagt Ihnen, wem diese IP gehört, was den klassischen Fall „Mail wird an einen längst abgeschalteten Server geliefert“ abfängt.

Eine oft übersehene Voraussetzung: DNS-Records drehen sich um Hostnamen, und der Hinweis in Ihrer Hand ist oft eine vollständige URL. Lassen Sie sie durch den URL-Parser laufen, um zuerst den Hostnamen zu extrahieren — fügen Sie keine Pfade und Query-Strings in dig ein.

DNS hat wenige Regeln, doch jede wird auf die harte Tour gelernt, bis jemand sie aufschreibt: A ist IPv4, AAAA ist IPv6, CNAME ist ein exklusiver Alias, MX braucht eine Priorität und ein Nicht-Alias-Ziel, TTL ist in Sekunden und wird vor einer Migration gesenkt. Verinnerlichen Sie das, plus die autoritativ-vs-rekursiv-Diagnose, und die meisten DNS-Vorfälle lösen sich in zehn Minuten.