Zone File Linter

The Zone File Linter validates BIND zone file syntax and detects common DNS configuration problems before deployment. Paste your zone file contents and the tool runs syntax, semantic, and structural validation passes, reporting errors with line numbers and specific fix recommendations. Unlike the cryptic messages BIND produces when it refuses to load a zone, this linter provides clear, actionable feedback.

Understanding Zone File Validation

DNS zone files are deceptively simple. They look like straightforward text files with records listed one per line, but they contain a surprising number of ways to introduce errors that cause outages. A missing trailing dot on an external target silently creates a nonsense hostname. A CNAME placed at the zone apex or alongside other record types violates the DNS specification and causes unpredictable resolver behavior. Duplicate records waste space and confuse audits. An invalid IP address in an A record produces a zone that loads successfully but returns garbage to clients.

The standard feedback you get from BIND when a zone file has errors is often unhelpful. Messages like "zone example.com/IN: loading from master file failed: bad owner name" do not tell you which line is wrong or what specifically is bad about it. You end up binary-searching through the file, commenting out sections until the error disappears. This is slow, frustrating, and completely unnecessary if you validate the file before attempting to load it.

This linter performs three passes over your zone file. The syntax pass checks each line for proper formatting: correct field counts, valid value formats, balanced parentheses, and proper directive syntax. The semantic pass verifies that values make sense: IP addresses are valid, hostnames follow RFC rules, TTLs are within reasonable ranges, and targets are properly qualified. The structural pass examines the zone as a whole: required SOA and NS records are present, CNAME conflicts are identified, duplicates are flagged, and orphan targets are detected. Each issue is reported with its line number, severity level, and a specific description of what is wrong and how to fix it.

How to Lint a DNS Zone File

1. Paste your BIND zone file contents into the input field
2. The linter runs syntax, semantic, and structural validation passes
3. Review the list of errors, warnings, and informational messages with line numbers
4. Fix the reported issues and re-validate until the zone file passes cleanly

Common Zone File Errors Detected

Zone File Lint Example

Input Zone File

$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 Output

Line 10: ERROR - CNAME at zone apex (@) conflicts with SOA and NS records
Line 12: WARNING - Duplicate record: www IN A 203.0.113.10
Line 15: ERROR - CNAME and MX records cannot coexist for name "smtp"
Line 16: ERROR - Invalid IPv4 address in A record: 192.168.1.500 (octet > 255)

When to Use the Zone File Linter

• Before deploying zone changes -- Catch errors that would cause BIND to reject the zone or serve incorrect responses
• After hand-editing zone files -- Manual edits frequently introduce typos, missing dots, or syntax errors
• Validating script-generated zones -- Automated zone generation scripts may produce subtly invalid output
• During DNS migrations -- Zone files exported from one DNS platform may need syntax adjustments for another
• Code review for infrastructure changes -- Include zone file linting in your review checklist for DNS pull requests
• Training and learning -- Understanding why specific zone file constructs are invalid helps deepen DNS knowledge

How Zone File Validation Works

The linter performs three validation passes, each catching different classes of problems:

Syntax Validation

Checks the raw format of each line:

• Record field counts: Each record type expects a specific number of fields (e.g., A records need a name, class, type, and IPv4 address)
• Value formats: IP addresses, hostnames, TTL values, and priority numbers are checked for valid formatting
• Directive syntax: $TTL, $ORIGIN, and $INCLUDE directives must follow BIND syntax rules
• Multi-line records: Parenthesized records (like SOA) must have matching opening and closing parentheses
• Comment handling: Semicolon comments are stripped before validation

Semantic Validation

Checks that values make sense in context:

• TTL ranges: Values should be between 60 seconds and 1 week for most records; the linter flags unreasonable TTLs
• Hostname validity: All hostnames referenced in records are checked against RFC 1123
• Target qualification: External targets should be fully qualified (trailing dot); relative targets should exist within the zone
• Address validity: A record addresses must be valid IPv4; AAAA records must be valid IPv6

Structural Validation

Checks the zone file as a whole:

• Required records: The zone apex must have at least one SOA record and at least two NS records
• CNAME conflicts: Names with CNAME records cannot have any other record types
• Apex restrictions: CNAME records cannot appear at the zone apex
• Duplicate detection: Identical records (same name, type, class, and data) are flagged
• Orphan detection: CNAME or MX targets that point to names not defined in the zone trigger a warning

Zone File Linting in Practice

The most valuable habit you can build around zone file management is to lint before every deployment. It takes seconds and catches the kinds of errors that cause outages lasting minutes or hours. A CI/CD pipeline that includes zone file linting as a pre-deployment gate is even better, because it prevents broken zone files from ever reaching production. Treat your zone files like code: they should go through review, validation, and testing before deployment.

The errors that cause the most operational pain are not the ones that BIND rejects outright. BIND will refuse to load a zone with a syntax error, and while that is disruptive, at least you know immediately that something is wrong. The dangerous errors are the ones that BIND accepts but that produce incorrect behavior: a missing trailing dot that creates a wrong CNAME target, a duplicate record that causes inconsistent responses depending on which authoritative server answers, or a CNAME conflict that makes one record type work while another silently fails. This linter catches all of these.

When debugging a zone file that the linter flags, start with the errors and fix them before addressing warnings. Errors indicate conditions that will cause DNS resolution to fail or produce incorrect results. Warnings indicate conditions that are technically valid but likely unintended, like duplicate records or TTLs that are unusually short or long. Informational messages point out things that are fine but worth being aware of, like the use of relative names that the linter resolved using the zone origin.

Frequently Asked Questions

Does the linter check if hostnames actually resolve?

No. The linter validates zone file syntax and structural correctness without performing live DNS queries. It verifies that hostnames follow RFC rules and that the zone file is internally consistent, but it does not check whether referenced external names exist in DNS.

Why does a missing trailing dot matter?

In BIND zone files, names without a trailing dot are treated as relative to the $ORIGIN (zone apex). If your zone is example.com and you write target.other.com without a trailing dot, BIND interprets it as target.other.com.example.com -- almost certainly not what you intended. Fully qualified external names must always end with a dot.

Can the linter fix errors automatically?

No. The linter reports problems but does not modify the zone file. Automated fixes could introduce new errors, especially with CNAME conflicts and structural issues that may have multiple valid resolutions. The linter provides specific enough information for you to make the correct fix.

What is the CNAME-at-apex restriction?

RFC 1034 prohibits CNAME records at the zone apex because CNAME cannot coexist with other record types, and the apex must have SOA and NS records. If you need apex aliasing, many DNS providers offer proprietary alternatives like ALIAS records or CNAME flattening, but standard BIND zone files do not support this.

Should I lint zone files that are generated by scripts?

Yes, absolutely. Automated zone generation is one of the most common sources of subtly invalid zone files. A script might produce correct output for most inputs but fail on edge cases: hostnames with unusual characters, IPv6 addresses in unexpected formats, or records that create CNAME conflicts. Linting the output of your generation scripts catches these issues before they reach production.

How do I handle multi-line SOA records?

SOA records commonly span multiple lines using parentheses. The linter handles multi-line records by tracking opening and closing parentheses and joining the lines before validation. Missing or mismatched parentheses are flagged as syntax errors.

Related Tools

• BIND Zone A/AAAA Generator - Generate BIND zone A and AAAA records from CSV
• BIND Zone CNAME Generator - Generate BIND zone CNAME records from CSV
• Hostname Validator - Validate hostnames per RFC 1123 standards
• DNS Record Set Deduper - Find and remove duplicate DNS records
• SPF Record Builder - Build SPF records with proper syntax