DNS-Record-Typen erklärt: A, CNAME, MX, TXT, NS, SOA, SRV

Vollständige Referenz der DNS-Record-Typen. Was jeder tut, wann er genutzt wird, mit praxisnahen Beispielen für A, AAAA, CNAME, MX, TXT, NS und mehr.

Ein DNS-Record ist eine Anweisung, die DNS-Resolvern sagt, wie sie Anfragen für Ihre Domain verarbeiten sollen. Es gibt etwa ein Dutzend Standardtypen, aber sechs decken 95% der alltäglichen Anwendungsfälle ab: A, AAAA, CNAME, MX, TXT und NS. Die anderen (SOA, SRV, CAA, PTR) haben spezifische, seltenere Einsatzbereiche. Records werden entweder im DNS-Interface Ihres Registrars oder bei einem spezialisierten DNS-Provider wie Cloudflare, AWS Route 53 oder OVH konfiguriert.

Schnellreferenz-Tabelle

Typ	Was er tut	Typischer Einsatz	Konfiguriert wo
A	Verbindet Domain mit IPv4-Adresse	IP Ihres Webservers	DNS-Provider
AAAA	Verbindet Domain mit IPv6-Adresse	IPv6-fähige Server	DNS-Provider
CNAME	Aliasiert einen Domainnamen zu einem anderen	www-Subdomain, SaaS-Subdomains	DNS-Provider
MX	Leitet E-Mails der Domain weiter	Google Workspace, Microsoft 365	DNS-Provider
TXT	Speichert Textdaten	SPF, DKIM, DMARC, Domain-Verifizierung	DNS-Provider
NS	Listet autoritative Nameserver	DNS-Delegation	Registrar
SOA	Zonen-Metadaten und Seriennummer	DNS-Zonenverwaltung	Auto (DNS-Provider)
SRV	Lokalisiert einen bestimmten Dienst	VoIP, Microsoft Teams, Gaming	DNS-Provider
CAA	Schränkt Zertifikatsausstellung ein	SSL/TLS-Sicherheit	DNS-Provider

Record A: IPv4-Adresse

A-Records sind der grundlegendste DNS-Record-Typ. Sie verbinden einen Domainnamen mit einer IPv4-Adresse, das ist, wie ein Browser example.com in einen erreichbaren Server übersetzt.

example.com.    3600    IN    A    93.184.216.34

In Cloudflares Interface: Name = @, Typ = A, Inhalt = 93.184.216.34, TTL = Auto.

Eine Domain kann mehrere A-Records haben, das ermöglicht Round-Robin-Lastverteilung, bei der DNS-Resolver die IP-Adressen bei jeder Anfrage rotieren. Wenn sich die IP-Adresse Ihres Servers ändert, reicht es, den A-Record zu aktualisieren. Typischerweise gibt es einen A-Record für example.com und einen für www.example.com (oder einen CNAME, der www auf @ zeigt).

Record AAAA: IPv6-Adresse

Identisch mit dem A-Record, aber für IPv6-Adressen. Die IPv6-Verbreitung ist erheblich, etwa 40% des globalen Internetverkehrs 2024 nutzt IPv6. Wenn Ihr Hosting-Provider eine IPv6-Adresse bereitstellt, lohnt sich ein AAAA-Record.

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

Nicht zwingend erforderlich, aber wenn Ihr Provider IPv6 unterstützt (Cloudflare, AWS, GCP tun das alle), verbessert ein AAAA-Record parallel zum A-Record die Konnektivität für IPv6-Nutzer ohne Nachteile.

Record CNAME: Domain-Alias

Ein CNAME macht einen Domainnamen zum Alias eines anderen. Er zeigt nicht auf eine IP-Adresse, er zeigt auf einen anderen Domainnamen, und der Resolver schlägt dann den A-Record dieses Domainnamens für die tatsächliche IP nach.

www.example.com.    3600    IN    CNAME    example.com.

