🖧 Vollständiger, erschöpfender Leitfaden zu DNS-Einträgen: Von den Grundlagen bis zu DNSSEC und Automatisierung

DNS (Domain Name System) ist das fundamentale System, auf dem das gesamte moderne Internet basiert. Es ist nicht nur ein „Telefonbuch“, sondern eine komplexe, verteilte Datenbank, die menschenlesbare Namen (z. B. google.com) in technische Kennungen wie IP-Adressen, Mailserver, Sicherheitsrichtlinien und sogar geografische Koordinaten übersetzt. Eine falsche DNS-Konfiguration ist eine der häufigsten Ursachen für Website-Ausfälle, E-Mail-Zustellprobleme und Sicherheitslücken.

Dieser Leitfaden vereint alle Aspekte von DNS: von den grundlegenden Einträgen, die täglich verwendet werden, bis hin zu komplexen Mechanismen wie DNSSEC und DANE. Wir werden jeden Eintragstyp, seine Funktion, Syntax, praktische Beispiele, häufige Fehler, Diagnosebefehle und vorgefertigte Vorlagen zur Bereitstellung untersuchen. Die Informationen sind so strukturiert, dass Sie dieses Material als Lehrbuch, Administratorreferenz und Checkliste für Produktionsumgebungen verwenden können.

1. Terminologie

Bevor wir uns mit den Eintragstypen befassen, ist es entscheidend, die wichtigsten Begriffe zu verstehen, die im DNS verwendet werden. Dies schafft eine gemeinsame sprachliche Basis und hilft, Verwirrung zu vermeiden.

DNS (Domain Name System): Das Domain Name System. Eine globale verteilte Datenbank, die Domainnamen in IP-Adressen und andere verwandte Informationen übersetzt.
Domainname (Domain Name): Eine für Menschen lesbare Adresse im Internet, z. B. example.com. Besteht aus durch Punkte getrennten Labels.
FQDN (Fully Qualified Domain Name): Ein vollständiger Domainname, der einen Knoten in der DNS-Hierarchie eindeutig identifiziert. Endet immer mit einem Punkt, der die DNS-Wurzel bezeichnet (z. B. www.example.com.).
Zone: Eine administrative Einheit im DNS. Ein Teil des Namensraums, der von einem autoritativen Server (oder einer Gruppe von Servern) verwaltet wird. Entspricht normalerweise einer Domain oder Subdomain.
Zonendatei (Zone File): Eine Textdatei, die auf einem DNS-Server gespeichert ist und alle Einträge für eine bestimmte Zone enthält. Verwendet die Syntax, die im BIND-Standard definiert ist.
Eintrag (Resource Record, RR): Die grundlegende Dateneinheit im DNS. Jeder Eintrag hat einen Typ, einen Namen, einen Wert und eine TTL.
Eintragstyp (Record Type): Definiert, welche Informationen der Eintrag enthält (z. B. A, MX, TXT). Jeder Typ entspricht einem eindeutigen numerischen Code (z. B. 1 für A, 15 für MX).
TTL (Time To Live): Die Lebensdauer des Eintrags, angegeben in Sekunden. Bestimmt, wie lange Resolver und andere DNS-Server den Eintrag zwischenspeichern dürfen, bevor sie ihn erneut vom autoritativen Server anfordern.
Resolver: Ein DNS-Client oder -Server, der eine Anfrage von einer Anwendung (z. B. einem Browser) erhält und die erforderlichen Abfragen durchführt, um eine Antwort zu erhalten. Kann rekursiv (führt die vollständige Abfragekette aus) oder nicht-rekursiv sein.
Autoritativer Server (Authoritative Server): Ein DNS-Server, der die ursprünglichen Einträge für eine bestimmte Zone speichert und dafür verantwortlich ist. Beantwortet Abfragen mit Daten aus der Zonendatei.
Rekursiver Server (Recursive Server): Ein Server, der eine Anfrage von einem Client erhält und, wenn er die Antwort nicht im Cache hat, eine Abfragekette ausführt, beginnend mit den Root-Servern, um den autoritativen Server zu finden und die Antwort zu erhalten.
Root-Server (Root Server): Einer der 13 Servergruppen (bezeichnet mit den Buchstaben von a.root-servers.net. bis m.root-servers.net.), die der Ausgangspunkt für die Auflösung jedes Domainnamens sind. Sie wissen, wo sich die Server für Top-Level-Domains (TLD) befinden.
TLD (Top-Level Domain): Eine Top-Level-Domain. Der letzte Teil eines Domainnamens (z. B. .com, .org, .ru, .io).
Registrar: Das Unternehmen, über das Domainnamen registriert werden. Verwaltet die Delegationsinformationen (welche NS-Server die Domain bedienen) in der übergeordneten Zone (z. B. in der .com-Zone für die Domain example.com).
Registrant: Der Eigentümer des Domainnamens.
Delegierung (Delegation): Der Prozess der Übertragung der Kontrolle über eine Subdomain (oder Domain) von der übergeordneten Zone an die untergeordnete. Wird mithilfe von NS-Einträgen in der übergeordneten Zone erreicht.
Glue Record (Klebe-Eintrag): Ein A– oder AAAA-Eintrag, der beim Registrar für einen Nameserver veröffentlicht wird, dessen Domainname innerhalb der delegierten Zone liegt. Notwendig, um eine zyklische Abhängigkeit zu durchbrechen.
SOA (Start of Authority): Ein Eintrag, der administrative Informationen über die Zone enthält, einschließlich des primären Servers, des Administrator-Kontakts und der Parameter, die die Zonenübertragung an sekundäre Server steuern.
Seriennummer (Serial Number): Ein Feld im SOA-Eintrag, das die Version der Zone angibt. Sekundäre Server verwenden es, um festzustellen, ob ein Update erforderlich ist.
Vorwärtsauflösung (Forward Resolution): Der Prozess der Umwandlung eines Domainnamens in eine IP-Adresse (z. B. example.com → 192.0.2.1).
Rückwärtsauflösung (Reverse Resolution): Der Prozess der Umwandlung einer IP-Adresse in einen Domainnamen (z. B. 192.0.2.1 → example.com). Wird über die Zonen in-addr.arpa (für IPv4) und ip6.arpa (für IPv6) verwaltet.
Cache: Ein temporärer Speicher für DNS-Einträge auf einem Resolver oder DNS-Server, um nachfolgende Anfragen zu beschleunigen.
Caching: Der Prozess des Speicherns von DNS-Einträgen im Cache.
Negatives Caching (Negative Caching): Caching von Informationen, dass der angeforderte Eintrag nicht existiert.
RFC (Request for Comments): Ein offizielles Dokument, das Standards, Protokolle und Verfahren im Internet beschreibt. Alle wichtigen Aspekte von DNS sind in einer Reihe von RFCs beschrieben.
BIND (Berkeley Internet Name Domain): Die am weitesten verbreitete Implementierung eines DNS-Servers. Die Syntax seiner Zonendateien ist zum De-facto-Standard geworden.
MTA (Mail Transfer Agent): Ein Mailserver, der für die Übertragung von E-Mails verantwortlich ist (z. B. Postfix, Exim, Sendmail).
FCrDNS (Forward-Confirmed Reverse DNS): Ein Verifizierungsmechanismus, bei dem eine IP-Adresse einen PTR-Eintrag hat, der in einen Domainnamen aufgelöst wird, und dieser Domainname wiederum einen A-Eintrag hat, der auf die ursprüngliche IP-Adresse verweist. Kritisch für die Reputation von Mailservern.
DNSSEC (Domain Name System Security Extensions): Eine Reihe von Erweiterungen, die DNS-Einträgen kryptografische Signaturen hinzufügen, um ihre Authentizität und Integrität zu gewährleisten.
DANE (DNS-based Authentication of Named Entities): Ein Standard, der es ermöglicht, TLS-Zertifikate über TLSA-Einträge an DNS-Namen zu binden. Erfordert die Aktivierung von DNSSEC.
CAA (Certification Authority Authorization): Ein Mechanismus, der es dem Domaininhaber ermöglicht, festzulegen, welche Zertifizierungsstellen (CA) Zertifikate für ihn ausstellen dürfen.
SPF (Sender Policy Framework): Ein Mechanismus, der es dem Domaininhaber ermöglicht, festzulegen, welche Server berechtigt sind, E-Mails in seinem Namen zu versenden.
DKIM (DomainKeys Identified Mail): Ein Mechanismus, der es ermöglicht, ausgehende E-Mails mit einer digitalen Signatur zu versehen, die der Empfänger mit einem im DNS veröffentlichten öffentlichen Schlüssel verifizieren kann.
DMARC (Domain-based Message Authentication, Reporting & Conformance): Eine Richtlinie, die definiert, wie Mailservers E-Mails behandeln sollen, die die SPF- oder DKIM-Überprüfungen nicht bestehen, und die das Senden von Berichten an den Domaininhaber konfiguriert.
ALIAS / ANAME: Nicht standardmäßige Eintragstypen, die von einigen DNS-Anbietern angeboten werden. Ermöglichen das Erstellen von Aliasen für die Root-Domain (Apex), was mit einem Standard-CNAME unmöglich ist.
CNAME Flattening: Eine Technologie, die von einigen DNS-Anbietern verwendet wird. Wenn ein CNAME für eine Apex-Domain abgefragt wird, löst der Server die CNAME-Kette automatisch auf und gibt die endgültigen A/AAAA-Einträge an den Client zurück, um RFC-Verletzungen zu vermeiden.

