DNS-Einträge erklärt: A, AAAA, CNAME, MX, TXT und weitere

Eine DNS-Zone ist eine Liste von Resource Records, auf Deutsch meist DNS-Einträge genannt. Jeder Eintrag besteht aus denselben fünf Teilen:

www.example.com.   3600   IN   A   192.0.2.10
└── name           └ TTL  └class └type └ data

Der Name ist das, wonach gefragt wird. Die TTL gibt an, wie viele Sekunden ein Resolver die Antwort zwischenspeichern darf (siehe Was ist die TTL im DNS?). Die Klasse lautet praktisch immer IN, und der Typ legt fest, wie die Daten zu lesen sind. Dieser Leitfaden geht die Record-Typen durch, denen Sie tatsächlich begegnen, samt der Regeln, die in der Praxis zu Ausfällen führen.

Die DNS-Record-Typen im Überblick

Typ	Zweck	Beispieldaten
`A`	IPv4-Adresse	`192.0.2.10`
`AAAA`	IPv6-Adresse	`2001:db8::10`
`CNAME`	Alias auf einen anderen Namen	`shop.hosting.example.`
`MX`	Mailserver der Domain	`10 mx1.mail.example.`
`TXT`	Freitext: SPF, DKIM, DMARC, Verifizierungen	`"v=spf1 -all"`
`NS`	für eine Zone zuständige Nameserver	`ns1.dns.example.`
`SOA`	Metadaten der Zone, einer pro Zone	Seriennummer, Timer
`PTR`	Rückwärtsauflösung: Adresse zu Name	`mail.example.com.`
`SRV`	Host und Port eines Dienstes	`10 5 5060 sip.example.com.`
`CAA`	welche CAs Zertifikate ausstellen dürfen	`0 issue "ca.example"`
`DS`, `DNSKEY`, `RRSIG`	DNSSEC	Schlüssel und Signaturen
`HTTPS`, `SVCB`	Dienstparameter für HTTPS	`1 . alpn="h2,h3"`

A und AAAA: Adressen

Ein A-Record ordnet einem Namen eine IPv4-Adresse zu, ein AAAA-Record eine IPv6-Adresse. Ein Name kann mehrere von beiden haben. Resolver liefern alle zurück, und der Client sucht sich einen aus. Das ergibt eine grobe Lastverteilung, aber kein Failover, auf das man sich verlassen könnte.

$ dig +short www.example.com A
192.0.2.10
$ dig +short www.example.com AAAA
2001:db8::10

Veröffentlichen Sie einen AAAA-Record nur, wenn der Server wirklich über IPv6 antwortet. Ein defekter IPv6-Pfad macht die Website für einen Teil der Nutzer langsam oder unerreichbar, während sie „bei Ihnen funktioniert“.

CNAME: Aliase und ihre zwei Regeln

Ein CNAME besagt: „Dieser Name ist ein Alias, frage stattdessen nach jenem anderen Namen.“ Der Resolver beginnt die Auflösung mit dem Ziel von vorn.

shop.example.com.   3600  IN  CNAME  stores.hosting.example.

Zwei Regeln ergeben sich aus den DNS-Standards, nicht aus den Vorlieben eines Anbieters:

Ein Name mit CNAME darf keine weiteren Einträge tragen. Kein MX, kein TXT, nichts (DNSSEC-Records ausgenommen).
Deshalb gibt es keinen CNAME am Zonen-Apex. example.com selbst muss SOA- und NS-Records tragen und kann daher kein CNAME sein.

Anbieter umgehen die zweite Regel mit „ALIAS“, „ANAME“ oder „CNAME-Flattening“: Der DNS-Anbieter löst das Ziel selbst auf und antwortet mit A/AAAA-Records. Das funktioniert, ist aber eine Funktion des Anbieters und kein Record-Typ. Einen Zonenexport zu einem Anbieter, der sie nicht kennt, übersteht sie nicht.