Zwei wichtige Regeln. Erstens: Ein CNAME kann im Standard-DNS nicht auf der Domain-Apex-Ebene (example.com selbst) verwendet werden (CNAMEs sind nur für Subdomains möglich. Cloudflare löst das mit "CNAME Flattening", das einen Apex-CNAME transparent funktionieren lässt. Zweitens: Ein CNAME kann nicht mit anderen Record-Typen für denselben Namen koexistieren) Sie können keinen CNAME und einen MX gleichzeitig auf www.example.com haben.

Praktische Einsatzbereiche: www zeigt auf die Root-Domain, blog.example.com auf example.ghost.io, shop.example.com auf example.myshopify.com. CNAME ist nützlich, wenn sich die IP-Adresse des Ziels ändert. Sie aktualisieren nur einen Record an der Quelle, und alle CNAMEs, die darauf zeigen, folgen automatisch.

Record MX: E-Mail-Routing

MX-Records teilen anderen Mailservern mit, wohin E-Mails für Ihre Domain gesendet werden sollen. Ohne gültige MX-Records werden E-Mails an sie@example.com abgewiesen.

example.com.    3600    IN    MX    10    aspmx.l.google.com.

Die Zahl (hier 10) ist die Priorität. Niedrigere Prioritätszahlen haben Vorrang. Sie können mehrere MX-Records mit verschiedenen Prioritäten für Backup-Mailserver haben, ist der primäre (niedrigste Prioritätszahl) nicht erreichbar, versuchen Sender den nächsten.

Google Workspace konfiguriert fünf MX-Records mit Prioritäten 1, 5, 5, 10 und 10. Microsoft 365 verwendet einen einzelnen MX-Record, der auf ihredomain-com.mail.protection.outlook.com mit Priorität 0 zeigt.

Der häufigste Fehler mit MX-Records: Sie beim Nameserver-Wechsel nicht neu anzulegen. Ihre E-Mails hören stillschweigend auf zu funktionieren, keine offensichtlichen Fehlermeldungen auf Ihrer Seite, Sender erhalten einfach Bounces.

Record TXT: Verifizierung und Authentifizierung

TXT-Records speichern beliebige Textdaten. Sie sind der vielseitigste DNS-Record-Typ, genutzt für eine breite Palette von Zwecken, die funktional nichts miteinander zu tun haben.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

Die wichtigsten Einsatzbereiche:

SPF: gibt an, welche Mailserver berechtigt sind, E-Mails im Namen Ihrer Domain zu senden. Verhindert Spoofing.
DKIM: speichert einen öffentlichen Schlüssel zur kryptografischen Verifizierung, dass ausgehende E-Mails wirklich von Ihnen stammen und nicht verändert wurden.
DMARC: definiert, was mit E-Mails passiert, die SPF- oder DKIM-Prüfungen nicht bestehen (ablehnen, in Quarantäne oder überwachen).
Domain-Eigentumsverifizierung: Google Search Console, AWS Certificate Manager, Facebook und viele SaaS-Dienste verlangen einen TXT-Record als Beweis, dass Sie die Domain kontrollieren. Der Record enthält ein eindeutiges Token, das sie Ihnen geben.
Site-Verifizierung: gleiches Prinzip für HubSpot, Atlassian und andere.

Eine Domain kann mehrere TXT-Records gleichzeitig haben, das ist erwartet und normal. Ihr SPF-Record, DKIM-Records (einer pro Sendedienst), DMARC-Record und verschiedene Verifizierungs-Tokens koexistieren alle als separate TXT-Records auf derselben Domain.

Record NS: Nameserver

NS-Records identifizieren, welche Nameserver für Ihre Domain autoritativ sind, das sind die Server, die wissen, wo alle Ihre anderen DNS-Records zu finden sind.

example.com.    86400    IN    NS    ns1.cloudflare.com.

