DNS-Zonen: Datensätze, Delegation und Fehlersuche

DNS-Zonen sind die Verwaltungseinheit des Namenssystems. Eine Zone ist der Teil des Namensraums, für den ein Server zuständig ist und dessen Datensätze er verwaltet. Wer DNS einrichten oder Fehler beheben will, muss Zonen, Datensatztypen und die Regeln der Zone verstehen.

Namensraum, Domain, Zone

Drei Begriffe, die oft verwechselt werden:

Namensraum: Der gesamte hierarchische Baum des DNS, von der Wurzel (.) über die Top-Level-Domain (de, org) abwärts.
Domain: Ein Knoten in diesem Baum mit allen Unterknoten – etwa example.org.
Zone: Der Teil, der tatsächlich auf einem Server liegt und für den er autoritativ antwortet. Eine Domain kann in mehrere Zonen aufgeteilt sein – häufig, weil Unterdomains an andere Abteilungen oder Anbieter delegiert werden.

example.org                -> Zone bei ns1.example.org\n  www.example.org          -> Datensatz in derselben Zone\n  mail.example.org         -> Datensatz in derselben Zone\n  shop.example.org         -> EIGENE Zone, delegiert an anderen Anbieter\n                             (via NS-Datensatz + Glue-Adressen)\n  kunde1.example.org       -> eigene Zone

SOA: der Verwaltungsdatensatz

Jede Zone beginnt mit einem Start of Authority. Er enthält die Verwaltungsangaben:

$ dig example.org SOA +short\nns1.example.org. hostmaster.example.org. 2026092601 7200 3600 1209600 300\n\n# Feld                  Beispiel              Bedeutung\n# MNAME (primaer NS)    ns1.example.org.      zustaendiger Hauptserver\n# RNAME (Verantwortl.)  hostmaster.example.org.\n#                        (das @ wird als . geschrieben!)\n# SERIAL                2026092601            Versionsnummer der Zone\n# REFRESH               7200                  wie oft Sekundaerserver pruefen\n# RETRY                 3600                  Wiederholung bei Fehlschlag\n# EXPIRE                1209600               wann Sekundaerserver aufgibt (14 Tage)\n# MINIMUM               300                   Standard-TTL fuer negative Antworten

Die Seriennummer ist der kritische Punkt. Sie muss bei jeder Änderung erhöht werden, sonst erkennen Sekundärserver und Zwischenspeicher die Änderung nicht. Bewährt hat sich das Muster JJJJMMTTNN (Datum plus laufende Nummer) – es ist lesbar und bei mehreren Änderungen pro Tag eindeutig.

Die Datensatztypen

A       IPv4-Adresse\nAAAA    IPv6-Adresse\nCNAME   Alias auf einen anderen Namen\nMX      Mailserver (mit Prioritaet, kleinere Zahl = hoehere Prioritaet)\nTXT     Textdatensaetze (SPF, DKIM, DMARC, Verifizierungen)\nNS      zustaendige Nameserver\nSOA     Verwaltungsdatensatz\nPTR     umgekehrte Aufloesung (in der in-addr.arpa-Zone)\nSRV     Dienst mit Host und Port (Verzeichnisdienste, SIP, Minecraft)\nCAA     welche Zertifizierungsstellen duerfen Zertifikate ausstellen\nDS/DNSKEY  DNSSEC-Verkettung\nNAPTR   Diensterkennung, Telefonie\nALIAS/ANAME  herstellerspezifisch: wie CNAME, aber auch am Zonenapex\nLOC     geografische Position\nSSHFP   Fingerabdruck eines SSH-Hostschluessels

; Zonendatei (BIND-Schreibweise)\n$ORIGIN example.org.\n$TTL 3600\n\n@       IN  SOA ns1.example.org. hostmaster.example.org. (\n                2026092601  ; Serial\n                7200        ; Refresh\n                3600        ; Retry\n                1209600     ; Expire\n                300 )       ; Minimum\n\n; Nameserver (muessen eingetragen sein!)\n@       IN  NS      ns1.example.org.\n@       IN  NS      ns2.example.org.\n\n; Adressen\n@       IN  A       203.0.113.10\n@       IN  AAAA    2001:db8::10\nns1     IN  A       203.0.113.10\nns2     IN  A       203.0.113.11\nwww     IN  A       203.0.113.10\nmail    IN  A       203.0.113.20\n\n; Alias\nftp     IN  CNAME   www\n\n; Mailserver (Prioritaet 10 und 20)\n@       IN  MX  10  mail.example.org.\n@       IN  MX  20  backup-mx.example.org.\n\n; SPF, DKIM, DMARC\n@               IN  TXT "v=spf1 mx a:mail.example.org -all"\nmail._domainkey IN  TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."\n_dmarc          IN  TXT "v=DMARC1; p=reject; rua=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein."\n\n; Zertifizierungsstellen\n@       IN  CAA 0 issue "letsencrypt.org"\n\n; Unterdomain delegieren (mit Glue-Adressen)\nshop    IN  NS  ns1.shopanbieter.de.\nshop    IN  NS  ns2.shopanbieter.de.

