Zones and records
Zones are created with sensible defaults - SOA values, NS records, and the TTLs you actually want rather than the ones in the textbook example. Records are edited in a table with type-aware validation, so an MX record without a priority or a CNAME at the apex is refused at input time.
Serials increment automatically on every change, using the date-based convention with a counter for multiple changes in a day.
Validation before reload
Every zone change is written to a staging file and checked with named-checkzone before BIND is reloaded. A syntax error or a broken record is reported with the line number and the previous zone stays live.
The same applies to the BIND configuration itself, checked with named-checkconf.
Integration with SSL and mail
Because the panel manages DNS, it can complete DNS-01 ACME challenges for wildcard certificates without an external API, and it can generate the SPF, DKIM and DMARC records for mail domains rather than leaving them as an exercise.
This is where a single panel across workloads pays off: the DNS record needed by the mail server is created by the system that configured the mail server.
- DNS-01 challenges for wildcard SSL
- SPF, DKIM and DMARC generation for managed mail domains
- PTR records in reverse zones you control
- CAA records restricting which CAs may issue for your domain
Reverse zones and secondaries
Reverse zones for IPv4 and IPv6 ranges delegated to you are managed the same way as forward zones. Secondary servers can be configured with zone transfers restricted by key, which is the configuration most people get wrong when doing it by hand.