Netzwerk: DNS & Dienste

DNS-Zonen: Aufbau, Prüfung und die typischen Fehler

Ein DNS-Zonen-Eintrag ist der Ort im Namesystem, an dem die Zuordnung von Namen zu Adressen tatsächlich liegt. Wer eine Domain betreibt, braucht ein Verständnis der Zonendatei – nicht, weil man sie täglich ändert, sondern weil Fehler dort den ganzen Dienst unsichtbar machen.

Der Aufbau einer Zone

; /etc/bind/zones/example.org.zone
; ACHTUNG: Ein Zonensatz endet mit einem Punkt!
; Ohne Punkt wird der Zonenname automatisch angehaengt.

$TTL 3600
$ORIGIN example.org.

@       IN  SOA ns1.example.org. hostmaster.example.org. (
            2026092601  ; Serial   - bei JEDER Aenderung erhoehen!
            3600        ; Refresh  - wie oft Sekundaer nachfragt
            900         ; Retry    - Wartezeit nach Fehlversuch
            1209600     ; Expire   - ab wann Zone als ungueltig gilt
            300 )       ; Minimum/negatives TTL

; Nameserver
@               IN  NS      ns1.example.org.
@               IN  NS      ns2.example.org.

; Adressen
@               IN  A       203.0.113.10
ns1             IN  A       203.0.113.11
ns2             IN  A       198.51.100.11
www             IN  A       203.0.113.10
mail            IN  A       203.0.113.20
api             IN  A       203.0.113.30

; IPv6
@               IN  AAAA    2001:db8::10
www             IN  AAAA    2001:db8::10

; Aliasname (CNAME) - MUSS auf einen Namen zeigen, nie auf eine A/AAAA
www2            IN  CNAME   www
ftp             IN  CNAME   www
;   Ein CNAME darf NICHT am Zonenursprung (@) stehen!
;   Dort sind SOA und NS vorgeschrieben, und ein CNAME
;   schliesst andere Eintraege desselben Namens aus.

; Mail
@               IN  MX  10  mail.example.org.
@               IN  MX  20  backup-mail.example.net.
;   Die Zahl ist die Praeferenz - kleine Zahl = bevorzugt.
;   Der MX-Wert MUSS ein Name sein, keine Adresse!

; Text-Eintraege
@               IN  TXT     "v=spf1 mx a:mail.example.org -all"
_dmarc          IN  TXT     "v=DMARC1; p=quarantine; rua=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein."
default._domainkey IN TXT   "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; Wildcard - Vorsicht!
*.dev           IN  A       203.0.113.40
;   Faengt ALLE nicht definierten Namen unter dev.example.org ab.
;   Praktisch, aber es verdeckt Tippfehler: "apti.exmaple.org"
;   statt "api" koennte ploetzlich auf einen Testserver zeigen.

; Dienst-Eintraege
_sip._tcp       IN  SRV 10 60 5060 sipserver.example.org.
;   Format: Prioritaet Gewicht Port Ziel

Die wichtigsten Eintragstypen

  • A / AAAA: Name zu IPv4- bzw. IPv6-Adresse.
  • CNAME: Alias auf einen anderen Namen. Nur für Nicht-Ursprungsnamen, nie neben anderen Einträgen desselben Namens.
  • MX: Zustellungsziel für Mail, mit Priorität.
  • TXT: Freitext. Wird für SPF, DKIM, DMARC und Domain-Bestätigungen verwendet.
  • NS: Welche Nameserver sind für diese Zone zuständig?
  • SOA: Verwaltungsdaten der Zone – genau einer je Zone.
  • SRV: Dienst, Protokoll, Port, Ziel.
  • PTR: Rückwärtssuche, liegt in einer eigenen Zone (in-addr.arpa) und wird vom Provider gepflegt.
  • CAA: Welche Zertifizierungsstellen dürfen Zertifikate für die Domain ausstellen? Eine wirksame Maßnahme gegen missbräuchliche Ausstellung. 
    @  IN  CAA  0 issue "letsencrypt.org"
@  IN  CAA  0 iodef "mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein."

Der Seriennummer-Fehler

Dies ist der häufigste Fehler im Zonenbetrieb: Wird die Seriennummer nicht erhöht, holen Sekundärserver die Änderung nie ab. Sie haben plausibel den Eindruck, aktuell zu sein – und liefern weiterhin alte Daten.

# Konvention: JJJJMMTAGxx (2026092601 = 2026-09-26, erste Aenderung)
#   Vorteil: von Hand lesbar, gut zu vergleichen.

# Ablauf nach jeder Aenderung
named-checkzone example.org /etc/bind/zones/example.org.zone
rndc reload example.org

# Auf Sekundaerservern pruefen - NICHT auf dem Primaer!
dig @ns2.example.org example.org SOA +short | awk '{print $3}'
dig @ns2.example.org www.example.org A +short
#   Weicht die Seriennummer ab, ist die Zone nicht uebertragen.
#   Protokoll: journalctl -u named | grep -i 'transfer\|xfer'

