Zone-File-Linter

Ueberprüfe Zone Files auf Syntaxfehler und Duplikate

Zone File Content

Lint Results

Paste a BIND zone file to validate

Der Zone-File-Linter validiert die BIND-Zonendatei-Syntax und erkennt haeufige DNS-Konfigurationsprobleme vor der Bereitstellung. Fuegen Sie Ihren Zonendatei-Inhalt ein und das Tool fuehrt Syntax-, Semantik- und Strukturvalidierungsdurchlaeufe durch und meldet Fehler mit Zeilennummern und spezifischen Korrekturempfehlungen. Im Gegensatz zu den kryptischen Meldungen, die BIND erzeugt, wenn es eine Zone nicht laden kann, liefert dieser Linter klares, umsetzbares Feedback.

Zonendatei-Validierung verstehen

DNS-Zonendateien sind truegerisch einfach. Sie sehen aus wie unkomplizierte Textdateien mit Eintraegen, die Zeile fuer Zeile aufgelistet sind, aber sie enthalten eine ueberraschende Anzahl von Moeglichkeiten, Fehler einzufuehren, die Ausfaelle verursachen. Ein fehlender abschliessender Punkt an einem externen Ziel erzeugt stillschweigend einen unsinnigen Hostnamen. Ein CNAME an der Zone-Apex oder neben anderen Eintragstypen verstoeest gegen die DNS-Spezifikation und verursacht unvorhersehbares Resolver-Verhalten. Doppelte Eintraege verschwenden Platz und verwirren Audits. Eine ungueltige IP-Adresse in einem A-Eintrag erzeugt eine Zone, die erfolgreich geladen wird, aber Clients Unsinn zurueckgibt.

Das Standard-Feedback, das Sie von BIND erhalten, wenn eine Zonendatei Fehler hat, ist oft wenig hilfreich. Meldungen wie "zone example.com/IN: loading from master file failed: bad owner name" sagen Ihnen nicht, welche Zeile falsch ist oder was genau daran schlecht ist. Sie muessen am Ende binaer durch die Datei suchen und Abschnitte auskommentieren, bis der Fehler verschwindet. Das ist langsam, frustrierend und voellig unnoetig, wenn Sie die Datei vor dem Laden validieren.

Dieser Linter fuehrt drei Durchlaeufe ueber Ihre Zonendatei durch. Der Syntaxdurchlauf prueft jede Zeile auf korrekte Formatierung: richtige Feldanzahlen, gueltige Wertformate, ausgewogene Klammern und korrekte Direktiven-Syntax. Der Semantikdurchlauf verifiziert, dass Werte sinnvoll sind: IP-Adressen sind gueltig, Hostnamen folgen RFC-Regeln, TTLs liegen in angemessenen Bereichen, und Ziele sind korrekt qualifiziert. Der Strukturdurchlauf untersucht die Zonendatei als Ganzes: erforderliche SOA- und NS-Eintraege sind vorhanden, CNAME-Konflikte werden identifiziert, Duplikate werden gekennzeichnet und verwaiste Ziele werden erkannt. Jedes Problem wird mit seiner Zeilennummer, Schweregrad und einer spezifischen Beschreibung gemeldet, was falsch ist und wie es behoben werden kann.

So validieren Sie eine DNS-Zonendatei

  1. Fuegen Sie Ihren BIND-Zonendatei-Inhalt in das Eingabefeld ein
  2. Der Linter fuehrt Syntax-, Semantik- und Strukturvalidierungsdurchlaeufe durch
  3. Ueberpruefen Sie die Liste von Fehlern, Warnungen und Informationsmeldungen mit Zeilennummern
  4. Beheben Sie die gemeldeten Probleme und validieren Sie erneut, bis die Zonendatei sauber besteht

Haeufig erkannte Zonendatei-Fehler

FehlerBeispielSchweregrad
Fehlender SOA-EintragZone hat keinen SOA am ApexFehler
Fehlende NS-EintraegeZone-Apex fehlen NS-EintraegeFehler
CNAME am Zone-Apex@ IN CNAME other.example.com.Fehler
CNAME mit anderen Typenwww hat sowohl CNAME- als auch A-EintraegeFehler
Fehlender abschliessender Punkt bei FQDNwww IN CNAME target.other.comWarnung
Doppelte EintraegeZwei identische A-Eintraege fuer wwwWarnung
Unangemessener TTLTTL von 0 oder 31536001 (>1 Jahr)Warnung
Unausgewogene KlammernSOA-Eintrag mit fehlender )Fehler
Ungueltige IP im A-Eintragwww IN A 999.1.2.3Fehler
Unbekannter Eintragstypwww IN AAAB 2001:db8::1Fehler

Zonendatei-Lint-Beispiel

Eingabe-Zonendatei

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
        2024010101 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        86400 )    ; minimum
