DNS Record-Typen — Vollständige Referenz

Der A Record ist der grundlegendste DNS-Record-Typ. Er ordnet einen Domainnamen einer IPv4-Adresse zu.

Aufbau

Hostname       TTL     Klasse  Typ   Wert
example.com.   3600    IN      A     93.184.216.34

Typische Anwendungsfälle

• Webserver: example.com → 93.184.216.34
• Subdomains: api.example.com → 10.0.1.50
• Loadbalancing: Mehrere A Records für dieselbe Domain (Round Robin DNS)

Beispiele

; Hauptdomain zeigt auf den Webserver
example.com.       3600  IN  A  93.184.216.34

; Subdomains für verschiedene Dienste
www.example.com.   3600  IN  A  93.184.216.34
api.example.com.   300   IN  A  10.0.1.50
mail.example.com.  3600  IN  A  10.0.1.100

; Round Robin Loadbalancing
cdn.example.com.   60    IN  A  203.0.113.10
cdn.example.com.   60    IN  A  203.0.113.11
cdn.example.com.   60    IN  A  203.0.113.12

Wichtige Hinweise

• A Records zeigen immer auf eine IPv4-Adresse (4 Byte, z.B. 192.168.1.1)
• Für IPv6 verwenden Sie stattdessen einen AAAA Record
• Am Domain-Apex (z.B. example.com ohne Subdomain) können Sie keinen CNAME verwenden — hier muss ein A Record stehen
• Mehrere A Records für denselben Hostnamen ermöglichen einfaches Loadbalancing

Diagnose

dig example.com A
nslookup example.com
host example.com

Der AAAA Record (gesprochen: "Quad-A") ist das IPv6-Pendant zum A Record. Er ordnet einen Domainnamen einer IPv6-Adresse zu.

Aufbau

Hostname       TTL     Klasse  Typ    Wert
example.com.   3600    IN      AAAA   2606:2800:220:1:248:1893:25c8:1946

Warum IPv6?

IPv4 hat nur ca. 4,3 Milliarden Adressen — die sind seit 2011 praktisch aufgebraucht. IPv6 bietet 340 Sextillionen (3,4 × 10³⁸) Adressen. In vielen Regionen (besonders Asien) ist IPv6 bereits die primäre Adressfamilie.

Best Practices

• Dual-Stack empfohlen: Setzen Sie sowohl A als auch AAAA Records für maximale Erreichbarkeit
• Testen Sie Ihre IPv6-Konnektivität: test-ipv6.com
• Viele CDNs und Cloud-Provider bieten automatisch IPv6-Support

Diagnose

dig example.com AAAA
dig +short example.com AAAA
host -t AAAA example.com

Ein CNAME Record erstellt einen Alias für einen anderen Domainnamen. Statt direkt auf eine IP zu zeigen, verweist er auf einen anderen DNS-Namen, der dann seinerseits aufgelöst wird.

Wie CNAME funktioniert

Wenn ein Client www.example.com auflöst:

1. DNS-Resolver findet den CNAME: www.example.com → example.com
2. Resolver löst nun example.com auf und findet A Record: 93.184.216.34
3. Client erhält die IP 93.184.216.34

Typische Anwendungsfälle

• www-Subdomain: www.example.com → example.com
• CDN-Integration: cdn.example.com → d1234.cloudfront.net
• SaaS-Dienste: shop.example.com → shops.myshopify.com

⚠️ Wichtige Einschränkungen

Regel	Erklärung
Kein CNAME am Apex	Der Domain-Apex (example.com) darf laut RFC 1034 KEINEN CNAME haben. Hier muss ein A/AAAA Record stehen. Einige Provider bieten "ALIAS" oder "ANAME" Records als Workaround.
Keine anderen Records	Wo ein CNAME existiert, dürfen keine anderen Record-Typen (A, MX, TXT etc.) für denselben Hostnamen existieren.
Keine Ketten	CNAME-Ketten (CNAME → CNAME → CNAME) sind zwar technisch möglich, aber stark abzuraten — sie verlangsamen die Auflösung und sind fehleranfällig.

Diagnose

dig www.example.com CNAME
dig +trace www.example.com

Der MX Record bestimmt, welche Mailserver für den E-Mail-Empfang einer Domain zuständig sind. Ohne korrekte MX Records kann Ihre Domain keine E-Mails empfangen.

Priorität (Preference)

Die Prioritätszahl bestimmt die Reihenfolge, in der Mailserver kontaktiert werden:

• Niedrigere Zahl = höhere Priorität
• Der Absende-Server versucht zuerst den Server mit der niedrigsten Prioritätszahl
• Ist dieser nicht erreichbar, wird der nächsthöhere versucht
• Gleiche Priorität → Round Robin (zufällige Auswahl)

Beispiel: Google Workspace

example.com.  3600  IN  MX  1   aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt4.aspmx.l.google.com.

Beispiel: Microsoft 365

example.com.  3600  IN  MX  0   example-com.mail.protection.outlook.com.