2. Detaillierte Aufschlüsselung aller Eintragstypen

Alle Beispiele sind im BIND-Stil-Zonendateiformat angegeben. Namen, die mit einem Punkt enden (z. B. example.com.), sind FQDNs. Die TTL (Time To Live) wird in Sekunden angegeben und bestimmt, wie lange der Eintrag von Resolvern zwischengespeichert werden kann.

A — Adress-Eintrag (IPv4)

Zweck: Verknüpft einen Domainnamen mit einer 32-Bit-IPv4-Adresse. Der grundlegendste und am häufigsten verwendete Eintrag.
Format: name TTL IN A IPv4-Adresse
Beispiel:
example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
Wann verwendet: Um die IP-Adresse eines Webservers, einer API, eines Spielservers oder eines anderen Dienstes anzugeben, der über IPv4 erreichbar ist.
Überprüfung: dig +short example.com A
Best Practices:
- Die Verwendung eines A-Eintrags für die Root-Domain (Apex, @) ist eine standardmäßige und korrekte Praxis.
- Wählen Sie die TTL basierend auf der Stabilität der IP-Adresse. Für stabile Adressen — 3600 (1 Stunde) oder 86400 (1 Tag). Vor einer Migration — auf 300 (5 Minuten) reduzieren.

AAAA — IPv6-Adress-Eintrag

Zweck: Analog zum A-Eintrag, aber für 128-Bit-IPv6-Adressen. Kritisch wichtig für die Zukunft des Internets.
Format: name TTL IN AAAA IPv6-Adresse
Beispiel:
example.com. 3600 IN AAAA 2001:db8::1
Wann verwendet: Um die Verfügbarkeit eines Dienstes über das IPv6-Protokoll sicherzustellen.
Überprüfung: dig +short example.com AAAA

CNAME — Kanonischer Name

Zweck: Erstellt einen Alias für einen Domainnamen. Jede Anfrage an einen CNAME wird automatisch in eine Anfrage an seinen Zielnamen (kanonisch) umgewandelt.
Format: name TTL IN CNAME Ziel.
Beispiel:
www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
Wichtige Einschränkungen:
- Eintragskonflikt: Sie können nicht gleichzeitig einen CNAME und einen anderen Eintrag (A, MX, TXT usw.) für denselben Namen haben. Dies verstößt gegen die RFC.
- Apex-Domain: Der RFC-Standard verbietet die Verwendung von CNAME für die Root-Domain (z. B. example.com.), da sie bereits NS– und SOA-Einträge enthält. Um dies zu lösen, bieten DNS-Anbieter (Cloudflare, AWS Route 53) nicht standardmäßige Erweiterungen an: ALIAS oder ANAME, die den Alias dynamisch in A/AAAA-Einträge auflösen.
Praktische Anwendung: Verbindung mit einem CDN (machen Sie www zu einem CNAME auf die CDN-Adresse), Verwendung von SaaS-Plattformen (Blog, Shop).
Überprüfung: dig +short www.example.com CNAME

MX — Mail Exchange-Eintrag

Zweck: Gibt die Server an, die eingehende E-Mails für die Domain entgegennehmen. Der Eintrag enthält eine Priorität: Je kleiner die Zahl, desto höher die Priorität.
Format: name TTL IN MX Priorität Mailserver.
Beispiel:example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
- E-Mails werden zuerst an mail1.example.com. gesendet. Wenn er nicht verfügbar ist, versucht der MTA (Mail Transfer Agent) mail2.example.com..
Wichtige Anforderungen:
- Der Mailserver (mail1.example.com.) muss seinen eigenen A– oder AAAA-Eintrag haben.
- Ein PTR-Eintrag muss für die IP-Adresse des Mailservers konfiguriert sein und mit dem im MX angegebenen Servernamen übereinstimmen. Dies ist entscheidend für die Serverreputation und die E-Mail-Zustellung.
Überprüfung: dig +short example.com MX

TXT — Text-Eintrag

Zweck: Speichert beliebige Textdaten. Häufig verwendet für E-Mail-Sicherheitsrichtlinien (SPF, DKIM, DMARC), Domain-Eigentumsverifizierung (Google, Microsoft, Yandex) und andere Zwecke.
Format: name TTL IN TXT "Text"
Beispiele:
- SPF (Sender Policy Framework): Definiert, welche Server berechtigt sind, E-Mails im Namen der Domain zu versenden. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
  - ip4:192.0.2.0/24 — erlaubt das gesamte Subnetz.
  - include:_spf.google.com — beinhaltet Regeln aus der Google-Zone (für Gmail).
  - ~all — „weicher“ Fehler für alle anderen (softfail). -all — strenger Fehler (fail).
