DNS-Records einfach erklärt: A, AAAA, MX, NS, CNAME, TXT, ALIAS & SRV

Grundlagen: Zone, Name, Typ, TTL und Zielwert

Ein typischer Zonendatei-Eintrag folgt dem Muster Name TTL Klasse Typ Wert. Die Klasse lautet im normalen Internetbetrieb fast immer IN. Der abschließende Punkt in www.example.com. markiert einen vollständig qualifizierten Domainnamen. Ohne Punkt ergänzen manche Oberflächen automatisch die aktuelle Zone; andere Systeme interpretieren die Eingabe anders. Die TTL steht in Sekunden. 300 bedeutet fünf Minuten, 3600 eine Stunde und 86400 einen Tag. Kurze TTLs erleichtern Änderungen, hohe TTLs reduzieren Abfragen und stabilisieren unveränderte Dienste.

DNS-Antworten können außerdem unterschiedlich aussehen: NXDOMAIN bedeutet, dass der Name nicht existiert. NOERROR ohne passenden Datensatz bedeutet, dass der Name existiert, aber nicht mit dem angefragten Typ. SERVFAIL weist oft auf DNSSEC-, Delegations- oder Serverprobleme hin. Diese Unterschiede helfen bei der Fehlersuche erheblich, weil nicht jede „Domain funktioniert nicht“-Meldung dieselbe Ursache hat.

A-Record (Address Record)

Der A-Record ordnet einen Domainnamen einer 32-Bit-IPv4-Adresse zu. Er ist einer der häufigsten DNS-Records und beantwortet die Frage, unter welcher IPv4-Adresse ein Host erreichbar ist. Ein typischer Eintrag lautet example.com. 300 IN A 192.0.2.1. Die Adresse 192.0.2.1 stammt aus einem Dokumentationsnetz und eignet sich für Beispiele, nicht für produktive Systeme. In der Praxis zeigt ein A-Record auf einen Webserver, Load Balancer, Reverse Proxy, API-Endpunkt oder eine Plattformadresse.

Funktionsweise: Wenn ein Nutzer eine Domain im Browser öffnet, fragt sein System über einen rekursiven Resolver nach der passenden Adresse. Der Resolver folgt der DNS-Hierarchie bis zum autoritativen Nameserver der Zone oder nutzt eine gültige Cache-Antwort. Der A-Record liefert anschließend die IPv4-Adresse. Erst danach baut der Client die eigentliche Verbindung zu HTTP, HTTPS, SSH oder einem anderen Dienst auf. DNS verbindet also Namen mit Zielen, prüft aber nicht, ob der Webserver dort korrekt antwortet.

Wichtige Aspekte: Mehrere A-Records für denselben Namen ermöglichen einfaches Round-Robin-DNS. Das verteilt Antworten, ersetzt aber kein professionelles Load Balancing mit Health Checks. Wenn ein Zielserver ausfällt, können Resolver weiterhin dessen IP-Adresse ausliefern, bis der Record geändert wurde und Caches abgelaufen sind. Vor Migrationen sollte man die TTL frühzeitig senken, mindestens die alte TTL abwarten und erst dann den Zielwert ändern. Häufige Fehler sind eine falsche IP-Adresse, ein vergessener paralleler AAAA-Record oder die Annahme, DNS-Änderungen würden weltweit sofort sichtbar.

Zusätzliche Informationen: A-Records eignen sich ausschließlich für IPv4. Für IPv6 verwendet man AAAA-Records. Eine Domain kann beide Typen parallel haben. Das nennt man Dual Stack. Bei CDN- und Cloud-Anbietern zeigt der A-Record oft nicht auf einen einzelnen Server, sondern auf eine Anycast-, Proxy- oder Load-Balancer-Adresse. In solchen Setups prüft man neben DNS auch TLS-Zertifikat, Hostheader, Weiterleitungen und Anwendungserreichbarkeit.

AAAA-Record (IPv6 Address Record)