Weitere Ratschläge zum CNAME: Lassen Sie MX- oder NS-Records nicht auf einen CNAME zeigen, und vermeiden Sie lange Ketten. Jeder Sprung ist eine weitere Abfrage und eine weitere Stelle, an der etwas ausfallen kann.

MX: wohin die E-Mail geht

MX-Records benennen die Server, die E-Mails für die Domain annehmen, jeweils mit einer Präferenzzahl. Der niedrigere Wert wird zuerst versucht, gleiche Werte teilen sich die Last.

example.com.  3600  IN  MX  10 mx1.mail.example.
example.com.  3600  IN  MX  20 mx2.mail.example.

Das Ziel muss ein Hostname mit A/AAAA-Records sein: keine IP-Adresse und kein CNAME. Hat eine Domain überhaupt keinen MX, weichen Absender auf den A-Record der Domain aus, was selten gewollt ist. Eine Domain, die keine E-Mails empfängt, kann das mit einem Null-MX ausdrücklich erklären: 0 .

SPF, DKIM und DMARC bauen auf MX und TXT auf und sind ein eigenes Thema: siehe MX, SPF, DKIM und DMARC erklärt.

TXT: Text mit Konventionen

Ein TXT-Record enthält beliebige Zeichenketten. Seine eigentliche Bedeutung erhält er durch Konventionen, die darauf aufsetzen:

SPF an der Domain selbst: "v=spf1 include:_spf.mail.example -all". Genau ein SPF-Record pro Name, zwei sind ein permanenter Fehler.
DKIM unter selector._domainkey.example.com.
DMARC unter _dmarc.example.com.
Zeichenketten zur Inhaberbestätigung für Search Consoles, SaaS-Dienste und die Zertifikatsausstellung.

Eine einzelne Zeichenkette in einem TXT-Record ist auf 255 Byte begrenzt. Längere Werte, typischerweise DKIM-Schlüssel mit 2048 Bit, werden innerhalb eines Records auf mehrere Zeichenketten in Anführungszeichen verteilt, und der Empfänger fügt sie ohne Trennzeichen zusammen:

sel1._domainkey  IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
                          "...AQ8AMIIBCgKCAQEA" )

Die meisten Verwaltungsoberflächen erledigen das Aufteilen für Sie. Wenn Sie von Hand teilen, setzen Sie an der Nahtstelle kein Leerzeichen.

NS und SOA: das Gerüst der Zone

NS-Records führen die autoritativen Nameserver auf. Es gibt sie doppelt: in der übergeordneten Zone (die Delegation, die Sie beim Registrar ändern) und in Ihrer eigenen Zone. Beide Sätze sollten übereinstimmen. NS-Records an einer Subdomain delegieren diese Subdomain an andere Server.

Der SOA-Record ist der eine Eintrag am Kopf jeder Zone:

example.com. 3600 IN SOA ns1.dns.example. hostmaster.example.com. (
    2026092001 ; serial
    7200       ; refresh
    3600       ; retry
    1209600    ; expire
    300 )      ; negative-caching TTL

Die Seriennummer zeigt den sekundären Servern, dass sich die Zone geändert hat. Das letzte Feld wird am häufigsten übersehen: Es bestimmt, wie lange Resolver die Antwort „diesen Namen gibt es nicht“ zwischenspeichern. Darum kann ein Eintrag, den Sie eine Minute nach einer fremden Abfrage angelegt haben, noch eine Weile unsichtbar bleiben.

Ein Wechsel der NS-Records ist ein eigenes Projekt und braucht einen eigenen Plan.

PTR: Rückwärtsauflösung

Ein PTR-Record ordnet einer Adresse wieder einen Namen zu. Er liegt in einer besonderen Zone (in-addr.arpa für IPv4, ip6.arpa für IPv6), die derjenige verwaltet, dem der IP-Adressblock gehört, also normalerweise Ihr Hosting-Anbieter oder Internetprovider, nicht Sie in der Zone Ihrer Domain.