- DKIM (DomainKeys Identified Mail): Veröffentlicht den öffentlichen Schlüssel zur Überprüfung der digitalen Signatur, die zu ausgehenden E-Mails hinzugefügt wird. Normalerweise für eine Subdomain wie selector._domainkey.domain erstellt. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
  - v=DKIM1 — Version.
  - k=rsa — Schlüsseltyp.
  - p=... — der öffentliche Schlüssel selbst im Base64-Format.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Legt die Richtlinie für die Behandlung von E-Mails fest, die die SPF- oder DKIM-Überprüfungen nicht bestehen, und konfiguriert das Senden von Berichten. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  - p=reject — lehnt E-Mails ab, die die Überprüfung nicht bestehen.
  - rua=mailto:... — Adresse für aggregierte Berichte.
  - ruf=mailto:... — Adresse für forensische Berichte (spezifische Fehler).
  - pct=100 — wendet die Richtlinie auf 100 % der E-Mails an.
- Verifizierung: example.com. 3600 IN TXT "google-site-verification=abc123..."
Hinweise:
- Wenn eine Textzeichenfolge länger als 255 Bytes ist, kann sie in mehrere Teile in der Zonendatei aufgeteilt werden, wobei jeder Teil in Anführungszeichen eingeschlossen wird. Der DNS-Server verknüpft sie automatisch.
  example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
Überprüfung: dig +short example.com TXT

NS — Nameserver-Eintrag

Zweck: Gibt die DNS-Server an, die für die Zone autoritativ sind. Diese Einträge sind die Grundlage für die Delegierung der Domainverwaltung.
Format: name TTL IN NS Servername.
Beispiel:
example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
Wichtige Punkte:
- Die NS-Einträge in der Zone müssen genau mit den beim Domain-Registrar angegebenen Nameservern übereinstimmen.
- Glue Records: Wenn der Nameserver (z. B. ns1.example.com.) innerhalb derselben Zone liegt, die er bedient (example.com.), entsteht eine zyklische Abhängigkeit. Um dies zu durchbrechen, fügen Sie beim Registrar „Glue“-Einträge — A– oder AAAA-Einträge für diese Nameserver — hinzu.
Überprüfung: dig +short example.com NS

SOA — Start of Authority-Eintrag

Zweck: Der wichtigste administrative Eintrag einer DNS-Zone. Enthält Informationen über den primären Server, den Administrator und Parameter, die die Synchronisierung zwischen dem primären und sekundären Servern steuern.
Format:
name TTL IN SOA primärer_server. admin_email. ( Seriennummer ; Serial Aktualisierungsintervall ; Refresh Wiederholungsintervall ; Retry Ablaufzeit ; Expire Min_TTL ) ; Minimum TTL
Beispiel:
example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 Stunden) 3600 ; Retry (1 Stunde) 1209600 ; Expire (14 Tage) 86400 ) ; Minimum TTL (1 Tag)
Felderklärungen:
- Serial: Zonenversion. Es ist äußerst wichtig, diese Nummer bei jeder Änderung der Zone zu erhöhen. Sekundäre Server vergleichen ihre Serial mit der Serial auf dem primären Server und fordern ein Update an, wenn sie kleiner ist. Empfohlenes Format: YYYYMMDDNN (Jahr, Monat, Tag, Revisionsnummer des Tages).
- Refresh: Intervall (in Sekunden), nach dem sekundäre Server den primären Server auf Updates überprüfen sollten.
- Retry: Intervall, nach dem ein sekundärer Server erneut versuchen sollte, wenn der erste Aktualisierungsversuch fehlschlägt.
- Expire: Zeit (in Sekunden), nach der ein sekundärer Server aufhört, auf Anfragen zu antworten, wenn er den primären Server nicht erreichen kann. Die Zone gilt als „abgelaufen“.
- Minimum TTL: Legte ursprünglich die minimale TTL für alle Einträge in der Zone fest. Wird jetzt oft als TTL für negatives Caching verwendet (wie lange eine „Eintrag nicht gefunden“-Antwort zwischengespeichert werden soll).
Überprüfung: dig +short example.com SOA

PTR — Zeiger-Eintrag (Reverse DNS)

Zweck: Bietet Reverse-Auflösung — wandelt eine IP-Adresse in einen Domainnamen um. Wird vom Eigentümer der IP-Adresse (ISP, Hosting-Anbieter) verwaltet, nicht vom Domaininhaber.
Format für IPv4: Die IP-Adresse wird in umgekehrter Reihenfolge geschrieben, und das Suffix .in-addr.arpa. wird hinzugefügt.
- IP 192.0.2.5 → 5.2.0.192.in-addr.arpa.
Format für IPv6: Jeder 4-Bit-Teil (Nibble) der Adresse wird in umgekehrter Reihenfolge geschrieben, und das Suffix .ip6.arpa. wird hinzugefügt.
- IPv6 2001:db8::1 → 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
Beispiel (IPv4):
5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
Praktische Bedeutung: Kritisch wichtig für Mailservers. Die meisten Mail-Systeme überprüfen, ob der PTR-Eintrag für die IP-Adresse des Absenders mit dem Namen übereinstimmt, den der Server im HELO/EHLO-Befehl angibt. Eine Diskrepanz ist ein häufiger Grund dafür, dass E-Mails als Spam markiert werden.
Überprüfung: dig -x 192.0.2.5 +short oder host 192.0.2.5

SRV — Service-Eintrag

Zweck: Gibt den Standort von Servern für bestimmte Dienste an, einschließlich Protokoll und Port. Ermöglicht es Clients, den erforderlichen Server automatisch zu finden.
Namensformat:_service._protokoll.name.
- Dienst: sip, xmpp-server, _minecraft usw.
- Protokoll: tcp, udp.
Eintragsformat: name TTL IN SRV Priorität Gewichtung Port Ziel.
Beispiel:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
Felderklärungen:
- Priority (Priorität): Je kleiner die Zahl, desto höher die Priorität. Der Client versucht zuerst, eine Verbindung zum Server mit der niedrigsten Priorität herzustellen.
- Weight (Gewichtung): Wird zur Lastverteilung zwischen Servern mit gleicher Priorität verwendet. Die Wahrscheinlichkeit, einen Server auszuwählen, ist proportional zu seinem Gewicht. Wenn alle Gewichtungen gleich sind, erfolgt die Auswahl zufällig.
- Port (Port): Der Port, auf dem der Dienst läuft.
- Target (Ziel): Der FQDN des Servers, an den die Anfrage gerichtet werden soll. Dieser Server muss einen A– oder AAAA-Eintrag haben.
Anwendung: VoIP (SIP), Instant Messaging (XMPP), Spiele (Minecraft), Verzeichnisse (LDAP).
Überprüfung: dig +short _sip._tcp.example.com SRV

CAA — Zertifizierungsstellen-Autorisierung

Zweck: Ermöglicht es dem Domaininhaber, festzulegen, welche Zertifizierungsstellen (CA) berechtigt sind, SSL/TLS-Zertifikate für diese Domain auszustellen. Dies ist ein wichtiger Sicherheitsmechanismus, um die unbefugte Ausstellung von Zertifikaten zu verhindern.
Format: name TTL IN CAA Flags Tag Wert
Beispiel:
example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
Erklärungen:
- Flags: Normalerweise 0. Das Flag 128 (kritisch) bedeutet, dass eine CA, die dieses Tag nicht versteht, die Ausstellung des Zertifikats ablehnen muss.
- Tags:
  - issue: Erlaubt der angegebenen CA, Zertifikate auszustellen. Ein leerer Wert (;) verbietet die Ausstellung durch jeden.
  - issuewild: Erlaubt die Ausstellung von Wildcard-Zertifikaten (*.example.com).
  - iodef: URL (normalerweise mailto: oder http(s):) zum Senden von Berichten über Versuche, die CAA-Richtlinie zu verletzen.
Überprüfung: dig +short example.com CAA

NAPTR — Namensautoritäts-Zeiger-Eintrag

Zweck: Wird für komplexe Regeln zur Umschreibung von Namen und URIs verwendet. Am häufigsten in Telekommunikationssystemen (ENUM zur Umwandlung von Telefonnummern in SIP-URIs) und für die dynamische Diensterkennung angewendet.
Format: name TTL IN NAPTR Reihenfolge Präferenz Flags Dienst regulärer_Ausdruck Ersatz.
Beispiel (vereinfacht für ENUM):
4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
Erklärungen:
- Order (Reihenfolge): Wird von klein nach groß verarbeitet.
- Preference (Präferenz): Analog zum weight in SRV für Einträge mit derselben order.
- Flags: U bedeutet, dass das Ergebnis ein URI ist (z. B. sip:).
- Service: Diensttyp (z. B. E2U+sip — Umwandlung in SIP-URI).
- Regexp: Regulärer Ausdruck zur Transformation der Eingabezeichenfolge.
- Replacement: Alternative zum regulären Ausdruck (normalerweise leer, wenn regexp verwendet wird).
Anwendung: Komplexe Routing-Szenarien in VoIP, ENUM.

TLSA — TLS-Zertifikats-Assoziations-Eintrag (DANE)

Zweck: Bindet ein TLS-Zertifikat (oder einen Teil davon) über einen DNS-Eintrag an einen DNS-Namen. Dies ist Teil des DANE-Standards (DNS-basierte Authentifizierung benannter Entitäten). Erfordert die Aktivierung von DNSSEC, um Vertrauen zu gewährleisten; andernfalls kann der Eintrag gefälscht werden.
Namensformat: _port._protokoll.name.
Eintragsformat: name TTL IN TLSA Verwendung Selektor Übereinstimmungstyp Daten
Beispiel:
_443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
Felderklärungen:
- Usage (Verwendung):
  - 3 (DANE-EE): Endentitäts-Zertifikat. Am häufigsten.
  - 1 (PKIX-EE): Endentitäts-Zertifikat, muss von einer vertrauenswürdigen CA signiert sein.
  - 2 (DANE-TA): Vertrauenswürdiges Zertifikat der Zertifizierungsstelle.
  - 0 (PKIX-TA): CA-Zertifikat, muss in der Vertrauenskette sein.
- Selector (Selektor):
  - 0: Vollständiges Zertifikat.
  - 1: Nur der öffentliche Schlüssel des Zertifikats.
- Matching Type (Übereinstimmungstyp):
  - 0: Exakte Daten (nicht verwendet).
  - 1: SHA-256-Hash.
  - 2: SHA-512-Hash.
- Data: Hash des Zertifikats oder seines öffentlichen Schlüssels im Hex-Format.
Anwendung: Verbesserung der TLS-Sicherheit, insbesondere in Umgebungen, in denen öffentlichen CAs nicht vertraut werden kann.
Überprüfung: dig +short _443._tcp.www.example.com. TLSA

DNSSEC-Einträge (DNSKEY, DS, RRSIG, NSEC, NSEC3)

DNSSEC (Domain Name System Security Extensions) ist eine Reihe von Erweiterungen, die DNS-Einträgen kryptografische Signaturen hinzufügen, um sie vor Fälschung (Spoofing) und Cache-Vergiftungsangriffen zu schützen.

Allgemeines Prinzip: Die Zone wird mit einem privaten Schlüssel signiert. Der öffentliche Schlüssel wird in einem DNSKEY-Eintrag veröffentlicht. Um eine Vertrauenskette zu erstellen, wird der Hash dieses Schlüssels (DS-Eintrag) in der übergeordneten Zone (z. B. für example.com — in der .com-Zone) veröffentlicht. Clients, die DNSSEC unterstützen, können die Signatur (RRSIG) jedes Eintrags mit dem öffentlichen Schlüssel verifizieren und seine Authentizität sicherstellen.
DNSKEY: Der öffentliche Schlüssel der Zone.
- Beispiel:example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
  - 257 — Flags (257 = KSK, 256 = ZSK).
  - 3 — Protokoll (immer 3).
  - 13 — Algorithmus (13 = ECDSA/SHA256).
  - Letztes Feld — Schlüssel in Base64.
DS (Delegation Signer): Hash des öffentlichen Schlüssels (DNSKEY) der untergeordneten Zone, der in der übergeordneten Zone veröffentlicht wird, um eine Vertrauenskette zu erstellen.
- Beispiel:example.com. 3600 IN DS 54517 13 2 84C8...D34F
  - 54517 — Key Tag (Schlüsselkennung).
  - 13 — Algorithmus.
  - 2 — Digest-Typ (SHA-256).
  - Letztes Feld — Hash in Hex.
RRSIG (Resource Record Signature): Digitale Signatur für eine Reihe von DNS-Einträgen.
- Beispiel (Signatur für A-Eintrag):example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
  - A — Typ der signierten Einträge.
  - 13 — Algorithmus.
  - 2 — Anzahl der Labels im Namen.
  - 3600 — Original-TTL.
  - 20251001000000 — Ablaufzeit der Signatur.
  - 20250901000000 — Beginn der Signatur.
  - 54517 — Key Tag des signierenden Schlüssels.
  - example.com. — Name des Signierenden.
  - Letztes Feld — Signatur in Base64.