Der AAAA-Record ist das IPv6-Pendant zum A-Record und ordnet einen Domainnamen einer 128-Bit-IPv6-Adresse zu. Ein Beispiel lautet example.com. 300 IN AAAA 2001:db8::10. Der Präfix 2001:db8::/32 ist für Dokumentation reserviert. Produktive Einträge müssen aus dem eigenen Hosting-, Provider- oder Unternehmensnetz stammen. IPv6-Adressen wirken länger, folgen aber klaren Kürzungsregeln: zusammenhängende Nullgruppen dürfen einmalig mit :: verkürzt werden.

Funktionsweise: Ein AAAA-Record liefert keine IPv4-Adresse, sondern einen IPv6-Endpunkt. Viele moderne Clients bevorzugen IPv6, wenn A und AAAA vorhanden sind. Deshalb kann eine Website für einen Teil der Nutzer gestört sein, obwohl IPv4 sauber funktioniert. Typische Ursachen sind fehlende Firewallfreigaben, falsche Routen, ein Webserver ohne IPv6-Listener oder ein CDN, das für IPv6 anders konfiguriert ist als für IPv4.

Wichtige Aspekte: IPv6 bringt einen sehr großen Adressraum und erleichtert direkte Adressierung, liefert aber keinen automatischen Sicherheitsgewinn. IPsec kann mit IPv6 genutzt werden, läuft jedoch nicht automatisch und ersetzt keine Firewall, keine Zugriffskontrolle und kein Monitoring. Wer AAAA-Records veröffentlicht, muss den gesamten Pfad prüfen: DNS, Routing, Paketfilter, Reverse Proxy, TLS-Zertifikat, Anwendung und Logs.

Zusätzliche Informationen: Für Tests eignen sich dig example.com AAAA, externe IPv6-Monitoringpunkte und echte Anwendungstests über IPv6. Bei Migrationen darf man AAAA nicht als Nebensache behandeln. Ein alter AAAA-Record kann trotz korrekt geändertem A-Record weiterhin Traffic zum alten System lenken. Das Fehlerbild wirkt dann zufällig, weil es von Netz, Client, Resolver und bevorzugtem Protokoll abhängt.

MX-Record (Mail Exchange Record)

Der MX-Record gibt an, welche Mailserver E-Mails für eine Domain annehmen. Die niedrigste numerische Preference besitzt die höchste Priorität. Ein Beispiel lautet example.com. 300 IN MX 10 mail1.example.com. und example.com. 300 IN MX 20 mail2.example.com.. Sendende Mailserver versuchen zuerst den Eintrag mit Preference 10. Wenn dieser nicht erreichbar ist, können sie den nächsten Eintrag nutzen. Das Ziel eines MX-Records muss ein Hostname sein und anschließend per A oder AAAA auflösbar sein.

Funktionsweise: Beim Versand an user@example.com fragt der sendende Mailserver die MX-Records von example.com ab. Gibt es mehrere gleichrangige MX-Records, kann der Sender zwischen ihnen verteilen. Gibt es keine MX-Records, existieren historisch definierte Fallbacks auf A oder AAAA, auf die man sich im professionellen Betrieb jedoch nicht verlassen sollte. Saubere Mailzustellung braucht explizite MX-Einträge, erreichbare Zielhosts, passende TLS-Konfiguration, korrekte Banner und konsistente Anti-Spoofing-Records.

Wichtige Aspekte: Mehrere MX-Records erhöhen nur dann die Ausfallsicherheit, wenn alle beteiligten Mailserver dieselben Richtlinien, Warteschlangen, TLS-Einstellungen und Spamfilter beherrschen. Ein schlecht konfigurierter Backup-MX kann Spam annehmen, Policies umgehen oder Nachrichten verspätet zustellen. SPF, DKIM und DMARC schützen nicht den MX-Record selbst, sondern die Authentisierung sendender Systeme und die Reputation der Domain.

Zusätzliche Informationen: Für sendende Mailserver ist Reverse DNS wichtig. PTR-Records liegen in Reverse-Zonen wie in-addr.arpa für IPv4 und ip6.arpa für IPv6. Gute Praxis ist forward-confirmed reverse DNS: Die sendende IP zeigt per PTR auf einen Hostnamen, und dieser Hostname zeigt per A oder AAAA zurück auf die sendende IP. PTR ersetzt SPF, DKIM und DMARC nicht, verbessert aber Plausibilität und Zustellbarkeit.

NS-Record (Name Server Record)