@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.
@       IN  CNAME  www.example.com.
www     IN  A      203.0.113.10
www     IN  A      203.0.113.10
mail    IN  A      203.0.113.20
smtp    IN  CNAME  mail
smtp    IN  MX     10 mail
api     IN  A      192.168.1.500

Linter-Ausgabe

Zeile 10: FEHLER - CNAME am Zone-Apex (@) steht in Konflikt mit SOA- und NS-Eintraegen
Zeile 12: WARNUNG - Doppelter Eintrag: www IN A 203.0.113.10
Zeile 15: FEHLER - CNAME- und MX-Eintraege koennen fuer den Namen "smtp" nicht koexistieren
Zeile 16: FEHLER - Ungueltige IPv4-Adresse im A-Eintrag: 192.168.1.500 (Oktett > 255)

Wann Sie den Zone-File-Linter verwenden sollten

  • Vor der Bereitstellung von Zonenaenderungen -- Fehler erkennen, die dazu fuehren wuerden, dass BIND die Zone ablehnt oder falsche Antworten liefert
  • Nach dem manuellen Bearbeiten von Zonendateien -- manuelle Bearbeitungen fuehren haeufig Tippfehler, fehlende Punkte oder Syntaxfehler ein
  • Validierung skriptgenerierter Zonen -- automatisierte Zonenerstellungsskripte koennen subtil ungueltige Ausgaben erzeugen
  • Waehrend DNS-Migrationen -- aus einer DNS-Plattform exportierte Zonendateien benoetigen moeglicherweise Syntaxanpassungen fuer eine andere
  • Code-Review fuer Infrastrukturaenderungen -- Zonendatei-Linting in Ihre Pruefcheckliste fuer DNS-Pull-Requests aufnehmen
  • Training und Lernen -- zu verstehen, warum bestimmte Zonendatei-Konstrukte ungueltig sind, hilft, DNS-Wissen zu vertiefen

Wie die Zonendatei-Validierung funktioniert

Der Linter fuehrt drei Validierungsdurchlaeufe durch, die jeweils unterschiedliche Fehlerklassen erkennen:

Syntax-Validierung

Prueft das Rohformat jeder Zeile:

  • Eintrags-Feldanzahlen: Jeder Eintragstyp erwartet eine bestimmte Anzahl von Feldern (z.B. A-Eintraege benoetigen Name, Klasse, Typ und IPv4-Adresse)
  • Wertformate: IP-Adressen, Hostnamen, TTL-Werte und Prioritaetsnummern werden auf gueltige Formatierung geprueft
  • Direktiven-Syntax: $TTL-, $ORIGIN- und $INCLUDE-Direktiven muessen den BIND-Syntaxregeln folgen
  • Mehrzeilige Eintraege: Eintraege in Klammern (wie SOA) muessen uebereinstimmende oeffnende und schliessende Klammern haben
  • Kommentarbehandlung: Semikolon-Kommentare werden vor der Validierung entfernt

Semantik-Validierung

Prueft, ob Werte im Kontext Sinn ergeben:

  • TTL-Bereiche: Werte sollten fuer die meisten Eintraege zwischen 60 Sekunden und 1 Woche liegen; der Linter kennzeichnet unangemessene TTLs
  • Hostname-Gueltigkeit: Alle in Eintraegen referenzierten Hostnamen werden gegen RFC 1123 geprueft
  • Ziel-Qualifizierung: Externe Ziele sollten vollstaendig qualifiziert sein (abschliessender Punkt); relative Ziele sollten innerhalb der Zone existieren
  • Adress-Gueltigkeit: A-Eintrag-Adressen muessen gueltiges IPv4 sein; AAAA-Eintraege muessen gueltiges IPv6 sein

Struktur-Validierung

Prueft die Zonendatei als Ganzes:

  • Erforderliche Eintraege: Der Zone-Apex muss mindestens einen SOA-Eintrag und mindestens zwei NS-Eintraege haben
  • CNAME-Konflikte: Namen mit CNAME-Eintraegen koennen keine anderen Eintragstypen haben
  • Apex-Beschraenkungen: CNAME-Eintraege koennen nicht am Zone-Apex erscheinen
  • Duplikaterkennung: Identische Eintraege (gleicher Name, Typ, Klasse und Daten) werden gekennzeichnet
  • Verwaiste-Ziel-Erkennung: CNAME- oder MX-Ziele, die auf in der Zone nicht definierte Namen verweisen, loesen eine Warnung aus

Zonendatei-Linting in der Praxis

Die wertvollste Gewohnheit, die Sie rund um die Zonendatei-Verwaltung aufbauen koennen, ist das Linten vor jeder Bereitstellung. Es dauert Sekunden und erkennt die Art von Fehlern, die Ausfaelle von Minuten oder Stunden verursachen. Eine CI/CD-Pipeline, die Zonendatei-Linting als Vor-Bereitstellungs-Gate einschliesst, ist noch besser, weil sie verhindert, dass fehlerhafte Zonendateien jemals die Produktion erreichen. Behandeln Sie Ihre Zonendateien wie Code: Sie sollten Review, Validierung und Tests vor der Bereitstellung durchlaufen.