NSEC / NSEC3: Werden verwendet, um negative Antworten zu authentifizieren (Nachweis, dass ein Eintrag mit einem solchen Namen oder Typ nicht existiert). NSEC3 hashiert zusätzlich Namen, um vor „Zone Walking“ zu schützen.
Aktivierung von DNSSEC: Dies ist ein separater, komplexer Prozess:
1. Generieren Sie Schlüsselpaare (KSK und ZSK) auf dem DNS-Server.
2. Veröffentlichen Sie DNSKEY-Einträge in der Zone.
3. Generieren Sie einen DS-Eintrag aus dem KSK.
4. Veröffentlichen Sie den DS-Eintrag beim Domain-Registrar (in der übergeordneten Zone).
5. Aktivieren Sie die Zonensignierung auf dem DNS-Server (automatische Generierung von RRSIG, NSEC/NSEC3).
6. Testen Sie mit dig +dnssec und Online-Tools (z. B. Verisign DNSSEC Debugger).
Überprüfung:
- dig +dnssec example.com A (zeigt RRSIG für A-Eintrag, wenn DNSSEC aktiviert und funktioniert).
- dig +short example.com DNSKEY
- dig +short example.com DS

SSHFP — SSH-Public-Key-Fingerprint

Zweck: Veröffentlicht den Hash (Fingerprint) des SSH-Schlüssels des Hosts im DNS. SSH-Clients können diesen Eintrag verwenden, um die Authentizität des Servers bei der ersten Verbindung automatisch zu überprüfen und so „Man-in-the-Middle“-Angriffe (MITM) zu verhindern. Es wird empfohlen, ihn mit DNSSEC zu verwenden, um die Authentizität des Eintrags zu gewährleisten.
Format: name TTL IN SSHFP Algorithmus Digest-Typ Fingerprint
Beispiel:
example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
Erklärungen:
- Algorithmus:
  - 1 — RSA
  - 2 — DSA
  - 3 — ECDSA
  - 4 — ED25519
- Digest-Typ:
  - 1 — SHA-1
  - 2 — SHA-256
- Fingerprint: Hash des öffentlichen Schlüssels im Hex-Format.
Generierung: Auf dem Server können Sie den Eintrag mit dem Befehl generieren: ssh-keygen -r example.com
Überprüfung: dig +short example.com SSHFP

Seltene und Diensteinträge

HINFO (Host-Informationen): Speichert Informationen über den CPU-Typ und das Betriebssystem des Hosts. Nicht zur Verwendung empfohlen, da es potenziell sensible Systeminformationen preisgibt.
- Beispiel: server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
LOC (Standort): Speichert die geografischen Koordinaten (Breitengrad, Längengrad, Höhe) des Hosts.
- Beispiel: example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
RP (Verantwortliche Person): Gibt die Kontaktperson an, die für die Zone verantwortlich ist. Die E-Mail wird im Hostnamenformat angegeben (Punkt statt @).
- Beispiel: example.com. 3600 IN RP admin.example.com. txt-record.example.com.
SPF (veraltet): Existiert früher als separater Eintragstyp, wird jetzt vollständig durch TXT ersetzt. Sollte nicht verwendet werden.
- Beispiel (nicht verwenden): example.com. IN SPF "v=spf1 ..."

3. Praktische Empfehlungen und Konfigurationsfeinheiten

TTL-Verwaltung:
- Standardwert: 3600 Sekunden (1 Stunde) — ein guter Kompromiss zwischen Leistung (Caching) und Flexibilität.
- Vor der Migration: Reduzieren Sie das TTL für relevante Einträge (z. B. A/AAAA für Ihre Website) 24-72 Stunden vor der geplanten Änderung auf 300 Sekunden (5 Minuten). Dies verkürzt die Zeit, die für die Verbreitung der Änderungen benötigt wird.
- Nach der Migration: Sobald sich die Änderungen stabilisiert haben, erhöhen Sie das TTL wieder auf einen optimalen Wert (z. B. 3600 oder 86400), um die Last auf den DNS-Servern zu verringern.
SOA Serial:
- Immer erhöhen Sie die Seriennummer nach jeder Änderung der Zone. Wenn Sie dies nicht tun, werden sekundäre Server nicht über Updates informiert.
- Empfohlenes Format: YYYYMMDDNN (z. B. 2024051701). Dies ist klar und ermöglicht eine einfache Verfolgung, wann die letzte Änderung vorgenommen wurde.
CNAME auf Apex (Root-Domain):
- Problem: Der RFC-Standard verbietet CNAME auf der Apex-Domain (z. B. example.com.), da er mit anderen obligatorischen Einträgen (NS, SOA) in Konflikt steht.
- Lösung: Verwenden Sie Funktionen, die von Ihrem DNS-Anbieter bereitgestellt werden:
  - ALIAS/ANAME: Nicht standardmäßige Eintragstypen, die sich wie CNAME verhalten, aber vom DNS-Server des Anbieters dynamisch in A/AAAA-Einträge für die Client-Antwort aufgelöst werden. Dies ermöglicht die Verwendung von Aliasen auf Apex.
  - CNAME Flattening: Eine Technologie (z. B. in Cloudflare), bei der ein CNAME auf Apex automatisch „abgeflacht“ wird — der DNS-Server gibt die A/AAAA-Einträge des Zielhosts anstelle des CNAME zurück.
Glue Records:
- Wann benötigt: Wenn Ihre Nameserver (z. B. ns1.example.com.) sich innerhalb derselben Zone befinden, die sie bedienen (example.com.).
- Was tun: Finden Sie den Glue-Record-Konfigurationsabschnitt bei Ihrem Domain-Registrar und fügen Sie A– (und/oder AAAA-) Einträge für Ihre Nameserver hinzu. Dies durchbricht die zyklische Abhängigkeit.
PTR-Einrichtung für E-Mail:
- Anforderung: Die IP-Adresse Ihres Mailservers muss einen PTR-Eintrag haben, der in seinen vollqualifizierten Domainnamen (FQDN, z. B. mail.example.com.) aufgelöst wird.
- Konsistenz: Der Name, den der Mailserver im HELO/EHLO-Befehl sendet, muss mit dem Namen aus dem PTR-Eintrag übereinstimmen, und dieser Name muss wiederum einen A-Eintrag haben, der auf dieselbe IP-Adresse verweist. Dies wird als „Forward-Confirmed Reverse DNS“ (FCrDNS) bezeichnet und ist entscheidend für die Reputation.
- Wo konfigurieren: Bei Ihrem Hosting-Anbieter oder IP-Adressinhaber, nicht in der DNS-Zone Ihrer Domain.
Aufteilung langer TXT-Einträge:
- Wenn eine Zeichenfolge in einem TXT-Eintrag 255 Bytes überschreitet, muss sie in mehrere Teile in der Zonendatei aufgeteilt werden. Jeder Teil wird in Anführungszeichen eingeschlossen, und der DNS-Server verknüpft sie automatisch.
- Beispiel:
  example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Vollständige Zonendateivorlagen (BIND-Stil)

Nachfolgend finden Sie vorgefertigte Vorlagen für drei gängige Szenarien. Ersetzen Sie example.com, example.net, IP-Adressen und Schlüssel durch Ihre eigenen Werte.

a) Einfache Website (statisch, ohne E-Mail)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 Stunden)
        3600       ; retry (1 Stunde)
        1209600    ; expire (14 Tage)
        86400 )    ; minimum TTL (1 Tag)