# Immer ueberpruefen, was im Cache steckt und was tatsaechlich
# ausgeliefert wird (nicht vom lokalen Resolver!)
dig @8.8.8.8 www.example.org A
dig @1.1.1.1 www.example.org A
dig +trace www.example.org

Prüfen: der Ablauf

# 1. Zonendatei syntaktisch pruefen - VOR dem Laden
named-checkzone example.org /etc/bind/zones/example.org.zone
#   Ausgabe beim Erfolg: "example.org.zone: loaded serial 2026092601"
#   Fehler werden mit Zeilennummer gemeldet.

# 2. Konfiguration pruefen
named-checkconf
named-checkconf -z            # alle Zonen laden und pruefen

# 3. Laden
rndc reload
journalctl -u named -n 30 --no-pager

# 4. Vom zustaendigen Server direkt abfragen (+norecursion!)
dig @ns1.example.org example.org SOA +norecurse
dig @ns1.example.org www.example.org A +norecurse
#   Ohne +norecurse koennte eine zwischengespeicherte Antwort
#   den falschen Eindruck erwecken.
dig @ns1.example.org example.org AXFR | head -20
#   Zonenuebertragung - funktioniert nur, wenn erlaubt.
#   Das ist auch der Test fuer Sekundaerserver.

# 5. Ueber die Oeffentlichkeit pruefen
dig +short NS example.org
dig +short www.example.org
dig +short MX example.org
dig +short TXT example.org
dig +dnssec www.example.org

# 6. Nach der Umstellung: TTL-Erwartung
#   Alte Eintraege bleiben bis zum Ablauf der TTL im Cache der Resolver.
#   Deshalb: TTL VOR der Umstellung senken (z. B. 5 Minuten),
#   umstellen, warten, danach wieder erhoehen.

Absichten des Zoneninhalts: Split-Horizon

# Fuer interne und externe Sicht unterschiedliche Antworten:
#   Extern: www -> oeffentliche Adresse
#   Intern: www -> interne Adresse (oder anderes Ziel)
#   Umsetzung ueber zwei Zonendateien mit gleichem Namen
#   auf unterschiedlichen Servern (view in BIND).

# Fallstrick: Ein Name, der intern anders aufgeloest wird,
# muss sorgfaeltig gepflegt werden. Weichen beide Fassungen
# auseinander, ist die Fehlersuche muehsam - weil der Fehler
# von der Herkunft der Abfrage abhaengt.
#   Pruefen deshalb IMMER gegen einen oeffentlichen Resolver UND
#   gegen den eigenen internen Server, nie nur gegen einen.

Betriebsregeln

  1. Zonendateien im Versionsverwaltungssystem halten. Wer eine Zone per Hand ändert, weiß in drei Monaten nicht mehr, was wann geändert wurde.
  2. Serial erhöhen ist Pflicht. Am besten automatisch aus dem Datum erzeugen.
  3. Zwei Nameserver in unterschiedlichen Netzen. Ein zweiter Nameserver in derselben Region oder beim selben Anbieter hilft bei einem Teilausfall nicht.
  4. TTL bewusst wählen. Kurz (300) bei Diensten, die umziehen sollen – lang (86400) bei stabilen Einträgen. Kurze TTL bedeutet mehr Last.
  5. DNSSEC in Betracht ziehen. Verhindert Antwortmanipulation. Erfordert disziplinierte Schlüsselverwaltung – ein Fehler dort kann die gesamte Domain unerreichbar machen.
  6. Keine zusammengefassten Wildcards ohne Not. Ein Wildcard verdeckt Tippfehler und lässt unbeabsichtigte Namen erreichbar werden.
  7. CNAME nicht überstrapazieren. Ein CNAME auf einen dynamischen Zielnamen bricht die gesamte Kette, wenn dort ein Fehler auftritt.
  8. Prüfen nach der Übertragung, nicht nach dem Speichern. Die Sekundärserver und ein öffentlicher Resolver sind die eigentliche Kontrolle.

Die häufigsten Fehler

  1. Fehlender Punkt am Ende. www IN CNAME www.example.org (ohne Punkt) wird zu www.example.org.example.org. Der Klassiker.
  2. Serial nicht erhöht. Siehe oben.
  3. CNAME am Zonenursprung. Unzulässig – dort stehen SOA und NS.
  4. CNAME neben anderen Einträgen. Ein Name mit CNAME darf keinen weiteren Eintrag haben.
  5. Klammern falsch gesetzt. Eine vergessene schließende Klammer im SOA-Eintrag führt dazu, dass die Datei unerwartet weiterläuft – mit verwirrenden Fehlermeldungen.
  6. Tab statt Leerzeichen vergessen. Nicht zwingend ein Fehler, aber die Ursache für schwer lesbare Fehlermeldungen.
  7. Keine Klammer- und Längenprüfung vor dem Laden. named-checkzone kostet eine Sekunde und verhindert Ausfälle.
  8. Port 53 blockiert. Wenn Sekundärserver die Zone nicht abholen können, ist nicht die Zone falsch – sondern UDP/TCP 53 von der Gegenstelle blockiert. Zuerst die Erreichbarkeit prüfen.

Verwandte Grundlagen: DNS, DHCP, DNSSEC, dig und nslookup.