Wichtige Hinweise

• MX Records zeigen immer auf einen Hostnamen, niemals direkt auf eine IP-Adresse
• Der Ziel-Hostname darf kein CNAME sein (RFC 2181)
• Stellen Sie sicher, dass der Ziel-Host einen A/AAAA Record und einen korrekten PTR Record (Reverse DNS) hat
• Für E-Mail-Authentifizierung konfigurieren Sie zusätzlich SPF, DKIM und DMARC Records

Null-MX Record (RFC 7505)

Wenn Ihre Domain explizit KEINE E-Mails empfangen soll:

example.com.  3600  IN  MX  0  .

Dies signalisiert sendenden Mailservern, dass die Domain keinen Mailempfang unterstützt.

Diagnose

dig example.com MX
nslookup -type=mx example.com

Der TXT Record ist ein vielseitiger Record-Typ, der beliebigen Text speichern kann. Ursprünglich für menschenlesbare Notizen gedacht, ist er heute der wichtigste Record für E-Mail-Sicherheit, Domain-Verifizierung und diverse andere Anwendungen.

Wichtige Anwendungen

1. SPF (Sender Policy Framework)

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Definiert, welche Server E-Mails im Namen Ihrer Domain senden dürfen.

2. DKIM (DomainKeys Identified Mail)

google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Enthält den öffentlichen Schlüssel zur Verifizierung von E-Mail-Signaturen.

3. DMARC (Domain-based Message Authentication)

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Definiert die DMARC-Richtlinie für Ihre Domain.

4. Domain-Verifizierung

; Google Search Console
example.com.  3600  IN  TXT  "google-site-verification=abc123..."

; Microsoft 365
example.com.  3600  IN  TXT  "MS=ms12345678"

Technische Grenzen

• Max. 255 Zeichen pro String: Längere Werte müssen in mehrere Strings aufgeteilt werden: "Teil1" "Teil2"
• Mehrere TXT Records möglich: Pro Hostname können mehrere TXT Records existieren

Diagnose

dig example.com TXT
dig _dmarc.example.com TXT

Der SOA Record definiert grundlegende Verwaltungsinformationen über eine DNS-Zone. Jede DNS-Zone hat genau einen SOA Record. Er ist der erste Record in jeder Zonendatei.

Aufbau

example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
    2025022701 ; Serial Number (YYYYMMDDNN)
    3600       ; Refresh (1 Stunde)
    900        ; Retry (15 Minuten)
    1209600    ; Expire (14 Tage)
    86400      ; Minimum TTL / Negative Caching TTL (24 Stunden)
)

Felder im Detail

Feld	Beschreibung	Empfehlung
MNAME	Primärer Nameserver der Zone	ns1.example.com.
RNAME	E-Mail des Zone-Administrators (@ wird durch . ersetzt)	admin.example.com. = admin@example.com
Serial	Versionsnummer — muss bei jeder Änderung erhöht werden	Format YYYYMMDDNN
Refresh	Intervall, in dem Sekundärserver den Primärserver auf Änderungen prüfen	3600–7200 (1–2 Stunden)
Retry	Wartezeit bei fehlgeschlagenem Refresh	900–3600
Expire	Nach dieser Zeit verwerfen Sekundärserver die Zone, wenn kein Refresh möglich war	604800–1209600 (7–14 Tage)
Minimum TTL	Wie lange negative Antworten (NXDOMAIN) gecacht werden	3600–86400

Diagnose

dig example.com SOA
dig +short example.com SOA

Der PTR Record ist das Gegenteil eines A Records: Er ordnet eine IP-Adresse einem Hostnamen zu. Dies nennt man Reverse DNS (rDNS). PTR Records sind essenziell für die E-Mail-Zustellbarkeit.

Warum Reverse DNS für E-Mail essenziell ist

Die meisten Mailserver führen beim Empfang einer E-Mail einen Forward Confirmed Reverse DNS (FCrDNS) Check durch:

1. IP-Adresse des Absenders → PTR Lookup → ergibt Hostname
2. Hostname → A Record Lookup → ergibt IP-Adresse
3. Prüfung: Stimmt die aufgelöste IP mit der ursprünglichen IP überein?

Wenn diese Prüfung fehlschlägt, wird die E-Mail oft als Spam markiert oder abgelehnt. Große Provider wie Google, Microsoft und Yahoo lehnen E-Mails ohne korrekten PTR ab.

Wer setzt PTR Records?

PTR Records werden nicht in Ihrer normalen DNS-Zone gesetzt, sondern beim Inhaber des IP-Adressblocks — in der Regel Ihr Hosting-Provider oder ISP.

Best Practices für E-Mail

• Der PTR sollte auf den HELO/EHLO-Hostnamen Ihres Mailservers zeigen
• Forward und Reverse müssen übereinstimmen (FCrDNS)
• Verwenden Sie aussagekräftige Hostnamen (nicht ip-93-184-216-34.example.com)

Diagnose