; Authoritative Name Servers
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Web Server (IPv4 and IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; WWW subdomain (alias to apex)
www     IN CNAME @

; Security: Restrict Certificate Authorities
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Website + eigener Mailserver

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Mail Section ---
; A record for the mail server
mail    IN A    192.0.2.20

; MX record pointing to the mail server
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
; SPF: Allow mail server IP and Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM: Public key for 'default' selector
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC: Policy to quarantine failures and send reports
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"

c) Website + CDN + E-Mail + DNSSEC (komplexes Beispiel)

$TTL 300 ; Lower TTL for flexibility with CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (also used for negative caching)

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section (with CDN) ---
; Apex domain: Use ALIAS/ANAME (provider-specific) to point to origin or CDN edge
; If your provider supports ALIAS:
; @     IN ALIAS origin.examplehost.net.
; If using CNAME flattening for apex (e.g., Cloudflare):
@       IN A    192.0.2.10 ; Temporary or fallback IP, often managed by provider

; WWW subdomain: CNAME to CDN provider
www     IN CNAME cdn-provider.example.net.

; --- Mail Section ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Example keys - REPLACE WITH YOURS) ---
; DNSKEY records (usually auto-generated by DNS server when signing is enabled)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; RRSIG records are automatically generated by the DNS server during signing and are not manually added to the zone file.
; NSEC/NSEC3 records are also automatically generated.

; --- Additional Services (Example) ---
; SRV record for SIP service
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Schritt-für-Schritt-Einrichtung der E-Mail-Domain (PTR, SPF, DKIM, DMARC)

Die E-Mail-Einrichtung ist eine komplexe Aufgabe. Befolgen Sie diese Schritte, um eine maximale Zustellbarkeit und Schutz vor Spam zu gewährleisten.

Schritt 1: A/AAAA für den Mailserver einrichten
Stellen Sie sicher, dass Ihr Mailserver einen A– (und vorzugsweise AAAA-) Eintrag hat.

mail.example.com. 3600 IN A 192.0.2.20

Schritt 2: MX-Einträge einrichten
Geben Sie an, dass E-Mails für example.com an mail.example.com. zugestellt werden sollen.

example.com. 3600 IN MX 10 mail.example.com.

Schritt 3: PTR (Reverse DNS) einrichten
Dies ist der wichtigste und oft übersehene Schritt. Wenden Sie sich an Ihren Hosting-Anbieter oder IP-Adressinhaber (192.0.2.20) und fordern Sie einen PTR-Eintrag an, der auf mail.example.com. verweist.

Überprüfung: dig -x 192.0.2.20 +short sollte mail.example.com. zurückgeben.

Schritt 4: SPF (über TXT) einrichten
Definieren Sie, welche Server berechtigt sind, E-Mails im Namen von example.com zu versenden. Schließen Sie Ihren Server und alle Drittanbieter-Dienste (Gmail, SendGrid usw.) ein.

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

Beginnen Sie mit ~all (softfail) zum Testen, wechseln Sie dann zu -all (hard fail).

Schritt 5: DKIM einrichten

Generieren Sie ein Schlüsselpaar (privat und öffentlich) auf Ihrem Mailserver (MTA). Wählen Sie einen „Selektor“ (z. B. default, 202405).
Konfigurieren Sie den MTA, um ausgehende E-Mails mit dem privaten Schlüssel und dem gewählten Selektor zu signieren.
Veröffentlichen Sie den öffentlichen Schlüssel im DNS als TXT-Eintrag für die Subdomain selector._domainkey.example.com..
default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Schritt 6: DMARC einrichten
Definieren Sie die Richtlinie für die Behandlung von E-Mails, die die SPF- oder DKIM-Überprüfungen nicht bestehen, und konfigurieren Sie das Senden von Berichten.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"

Bereitstellungsstrategie:
1. Beginnen Sie mit p=none — E-Mails werden nicht blockiert, Sie erhalten nur Berichte.
2. Analysieren Sie die Berichte, beheben Sie Fehler in SPF/DKIM.
3. Wechseln Sie zu p=quarantine — verdächtige E-Mails landen im Spam.
4. Wechseln Sie zu p=reject — verdächtige E-Mails werden abgelehnt.

Zusätzliche Tipps:

Stellen Sie sicher, dass der Name, den Ihr Mailserver im HELO/EHLO-Befehl sendet, mit dem Namen aus dem PTR-Eintrag (mail.example.com.) übereinstimmt.
Verwenden Sie Online-Tools zur Überprüfung Ihrer Konfiguration: mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Befehle zur DNS-Überprüfung und -Fehlerbehebung

Befehlszeilentools sind für Administratoren unverzichtbar.

dig (Domain Information Groper) — das leistungsstärkste und empfohlene Tool.
- Grundlegende Abfragen:
  - dig +short example.com A — nur die IPv4-Adresse abrufen.
  - dig +short example.com AAAA — nur die IPv6-Adresse abrufen.
  - dig +short example.com MX — MX-Einträge abrufen.
  - dig +short example.com TXT — TXT-Einträge (SPF, DKIM, DMARC) abrufen.
  - dig +short www.example.com CNAME — CNAME abrufen.
  - dig +short _sip._tcp.example.com SRV — SRV-Eintrag abrufen.
- Reverse DNS:
  - dig -x 192.0.2.1 +short — PTR für IP abrufen.
- Delegierungs-Tracing:
  - dig +trace example.com — zeigt den gesamten Pfad von den Root-Servern zu den autoritativen Servern Ihrer Zone. Ideal zur Diagnose von Delegierungsproblemen.
- Abfrage an bestimmten Server:
  - dig @ns1.example.net example.com SOA — SOA-Eintrag bei einem bestimmten Nameserver anfordern.
- DNSSEC-Überprüfung:
  - dig +dnssec example.com A — führt eine Abfrage mit dem DO-Flag (DNSSEC OK) durch und zeigt RRSIG-Einträge an, falls vorhanden.
  - dig +short example.com DNSKEY — DNSKEY-Einträge abrufen.
  - dig +short example.com DS — DS-Eintrag (aus der übergeordneten Zone) abrufen.
- TLSA (DANE) Überprüfung:
  - dig +short _443._tcp.www.example.com. TLSA
- SSHFP Überprüfung:
  - dig +short example.com SSHFP
nslookup — altes, aber immer noch anzutreffendes Tool.
- nslookup -type=MX example.com
- nslookup -type=TXT example.com
- nslookup 192.0.2.1 (für PTR)
host — einfach und praktisch für grundlegende Abfragen.
- host -t A example.com
- host -t MX example.com
- host -t TXT example.com
- host 192.0.2.1 (für PTR)
- host -t sshfp example.com

7. Sicherheit und Best Practices