Der NS-Record gibt an, welche Nameserver für eine Zone autoritativ sind. Autoritative Nameserver liefern die maßgeblichen Antworten für eine Domain. Rekursive Resolver nehmen dagegen Anfragen von Clients entgegen, durchlaufen die DNS-Hierarchie und speichern Antworten zwischen. Ein Beispiel lautet example.com. 3600 IN NS ns1.example.com. und example.com. 3600 IN NS ns2.example.com.. Für stabile Domains sollten mehrere Nameserver existieren, idealerweise in voneinander unabhängigen Netzen.

Funktionsweise: Die Delegation einer Domain liegt in der Parent-Zone, zum Beispiel bei der TLD. Dort stehen die zuständigen Nameserver. Innerhalb der eigenen Zone stehen ebenfalls NS-Records. Beide Ebenen sollten zusammenpassen. Weichen sie ab, entstehen schwer erkennbare Fehler, weil manche Resolver der Parent-Delegation folgen, während Diagnosewerkzeuge direkt abweichende autoritative Daten sehen. Ein solcher Zustand kann zu inkonsistenten Antworten führen.

Wichtige Aspekte: Wenn ein Nameserver unterhalb der eigenen Domain liegt, etwa ns1.example.com, benötigt die Parent-Zone Glue Records. Diese A- oder AAAA-Adressen verhindern ein Auflösungsproblem, bei dem der Resolver den Nameservernamen nur über die Zone finden könnte, die er erst erreichen will. Typische Fehler sind lame delegations, fehlender Glue, alte Nameserver beim Registrar oder autoritative Server, die für die Zone nicht korrekt antworten.

Zusätzliche Informationen: Jede Zone besitzt genau einen SOA-Record. Er enthält unter anderem den primären Nameserver, die verantwortliche Mailbox, die Serial sowie Zeitwerte für Refresh, Retry und Expire. In klassischem Primary-Secondary-Betrieb entscheidet die Serial, ob sekundäre Nameserver eine neue Zonenversion übernehmen. Negative Antworten wie NXDOMAIN oder NOERROR/NODATA werden ebenfalls gecacht; deshalb können auch korrigierte fehlende Records noch für eine gewisse Zeit scheinbar fehlen.

CNAME-Record (Canonical Name Record)

Ein CNAME-Record ordnet einen Namen einem anderen Domainnamen zu. Er erstellt also einen Alias. DNS führt dabei keine HTTP-Weiterleitung aus. Der Resolver erhält den kanonischen Namen und löst diesen anschließend weiter auf. Ein Beispiel lautet www.example.com. 300 IN CNAME example.com.. Der Browser bleibt bei der angefragten URL; nur die DNS-Auflösung folgt dem Alias.

Funktionsweise: CNAMEs eignen sich besonders für Subdomains, die auf externe Plattformen zeigen: www, shop, status oder docs. Ändert der Plattformanbieter seine IP-Adressen, muss der Kunde nicht jedes Ziel selbst pflegen. Der Alias zeigt weiterhin auf den vom Anbieter kontrollierten Hostnamen. Dadurch reduziert CNAME Wartungsaufwand, erhöht aber die Abhängigkeit vom Zielnamen und dessen DNS-Verfügbarkeit.

Wichtige Aspekte: Die entscheidende Regel lautet: Wenn an einem Namen ein CNAME existiert, dürfen an genau diesem Namen keine anderen Record-Typen koexistieren. Die Aussage, CNAME dürfe innerhalb einer Zone nur einmal vorkommen, wäre falsch. Eine Zone kann viele CNAMEs enthalten, solange sie unterschiedliche Namen betreffen. Am Zonen-Apex, also direkt bei example.com., ist ein echter CNAME praktisch ausgeschlossen, weil dort zwingend SOA- und NS-Daten existieren.

Zusätzliche Informationen: Häufige Fehler entstehen durch CNAME-Ketten, falsche Zielnamen, fehlende abschließende Punkte in Zonendateien oder parallele TXT-Validierungen am gleichen Namen. Auch Maildomains dürfen nicht blind per CNAME ersetzt werden, wenn am selben Namen MX-, SPF-, DKIM- oder DMARC-nahe Einträge erforderlich sind. Für die Root-Domain nutzt man stattdessen A/AAAA, Weiterleitung auf www oder providerabhängiges Flattening.