Regeln, die eingehalten werden müssen

CNAME darf nicht an der Zonenspitze stehen (@). Ein CNAME ersetzt den Namen vollständig; damit gäbe es keinen Platz mehr für die SOA- und NS-Datensätze. Deshalb verwenden manche Anbieter herstellerspezifische ALIAS-Einträge, die sich wie ein CNAME verhalten, aber die Zonendatensätze bestehen lassen.
CNAME und andere Datensätze am selben Namen schließen sich aus. Ein Name mit CNAME darf keinen A-, MX- oder TXT-Datensatz haben.
MX zeigt nie auf einen CNAME. Immer auf einen A- oder AAAA-Datensatz. Andernfalls wird die Mailzustellung unzuverlässig.
Wildcard ist nicht „alle Namen“. Ein *-Eintrag deckt nur Namen ab, die nicht ausdrücklich existieren. Er deckt keine weitere Ebene ab: *.example.org deckt a.example.org, aber nicht a.b.example.org.
Jeder NS-Eintrag braucht Glue. Für die eigenen Nameserver muss die Adresse in der eigenen Zone stehen, sonst entsteht eine Abfrageschleife.
Serial erhöhen. Jede Änderung.
TTL bedenken. Eine lange Gültigkeitsdauer verzögert jede Änderung. Vor geplanten Umstellungen die TTL vorher senken.

Zonenübertragung und Sekundärserver

; Zonendatei pruefen (BIND)\nnamed-checkzone example.org /etc/bind/db.example.org\nnamed-checkconf\n\n; Zone neu laden\nrndc reload example.org\nrndc status\n\n; Zonenuebertragung testen (AXFR)\ndig @ns1.example.org example.org AXFR\ndig +noall +answer @ns1.example.org example.org AXFR | wc -l\n\n; Vergleichen, ob alle Nameserver dieselbe Serial haben\nfor ns in ns1.example.org ns2.example.org; do\n  echo -n "$ns: "\n  dig +short @$ns example.org SOA | awk '{print $3}'\ndone\n\n; AXFR von aussen muss abgelehnt werden!\ndig @ns1.example.org example.org AXFR\n#   Ein offener Zonentransfer gibt den gesamten Adressbestand preis -\n#   eine Einladung fuer Angreifer. Nur bekannte Sekundaerserver erlauben.

Delegation einer Unterdomain

Die häufigste Aufgabe im Alltag: Eine Unterdomain soll von einem anderen Anbieter verwaltet werden.

# In der Zone der Hauptdomain:\nshop    IN  NS  ns1.anderer-anbieter.de.\nshop    IN  NS  ns2.anderer-anbieter.de.\n\n# Optional Glue (empfohlen, wenn moeglich):\nns1.shop  IN  A  198.51.100.10\nns2.shop  IN  A  198.51.100.11\n\n# Beim anderen Anbieter: Zone fuer shop.example.org anlegen.\n# Pruefen:\ndig +short NS shop.example.org\ndig +short @ns1.anderer-anbieter.de www.shop.example.org\ndig +trace www.shop.example.org | tail -15

Wichtig: Die alte Domain bleibt zuständig für die Delegation. Ein häufig gemachter Fehler ist, den NS-Datensatz nur beim neuen Anbieter einzutragen – dann findet ihn niemand, weil die Abfrage oben beginnt.

Fehlersuche

# 1. Autoritative Antwort oder Zwischenspeicher?\ndig example.org\n#   flags: aa  -> vom zustaendigen Server (autoritativ)\n#   ohne aa    -> aus einem Zwischenspeicher\n\n# 2. Alle Nameserver vergleichen (Abweichungen sind der Klassiker)\nfor ns in ns1.example.org ns2.example.org ns3.example.org; do\n  echo "== $ns =="\n  dig +short @$ns example.org SOA | awk '{print "SOA-Serial:", $3}'\n  dig +short @$ns www.example.org\n  dig +short @$ns MX example.org\ndone\n\n# 3. Delegationskette verfolgen\ndig +trace www.example.org | tail -20\n\n# 4. Zonendatei pruefen (Syntax und Logik)\nnamed-checkzone example.org /etc/bind/db.example.org\n\n# 5. Rekursion und offene Resolver\ndig @8.8.8.8 example.org\n#   Ein eigener Server sollte Rekursion nur fuer eigene Netze erlauben.\n#   Ein offener Resolver wird fuer Verstaerkungsangriffe missbraucht.

Verwandte Grundlagen: DNS, dig und nslookup, SPF, DKIM und DMARC, DNS unter Linux einrichten.

Netzwerk: DNS & Dienste