DNSSEC: Aktivieren Sie DNSSEC für kritische Domains. Dies schützt Ihre Benutzer vor gefälschten DNS-Antworten. Beginnen Sie mit einer Testdomain, um das Verfahren (Schlüsselgenerierung, Veröffentlichung von DS beim Registrar) zu beherrschen. Verwenden Sie Online-Validatoren zur Überprüfung.
CAA: Konfigurieren Sie immer CAA-Einträge. Dies ist eine einfache und effektive Möglichkeit, die unbefugte Ausstellung von Zertifikaten für Ihre Domain zu verhindern. Geben Sie nur die CAs an, die Sie verwenden (z. B. letsencrypt.org).
DKIM-Schlüsselverwaltung: Generieren Sie regelmäßig (z. B. jährlich) neue DKIM-Schlüsselpaare. Veröffentlichen Sie den neuen öffentlichen Schlüssel im DNS, konfigurieren Sie den MTA für die Verwendung des neuen Selektors und löschen Sie nach einigen Wochen (nachdem sichergestellt ist, dass alle alten E-Mails mit der alten Schlüsselsignatur verarbeitet wurden) den alten TXT-Eintrag.
Datenschutz: Veröffentlichen Sie keine HINFO-Einträge, da sie Hardware- und Softwareinformationen preisgeben, die für Angreifer nützlich sein könnten.
ANY-Abfragen: Viele öffentliche DNS-Resolver (z. B. Google Public DNS, Cloudflare) verarbeiten ANY-Abfragen nicht mehr, da sie bei DDoS-Angriffen verwendet werden. Verlassen Sie sich nicht darauf.

8. Häufige Fehler und wie man sie vermeidet

CNAME steht in Konflikt mit anderen Einträgen: Sie können nicht gleichzeitig einen CNAME und z. B. einen A oder MX für denselben Namen haben. Lösung: Überprüfen Sie die Struktur Ihrer Zone. Verwenden Sie A-Einträge oder ALIAS/ANAME für Apex.
Fehlender PTR für den Mailserver: Dies ist der Hauptgrund, warum E-Mails im Spam landen. Lösung: Konfigurieren Sie immer PTR bei Ihrem Hosting-Anbieter.
Unveränderte SOA Serial: Wenn Sie die Seriennummer nicht erhöhen, werden sekundäre Server nicht über Updates informiert. Lösung: Erhöhen Sie Serial immer nach jeder Änderung der Zone. Automatisieren Sie diesen Prozess, wenn möglich.
Falsche Formatierung langer TXT-Einträge: Wenn eine Zeichenfolge länger als 255 Bytes ist und nicht in Teile aufgeteilt wird, kann sie abgeschnitten werden oder einen Fehler verursachen. Lösung: Teilen Sie lange Zeichenfolgen in TXT-Einträgen immer auf, indem Sie jeden Teil in Anführungszeichen einschließen.
Falscher DS bei Aktivierung von DNSSEC: Wenn der beim Registrar veröffentlichte DS-Eintrag nicht mit Ihrem DNSKEY übereinstimmt, wird die Zone „nicht vertrauenswürdig“, und Clients mit aktiviertem DNSSEC können keine Einträge daraus abrufen. Lösung: Befolgen Sie sorgfältig die Anweisungen Ihres DNS-Servers und Registrars. Überprüfen Sie die Hashes zweimal.
Hohes TTL vor der Migration: Wenn das TTL hoch ist (z. B. 86400), werden Benutzer nach der Änderung der IP-Adresse einen Tag lang auf die alte Adresse geleitet. Lösung: Reduzieren Sie das TTL immer ein oder zwei Tage vor einer geplanten Migration.
CNAME auf Apex-Domain: Die direkte Verwendung von CNAME für example.com. verstößt gegen die RFC und kann unvorhersehbares Verhalten verursachen. Lösung: Verwenden Sie ALIAS/ANAME oder CNAME flattening, das von Ihrem DNS-Anbieter bereitgestellt wird.

9. Checkliste vor der Produktivfreigabe oder Migration

Verwenden Sie diese Liste für die abschließende Überprüfung vor dem Start oder der Verschiebung einer Website/eines Dienstes.

[ ] Grundlegende Einträge: A/AAAA für alle wichtigen Hosts (Web, E-Mail) sind konfiguriert und verweisen auf die richtigen IP-Adressen.
[ ] E-Mail: MX-Einträge sind konfiguriert und verweisen auf Hosts mit A/AAAA-Einträgen.
[ ] Reverse DNS: PTR-Einträge für alle IP-Adressen der Mailservers sind konfiguriert und korrekt (überprüft mit dig -x).
[ ] SPF: Der TXT-SPF-Eintrag ist konfiguriert, enthält alle erlaubten Quellen und hat den richtigen Abschlussmechanismus (-all oder ~all).
[ ] DKIM: Der öffentliche Schlüssel ist im DNS veröffentlicht, der MTA ist konfiguriert, um E-Mails zu signieren. Die Signatur wurde an einer Test-E-Mail überprüft.
[ ] DMARC: Der TXT-DMARC-Eintrag ist veröffentlicht. Für neue Bereitstellungen wird empfohlen, mit p=none zu beginnen.
[ ] Nameserver: NS-Einträge in der Zone stimmen mit den beim Registrar angegebenen Servern überein. Glue-Einträge sind bei Bedarf konfiguriert.
[ ] SOA Serial: Die Seriennummer wurde nach allen letzten Änderungen erhöht.
[ ] CAA: CAA-Einträge sind konfiguriert, um die Zertifikatsausstellung einzuschränken.
[ ] TTL: Das TTL wurde im Voraus reduziert (wenn eine Migration geplant war).
[ ] Überprüfung: Überprüfungen wurden mit dig +trace, dig MX, dig TXT und Online-Tools (z. B. MXToolbox) durchgeführt.
[ ] DNSSEC (falls aktiviert): Der DS-Eintrag ist korrekt beim Registrar hinzugefügt, DNSSEC-Überprüfungen sind erfolgreich.
[ ] Backup: Der Export der aktuellen Zone ist gespeichert.
[ ] Rollback-Plan: Die Schritte zum Rückgängigmachen von Änderungen im Fehlerfall sind klar aufgeschrieben.
[ ] Überwachung: Überwachungssysteme sind konfiguriert, um die Verfügbarkeit der DNS-Server und Änderungen in der Zone zu verfolgen.

10. Zusätzliche Beispiele und Felderklärungen

SRV — Vertiefung:_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
- Der Client wird sich zuerst mit den Servern mit Priorität 5 (xmpp1 und xmpp2) verbinden.
- Zwischen xmpp1 und xmpp2 wird die Auswahl proportional zu ihrem Gewicht sein: xmpp1 hat eine 40%ige Chance (20/(20+30)), xmpp2 — 60% (30/(20+30)).
- Der Server backup.example.com. (Priorität 10) wird nur verwendet, wenn beide Server mit Priorität 5 nicht verfügbar sind.
TLSA — Beispieldecodierung:_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
- 3 (DANE-EE): Der Client muss dieses genaue Zertifikat (oder seinen öffentlichen Schlüssel) verwenden, unabhängig von der CA-Vertrauenskette.
- 1 (Selektor): Der Eintrag speichert den Hash nicht des gesamten Zertifikats, sondern nur seines öffentlichen Schlüssels. Dies ist praktischer, da bei der erneuten Ausstellung eines Zertifikats mit demselben Schlüssel der TLSA-Eintrag nicht geändert werden muss.
- 1 (Übereinstimmungstyp): SHA-256-Hash wird verwendet.
SSHFP — Beispieldecodierung:
example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
- 4: Algorithmus — ED25519 (modern und sicher).
- 2: Digest-Typ — SHA-256.
- 356a19...28ab: SHA-256-Hash des ED25519-öffentlichen Schlüssels.