ALIAS-Record

Der ALIAS-Record erfüllt in vielen DNS-Oberflächen einen ähnlichen Zweck wie ein CNAME, ist aber kein universell standardisierter DNS-Record-Typ wie A, MX oder CNAME. Anbieter verwenden auch Begriffe wie ANAME, Apex Alias oder CNAME-Flattening. Die Funktion löst ein Ziel intern auf und veröffentlicht nach außen passende A- oder AAAA-Antworten. Dadurch kann eine Root-Domain wie example.com komfortabel auf ein CDN- oder Plattformziel zeigen, ohne am Apex einen echten CNAME zu setzen.

Funktionsweise: Der DNS-Anbieter fragt den hinterlegten Zielnamen ab, übernimmt dessen Adressen und beantwortet öffentliche Anfragen mit synthetisierten A- oder AAAA-Records. Aus Sicht des Clients sieht die Antwort wie eine normale Adressauflösung aus. Aus Sicht des Administrators bleibt die Konfiguration hostnamenbasiert. Diese Übersetzung ist providerabhängig; deshalb funktionieren Zonendatei-Beispiele mit IN ALIAS nicht überall und können bei klassischen DNS-Servern ungültig sein.

Wichtige Aspekte: ALIAS vereinfacht SaaS- und CDN-Anbindungen am Apex, erschwert aber Debugging. Öffentlich sichtbar ist nur das Ergebnis, nicht zwingend der intern konfigurierte Zielname. TTL-Verhalten, IPv6-Unterstützung und Aktualisierungsintervalle hängen vom Anbieter ab. Vor einem Providerwechsel muss man prüfen, ob die Zielplattform echte A/AAAA-Adressen, eine Subdomain per CNAME oder ein kompatibles Flattening-Verfahren erwartet.

Zusätzliche Informationen: ALIAS löst nicht jedes Apex-Problem. Mail, Verifikation, CAA, DNSSEC und andere Records bleiben weiterhin separat zu pflegen. Bei kritischen Domains dokumentiert man den intern gesetzten Zielnamen, die öffentlich gelieferten A/AAAA-Antworten und die vom Anbieter angegebene Aktualisierungslogik. Nur so lässt sich später nachvollziehen, ob eine Störung vom DNS-Anbieter, vom Zielhost oder von Caches stammt.

TXT-Record (Text Record)

Der TXT-Record wurde ursprünglich für frei definierbaren Text vorgesehen. Heute nutzt man ihn vor allem für Domainverifikation, SPF, DKIM, DMARC und andere Sicherheits- oder Plattformnachweise. Technisch besteht ein TXT-RR aus einem oder mehreren Character-Strings. Jeder einzelne String ist auf 255 Oktette begrenzt. Lange DKIM-Schlüssel erscheinen deshalb oft als mehrere direkt hintereinander notierte Strings innerhalb desselben TXT-Records. Das ist nicht dasselbe wie mehrere unabhängige TXT-Records mit gleicher Bedeutung.

Funktionsweise: Dienste lesen TXT-Records, um Besitz oder Richtlinien zu prüfen. SPF definiert, welche Systeme im Namen einer Domain senden dürfen, etwa example.com. IN TXT "v=spf1 include:_spf.example.net -all". Für eine Domain sollte genau ein SPF-Record existieren; mehrere SPF-Records führen zu Fehlern. DKIM veröffentlicht öffentliche Schlüssel unter Selektoren wie selector1._domainkey.example.com. DMARC liegt unter _dmarc.example.com und legt fest, wie Empfänger mit Nachrichten umgehen sollen, die SPF- oder DKIM-Prüfungen nicht im Alignment bestehen.

Wichtige Aspekte: SPF hat ein Limit von zehn DNS-Lookups für Mechanismen wie include, a, mx, exists und redirect. Überschreitet eine Domain dieses Limit, können Empfänger SPF als fehlerhaft bewerten. +all ist praktisch immer falsch, weil es jeden Sender erlaubt. ~all eignet sich für vorsichtige Übergänge, -all für klare Ablehnung nicht autorisierter Sender. DMARC sollte man häufig mit p=none starten, Berichte auswerten und erst danach auf quarantine oder reject erhöhen.