Die Fehler, die den meisten betrieblichen Schmerz verursachen, sind nicht die, die BIND direkt ablehnt. BIND wird das Laden einer Zone mit einem Syntaxfehler verweigern, und waehrend das stoerend ist, wissen Sie zumindest sofort, dass etwas falsch ist. Die gefaehrlichen Fehler sind die, die BIND akzeptiert, die aber falsches Verhalten erzeugen: ein fehlender abschliessender Punkt, der ein falsches CNAME-Ziel erzeugt, ein doppelter Eintrag, der inkonsistente Antworten verursacht, je nachdem welcher autoritative Server antwortet, oder ein CNAME-Konflikt, der einen Eintragstyp funktionieren laesst, waehrend ein anderer stillschweigend fehlschlaegt. Dieser Linter erkennt all diese Faelle.

Beim Debugging einer Zonendatei, die der Linter beanstandet, beginnen Sie mit den Fehlern und beheben Sie sie, bevor Sie sich den Warnungen widmen. Fehler zeigen Bedingungen an, die dazu fuehren, dass die DNS-Aufloesung fehlschlaegt oder falsche Ergebnisse liefert. Warnungen zeigen Bedingungen an, die technisch gueltig, aber wahrscheinlich unbeabsichtigt sind, wie doppelte Eintraege oder TTLs, die ungewoehnlich kurz oder lang sind. Informationsmeldungen weisen auf Dinge hin, die in Ordnung sind, aber beachtenswert, wie die Verwendung relativer Namen, die der Linter anhand des Zone-Origin aufgeloest hat.

Haeufig gestellte Fragen

Prueft der Linter, ob Hostnamen tatsaechlich aufgeloest werden?

Nein. Der Linter validiert die Zonendatei-Syntax und strukturelle Korrektheit, ohne Live-DNS-Abfragen durchzufuehren. Er verifiziert, dass Hostnamen den RFC-Regeln folgen und dass die Zonendatei intern konsistent ist, prueft aber nicht, ob referenzierte externe Namen im DNS existieren.

Warum ist ein fehlender abschliessender Punkt wichtig?

In BIND-Zonendateien werden Namen ohne abschliessenden Punkt als relativ zum $ORIGIN (Zone-Apex) behandelt. Wenn Ihre Zone example.com ist und Sie target.other.com ohne abschliessenden Punkt schreiben, interpretiert BIND es als target.other.com.example.com -- fast sicher nicht das, was Sie beabsichtigt haben. Vollstaendig qualifizierte externe Namen muessen immer mit einem Punkt enden.

Kann der Linter Fehler automatisch beheben?

Nein. Der Linter meldet Probleme, aendert aber die Zonendatei nicht. Automatische Korrekturen koennten neue Fehler einfuehren, insbesondere bei CNAME-Konflikten und strukturellen Problemen, die mehrere gueltige Loesungen haben koennen. Der Linter liefert genuegend spezifische Informationen, damit Sie die richtige Korrektur vornehmen koennen.

Was ist die CNAME-am-Apex-Beschraenkung?

RFC 1034 verbietet CNAME-Eintraege am Zone-Apex, weil CNAME nicht mit anderen Eintragstypen koexistieren kann, und der Apex SOA- und NS-Eintraege haben muss. Wenn Sie Apex-Aliasing benoetigen, bieten viele DNS-Anbieter proprietaere Alternativen wie ALIAS-Eintraege oder CNAME-Flattening an, aber Standard-BIND-Zonendateien unterstuetzen dies nicht.

Sollte ich Zonendateien validieren, die von Skripten generiert werden?

Ja, unbedingt. Automatisierte Zonengenerierung ist eine der haeufigsten Quellen fuer subtil ungueltige Zonendateien. Ein Skript koennte fuer die meisten Eingaben korrekte Ausgaben erzeugen, aber bei Randfaellen versagen: Hostnamen mit ungewoehnlichen Zeichen, IPv6-Adressen in unerwarteten Formaten oder Eintraege, die CNAME-Konflikte erzeugen. Das Linten der Ausgabe Ihrer Generierungsskripte erkennt diese Probleme, bevor sie die Produktion erreichen.

Wie gehe ich mit mehrzeiligen SOA-Eintraegen um?

SOA-Eintraege erstrecken sich ueblicherweise ueber mehrere Zeilen unter Verwendung von Klammern. Der Linter behandelt mehrzeilige Eintraege, indem er oeffnende und schliessende Klammern verfolgt und die Zeilen vor der Validierung zusammenfuegt. Fehlende oder nicht uebereinstimmende Klammern werden als Syntaxfehler gekennzeichnet.

Verwandte Tools

IPparse•Kostenlose Netzwerk- & Subnetz-Rechner-Tools

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected