BIND Zone File Validation Checklist

Review zone files before publishing DNS changes

Zone file mistakes are often small: one missing trailing dot, one unchanged serial, or one CNAME left beside an old A record. This checklist keeps the review focused before you load the zone into BIND or send it to a DNS provider.

Before Editing

• Confirm the exact zone origin, such as example.test, and validate against that origin.
• Start from the currently published or currently deployed zone file, not a stale copy.
• Record the current SOA serial so you can verify that the new serial increases.
• Lower TTLs ahead of planned migrations, then wait for the old TTL to expire before cutover.

Syntax Review

• The file has a $TTL directive or explicit TTLs on every relevant record.
• The SOA record is present, has the expected fields, and uses balanced parentheses if split across lines.
• Fully qualified target names end with a trailing dot.
• TXT values with spaces are quoted.
• Comments begin with ;, not #.

Record Review

• The zone has at least one NS record at the apex; production zones should normally have at least two authoritative nameservers.
• In-zone NS and MX targets have corresponding A or AAAA records.
• No owner name has a CNAME alongside A, AAAA, MX, TXT, or other records.
• The zone apex is not a CNAME.
• MX records include a numeric priority before the mail exchanger name.
• SRV records include priority, weight, port, and target in that order.
• Records belong to the current zone unless they are intentionally delegated or part of a reverse zone.

Operational Review

• The SOA serial has increased from the currently deployed version.
• TTL values match the planned rollout and rollback window.
• DNSSEC-related records are coordinated with signing and parent-zone DS updates.
• Registrar glue is updated if authoritative nameserver addresses changed.
• Rollback records are known before making a production change.

Validation and Deployment

1. Run named-checkzone locally or use the browser validator.
2. Fix the first syntax error reported, then validate again.
3. Review warnings, especially out-of-zone data or missing address records for in-zone targets.
4. Load or publish the zone only after validation is clean enough for your operating policy.
5. After deployment, query authoritative nameservers directly to confirm the expected SOA serial and record answers.