Zusätzliche Informationen: Nicht jeder Sicherheitsmechanismus nutzt TXT. CAA ist ein eigener Record-Typ und legt fest, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. DNSSEC nutzt eigene Typen wie DNSKEY, DS und RRSIG. DNSSEC schützt Authentizität und Integrität von DNS-Antworten, aber nicht deren Vertraulichkeit. Typische DNSSEC-Probleme sind falsche DS-Einträge beim Registrar, abgelaufene Signaturen oder fehlerhafte Schlüsselwechsel.

SRV-Record (Service Locator)

Der SRV-Record veröffentlicht, welcher Host einen bestimmten Dienst über ein bestimmtes Protokoll bereitstellt. Die Struktur lautet _dienst._proto.name, gefolgt von Priorität, Gewicht, Port und Zielhost. Ein Beispiel ist _sip._tcp.example.com. 300 IN SRV 10 60 5060 sipserver.example.com.. Der Zielhost sollte ein Hostname sein, keine IP-Adresse, und anschließend per A oder AAAA auflösbar sein.

Funktionsweise: Die Priorität bestimmt, welche Servergruppe zuerst verwendet wird. Ein niedrigerer Wert hat höhere Priorität. Das Gewicht verteilt Last innerhalb derselben Priorität. Der Port erlaubt Diensten, ihren tatsächlichen Zielport zu veröffentlichen, ohne ihn im Client hart zu kodieren. Reale Einsatzfälle sind SIP, XMPP, Kerberos, LDAP und einige Spiele- oder Unternehmensdienste. Ob SRV genutzt wird, entscheidet aber die jeweilige Anwendung.

Wichtige Aspekte: SRV ersetzt keine normalen A- oder AAAA-Records. Der SRV-Record verweist auf einen Zielhost, und dieser Zielhost braucht anschließend eine Adressauflösung. Webbrowser nutzen SRV für gewöhnliche Websites nicht automatisch. Für moderne Webverbindungen existieren HTTPS- und SVCB-Records, die zusätzliche Serviceinformationen wie alternative Endpunkte oder Protokollhinweise veröffentlichen können. A und AAAA bleiben dennoch wichtig, weil nicht jeder Client und nicht jeder DNS-Anbieter HTTPS/SVCB vollständig unterstützt.

Zusätzliche Informationen: Bei SRV-Problemen prüft man zuerst den exakten Namen inklusive Unterstrichen, danach Priorität, Gewicht, Port und Zielhost. Ein häufiger Fehler ist die Verwechslung von Dienstname und Hostname. Ebenso kritisch sind falsche Protokolle: _sip._tcp und _sip._udp sind unterschiedliche Namen. Anwendungen, die SRV nicht auswerten, ignorieren den Record vollständig.

Praxisreferenz: wichtige Records, typische Fehler und Prüfungen

Zusammengefasst

DNS-Records sind essenziell für die Funktionsweise des Internets. A und AAAA verbinden Namen mit Servern, MX regelt Mailannahme, NS und SOA halten Delegation und Zonenbetrieb zusammen, CNAME vereinfacht Aliase, ALIAS löst providerabhängig Apex-Probleme, TXT trägt Verifikations- und Mailrichtlinien, SRV beschreibt spezialisierte Dienste, CAA begrenzt Zertifikatsaussteller und DNSSEC ergänzt Integritätsschutz. Die korrekte Konfiguration verbessert Verfügbarkeit, Sicherheit und Wartbarkeit, verlangt aber genaue Planung.

Eine zuverlässige Arbeitsweise folgt immer demselben Ablauf: Ist-Zustand erfassen, betroffene Record-Typen bestimmen, TTL planen, Änderung setzen, autoritative Nameserver prüfen, rekursive Resolver vergleichen, Anwendung testen und erst nach stabiler Funktion die TTL wieder erhöhen. Besonders kritisch sind Migrationen am Zonen-Apex, Mailumstellungen, DNSSEC-Rollovers und Zertifikatsrichtlinien. Wer DNS nicht isoliert, sondern als Zusammenspiel aus Records, Caches, Delegation und Anwendung betrachtet, reduziert Ausfälle und beschleunigt jede Fehlersuche.