Typischerweise haben Sie 2 bis 4 NS-Records für Redundanz. Sie werden von Ihrem DNS-Provider festgelegt und beim Registrar konfiguriert (nicht in der DNS-Zone selbst, obwohl sie dort sichtbar sind). Der TTL auf NS-Records ist bewusst hoch (86400 = 24 Stunden), weil diese Records selten wechseln.

Sie bearbeiten NS-Records fast nie direkt in Ihrem DNS-Manager. Sie ändern sie auf Registrar-Ebene beim Wechsel zu einem neuen DNS-Provider. Für die Vorgehensweise lesen Sie Nameserver ändern.

Record SOA: Start of Authority

Jede DNS-Zone hat genau einen SOA-Record. Er enthält administrative Metadaten über die Zone: den primären Nameserver, die Kontakt-E-Mail des Domain-Administrators, eine Seriennummer (nach jeder Änderung inkrementiert) und Timing-Parameter für die Zonensynchronisierung zwischen primären und sekundären DNS-Servern.

example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. 2024010101 7200 3600 1209600 300

Sie konfigurieren diesen Record fast nie manuell, Ihr DNS-Provider verwaltet ihn automatisch. Sie schauen ihn sich bei der Diagnose komplexer DNS-Probleme an oder um zu verifizieren, dass eine Zonenänderung korrekt angewendet wurde (Seriennummer-Inkrement prüfen).

Record SRV: Service-Lokator

SRV-Records geben an, wo ein bestimmter Dienst auf Ihrer Domain läuft, sie kombinieren Protokoll, Port und Host-Informationen.

_sip._tcp.example.com.    3600    IN    SRV    10    5    5060    sip.example.com.

Das Format: _dienst._protokoll.domain TTL IN SRV priorität gewicht port ziel. Priorität und Gewicht sind Lastverteilungs-Steuerungen.

Reale Einsatzbereiche: Microsoft Teams benötigt SRV-Records für die Service-Erkennung in hybriden Deployments, Minecraft-Server-Hosting nutzt SRV-Records damit Spieler sich mit play.example.com statt einer rohen IP:Port verbinden, und VoIP-Provider die SIP verwenden benötigen SRV-Records für das Anruf-Routing.

Sie konfigurieren einen SRV-Record nur, wenn ein spezifischer Service-Provider ihn anfordert, er gibt Ihnen die genauen Werte.

Record CAA: Certification Authority Authorization

CAA-Records geben an, welche Zertifizierungsstellen SSL/TLS-Zertifikate für Ihre Domain ausstellen dürfen. Jede nicht gelistete CA ist gesperrt.

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

Wenn Sie nur Let's Encrypt verwenden, blockiert ein CAA-Record mit letsencrypt.org DigiCert, Sectigo und jede andere CA daran, Zertifikate für Ihre Domain auszustellen, selbst wenn sie durch Social Engineering oder einen Breach kompromittiert werden. Einen CAA-Record hinzuzufügen ist eine direkte Sicherheitsverbesserung für jede Produktions-Domain.

Der Tag issue erlaubt die Ausstellung normaler Zertifikate. issuewild erlaubt Wildcard-Zertifikate. iodef gibt an, wohin Verstoßberichte gesendet werden sollen (E-Mail-Adresse oder URL).

Eigene Records prüfen

Alle DNS-Records für Ihre Domain in einem Befehl abrufen:

dig ANY example.com

Hinweis: Manche Resolver schränken Antworten auf ANY-Anfragen ein. Zuverlässiger ist die Abfrage spezifischer Typen:

dig A example.com
dig MX example.com
dig TXT example.com

Domain Sentinel bietet ein DNS-Lookup-Tool, das mehrere Record-Typen gleichzeitig abfragt und sie lesbar darstellt, nützlich, wenn Sie Ihre Konfiguration prüfen möchten, ohne Kommandozeilen-Ausgaben zu analysieren. Prüfen Sie die Records Ihrer Domain jederzeit, um zu bestätigen, dass Änderungen wirksam wurden.