$ dig +short -x 192.0.2.25
mail.example.com.

Wichtig ist das vor allem für Mailserver. Mehr dazu im Glossar unter Reverse DNS.

SRV: Dienste mit Port

Mit SRV-Records findet ein Client den Host und den Port eines Dienstes, und zwar unter einem Namen der Form _service._proto.name:

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
;                                  prio weight port target

Genutzt wird das von SIP, XMPP, Matrix, einigen Microsoft-Diensten und anderen. Browser verwenden SRV für Websites nicht.

CAA: wer Zertifikate ausstellen darf

Ein CAA-Record führt die Zertifizierungsstellen auf, die für die Domain ausstellen dürfen. Jede öffentliche CA muss ihn vor der Ausstellung prüfen.

example.com.  IN  CAA  0 issue "ca.example"
example.com.  IN  CAA  0 issuewild ";"

Ohne CAA-Record darf jede CA ausstellen. Mehr dazu im Glossar unter CAA-Record.

DNSSEC-Records

DNSKEY enthält die öffentlichen Schlüssel der Zone, RRSIG die Signaturen über jeden Record-Satz, NSEC/NSEC3 beweisen, dass ein Name nicht existiert, und DS in der übergeordneten Zone bindet den Schlüssel der untergeordneten Zone in die Vertrauenskette ein. Ihr DNS-Anbieter erzeugt alle diese Records außer DS. Den reichen Sie (oder der Anbieter) über den Registrar ein.

HTTPS und SVCB

Über den HTTPS-Record (eine Sonderform von SVCB) erfährt ein Browser schon aus der DNS-Antwort, dass eine Website HTTP/2 oder HTTP/3 unterstützt und welche Adressen zu verwenden sind. Wahlweise nennt der Record auch ein Alias-Ziel, sogar am Apex. Große CDNs veröffentlichen ihn automatisch. Von Hand schreibt man ihn selten, aber in Abfragen werden Sie ihn sehen:

$ dig +short example.com HTTPS
1 . alpn="h2,h3"

Und was ist mit ANY?

dig example.com ANY lieferte früher alles, was ein Server hatte. Viele Server antworten inzwischen nur noch mit einer Minimalantwort, weil ANY für Amplification-Angriffe missbraucht wurde. Um die Einträge einer Zone zu sehen, fragen Sie jeden Typ ab, der Sie interessiert. Eine öffentliche Abfrage, die alle Namen einer Zone auflistet, gibt es nicht. Zonentransfers (AXFR) sind auf autorisierte sekundäre Server beschränkt.

Häufige Fehler

CNAME am Apex oder CNAME neben MX/TXT am selben Namen.
MX, der auf eine IP-Adresse oder einen CNAME zeigt.
Zwei SPF-TXT-Records an einem Namen.
Fehlender Punkt am Ende in einer Zonendatei, sodass aus mx1.mail.example ein mx1.mail.example.example.com. wird. Verwaltungsoberflächen erwarten den Punkt unterschiedlich. Prüfen Sie das Ergebnis mit dig.
Ein AAAA-Record für einen Server ohne funktionierendes IPv6.
Einen Eintrag für www anlegen und erwarten, dass die nackte Domain folgt, oder umgekehrt. Es sind verschiedene Namen.
Die Negative-Caching-TTL vergessen, wenn ein neuer Eintrag „nicht auftaucht“.

Mit OrbitProbe prüfen

Die DNS-Abfrage von OrbitProbe fragt für einen Namen A, AAAA, CNAME, MX, TXT, NS, SOA und CAA in einem Durchgang ab und zeigt die TTL jeder Antwort. So können Sie vergleichen, was veröffentlicht ist und was Sie beabsichtigt hatten. Führen Sie die Abfrage für die nackte Domain und für www getrennt aus: Es sind getrennte Namen mit getrennten Einträgen.