11. Nützliche Szenarien

Website mit CDN verbinden:
1. Normalerweise bittet der CDN-Anbieter Sie, einen CNAME für eine Subdomain (z. B. www) auf ihre Adresse (z. B. example.cdnprovider.com) zu setzen.
2. Wenn Sie das CDN für die Root-Domain (example.com) verwenden möchten, verwenden Sie die ALIAS/ANAME– oder CNAME flattening-Funktion Ihres DNS-Anbieters.
3. Stellen Sie sicher, dass das CDN korrekt für die Arbeit mit Ihrem SSL-Zertifikat konfiguriert ist (oft übernimmt das CDN die SSL-Terminierung). Die Berücksichtigung von CAA-Einträgen ist in diesem Fall wichtig.
Host verschieben (Migration):
1. 48-72 Stunden vor der Migration: Reduzieren Sie das TTL für die A/AAAA-Einträge Ihrer Website auf 300 Sekunden.
2. Warten: Warten Sie, bis das alte TTL „propagiert“ ist (warten Sie einen Zeitraum, der dem alten TTL entspricht, z. B. 3600 Sekunden).
3. Am Migrationstag: Ändern Sie die A/AAAA-Einträge, um auf die neuen IP-Adressen zu verweisen.
4. Überprüfung: Verwenden Sie dig +short example.com A mit verschiedenen öffentlichen DNS (Google 8.8.8.8, Cloudflare 1.1.1.1), um die Verbreitung der Änderungen zu überprüfen.
5. Nach der Stabilisierung (nach 24-48 Stunden): Erhöhen Sie das TTL wieder auf einen optimalen Wert (z. B. 3600).

12. Ready-to-Use JSON for Import into Provider Panel

Cloudflare:

{
  "zone_name": "example.com",
  "zone_type": "full",
  "records": [
    {
      "type": "A",
      "name": "@",
      "content": "192.0.2.10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "AAAA",
      "name": "@",
      "content": "2001:db8::10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "CNAME",
      "name": "www",
      "content": "example.com",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "MX",
      "name": "@",
      "content": "mail.example.com",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "content": "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns1.example.net",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns2.example.net",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "data": {
        "target": "sipserver.example.com",
        "port": 5060,
        "priority": 10,
        "weight": 60
      },
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "data": {
        "flags": 0,
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp",
      "data": {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": ""
      },
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "data": {
        "algorithm": 4,
        "digest_type": 2,
        "fingerprint": "d6f8..."
      },
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "@",
      "data": {
        "cpu": "INTEL",
        "os": "Linux"
      },
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "data": {
        "latitude": "37.7749N",
        "longitude": "122.4194W",
        "altitude": 30
      },
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "admin",
      "data": {
        "mbox": "admin.example.com",
        "txt": "Responsible person for the domain"
      },
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "_sip._tcp",
      "data": {
        "order": 100,
        "preference": 10,
        "flags": "U",
        "service": "SIP+D2U",
        "regexp": "",
        "replacement": "_sip._udp.example.com"
      },
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "data": {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": ""
      },
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "data": {
        "flags": 256,
        "protocol": 3,
        "algorithm": 8,
        "public_key": ""
      },
      "ttl": 3600
    },
    {
      "type": "RRSIG",
      "name": "@",
      "data": {
        "type_covered": "A",
        "algorithm": 8,
        "labels": 1,
        "original_ttl": 3600,
        "signature_expiration": 1700000000,
        "signature_inception": 1690000000,
        "key_tag": 12345,
        "signer_name": "example.com",
        "signature": ""
      },
      "ttl": 3600
    },
    {
      "type": "NSEC",
      "name": "@",
      "data": {
        "next_domain": "example.net",
        "types": ["A","AAAA","MX","TXT","NS"]
      },
      "ttl": 3600
    }
  ]
}

Route 53:

{
  "Comment": "Full DNS cheat sheet import",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "AAAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "2001:db8::10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 mail.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          {"Value": "ns1.example.net"},
          {"Value": "ns2.example.net"}
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 60 5060 sipserver.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "0 issue \"letsencrypt.org\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_443._tcp.example.com.",
        "Type": "TLSA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "3 1 1 "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "SSHFP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "4 2 d6f8..."}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "HINFO",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"INTEL\" \"Linux\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "LOC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "37.7749N 122.4194W 30m"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "admin.example.com.",
        "Type": "RP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "admin.example.com Responsible person for the domain"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "NAPTR",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "100 10 U SIP+D2U \"\" _sip._udp.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DS",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "12345 8 2 "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DNSKEY",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "256 3 8 "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "RRSIG",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "A 8 1 3600 1700000000 1690000000 12345 example.com "}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NSEC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.net A AAAA MX TXT NS"}]
      }
    }
  ]
}

Unterstützung für alle Eintragstypen: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, TLSA, SSHFP, HINFO, LOC, RP, NAPTR, DS, DNSKEY, RRSIG, NSEC. TTL und Prioritäten sind bereits gesetzt und können bei Bedarf angepasst werden. Verwendet ResourceRecords für jeden Eintrag, wie von AWS erforderlich.
Direkter Import über AWS CLI mit dem Befehl:

aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID --change-batch file://dns_records.json

Schlussfolgerung

DNS ist ein leistungsfähiges und flexibles System, und das Wissen darüber ist für jeden, der Webprojekte, E-Mail-Systeme oder Netzwerkinfrastrukturen verwaltet, von entscheidender Bedeutung. Dieser Leitfaden deckt alle Aspekte ab — von einfachen A-Einträgen bis hin zu komplexen Sicherheitsmechanismen wie DNSSEC und DANE.

Wichtige Erkenntnisse:

Änderungen planen: Reduzieren Sie das TTL immer vor einer Migration.
Testen: Verwenden Sie dig, nslookup und Online-Tools, um jede Konfiguration zu überprüfen.
Sicherheit zuerst: Konfigurieren Sie SPF, DKIM, DMARC für E-Mail. Aktivieren Sie CAA, um Zertifikate zu kontrollieren. Erwägen Sie die Verwendung von DNSSEC für kritische Domains.
Dokumentieren: Führen Sie Checklisten und speichern Sie Zonensicherungen.

Dieses Material ist als universelle Referenz konzipiert. Speichern Sie es, und es wird Ihnen helfen, jede Aufgabe im Zusammenhang mit DNS zu lösen.