dig -x 93.184.216.34
nslookup 93.184.216.34
host 93.184.216.34

Der NS Record gibt an, welche DNS-Server für eine Domain autoritativ sind — also die offizielle DNS-Informationsquelle für diese Domain darstellen.

Best Practices

• Mindestens 2 NS Server — für Redundanz (RFC empfiehlt mindestens 2, typisch sind 2–4)
• Geografisch verteilt — verschiedene Netzwerke/Standorte für Ausfallsicherheit
• Verschiedene Netze — nicht alle NS im selben /24-Subnetz
• Hohe TTL — 86400 (24h) oder höher, da NS-Änderungen selten sind

Glue Records

Wenn Ihre Nameserver in der eigenen Domain liegen (z.B. ns1.example.com für example.com), entsteht ein Henne-Ei-Problem. Glue Records lösen das — sie sind A Records, die direkt in der Parent Zone hinterlegt sind.

Diagnose

dig example.com NS
dig +trace example.com NS
whois example.com | grep -i "name server"

Der SRV Record ermöglicht es, den Standort (Hostname und Port) eines bestimmten Dienstes zu definieren. Er wird u.a. für VoIP (SIP), Messaging (XMPP), Verzeichnisdienste (LDAP) und Microsoft-Dienste verwendet.

Aufbau

_service._proto.name.  TTL  IN  SRV  Priorität  Gewicht  Port  Zielhost
_sip._tcp.example.com.    3600  IN  SRV  10  60  5060  sipserver.example.com.

Felder

Feld	Beschreibung
_service	Name des Dienstes (z.B. _sip, _xmpp-client, _ldap)
_proto	Transportprotokoll (_tcp oder _udp)
Priorität	Wie bei MX: niedrigerer Wert = bevorzugt
Gewicht	Lastverteilung bei gleicher Priorität (höherer Wert = mehr Traffic)
Port	TCP/UDP-Port des Dienstes
Zielhost	Hostname des Servers (muss A/AAAA Record haben)

Diagnose

dig _sip._tcp.example.com SRV
dig _sipfederationtls._tcp.example.com SRV

Der CAA Record definiert, welche Zertifizierungsstellen (CAs) SSL/TLS-Zertifikate für Ihre Domain ausstellen dürfen. Seit September 2017 müssen alle CAs CAA Records prüfen, bevor sie ein Zertifikat ausstellen.

Tags

Tag	Beschreibung
issue	Welche CA darf Zertifikate für diese Domain ausstellen
issuewild	Welche CA darf Wildcard-Zertifikate (*.example.com) ausstellen
iodef	E-Mail oder URL für Benachrichtigungen bei Policy-Verstößen

Beispiele

; Nur Let's Encrypt darf Zertifikate ausstellen
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"
example.com.  3600  IN  CAA  0  issuewild  ";"  ; Keine Wildcard-Zertifikate

; Mit Benachrichtigung
example.com.  3600  IN  CAA  0  iodef  "mailto:security@example.com"

Diagnose

dig example.com CAA

DS & DNSKEY Records (DNSSEC)

DS (Delegation Signer) und DNSKEY Records bilden die Grundlage von DNSSEC — dem System zur kryptographischen Absicherung von DNS-Antworten. Siehe den eigenen DNSSEC-Artikel für Details.

HTTPS / SVCB Record (RFC 9460, 2023)

Neuer Record-Typ für moderne HTTP-Dienste. Ermöglicht das Mitteilen von ALPN-Protokollen, ECH-Schlüsseln, und alternativen Endpoints in einem einzigen DNS-Lookup.

example.com.  IN  HTTPS  1  .  alpn="h3,h2" ech="MIGf..."

Vorteile: Schnellerer Verbindungsaufbau, weniger Round-Trips, Encrypted Client Hello (ECH) Support.

TLSA Record (DANE)

Ermöglicht die Zertifikatvalidierung über DNS. Alternative zu oder Ergänzung von CAs.

_443._tcp.example.com.  IN  TLSA  3  1  1  2b4c342f...

Record-Typ Übersicht

Typ	RFC	Zweck	Häufigkeit
A	1035	IPv4-Adresse	⭐⭐⭐⭐⭐
AAAA	3596	IPv6-Adresse	⭐⭐⭐⭐
CNAME	1034	Alias	⭐⭐⭐⭐⭐
MX	1035	Mailserver	⭐⭐⭐⭐⭐
NS	1035	Nameserver	⭐⭐⭐⭐⭐
TXT	1035	Text / Verifizierung	⭐⭐⭐⭐⭐
SOA	1035	Zone-Verwaltung	⭐⭐⭐⭐⭐
PTR	1035	Reverse DNS	⭐⭐⭐⭐
SRV	2782	Dienst-Standort	⭐⭐⭐
CAA	8659	Zertifikat-Autorisierung	⭐⭐⭐
DS/DNSKEY	4034	DNSSEC	⭐⭐⭐
HTTPS	9460	HTTP Service Binding	⭐⭐ (steigend)