Maintaining many multiple DNS domains can be time-consuming and frustrating due to the zones diverging. This can become a source of bugs if the domain is used for more than just hosting a single web site: email (with SMTP, IMAP, POP, autoconfiguration, SPF, DKIM, DMARC, …), XMPP, name servers, DNS ownership proofs, and many more want their share of entries. Many of them follow the same pattern, but need to be updated once in a while, leading to complications.
DNStemple is a simple yet powerful DNS templating engine. To keep the threshold of entry minimal, it is a minimal extension of the well-known BIND zone file format:
- Variables with scopes, i.e., changing the variables in a deeper nesting level does not update the higher layers.
$INCLUDEgeneralization: In addition to a file name, variable names and their values can be specified, which will be visible in the included files. This allows parameterized macros, similar to a function call.
$DEFAULTcan assign a default value to a variable, which is useful in include files.
$ADDRESSis a flexible way of not having to care whether one or several addresses have been specified for that address variable and whether they are IPv4 or IPv6 addresses.
DNStemple uses a configuration file to define global variables and addresses. It is able to flexibly and automatically manage the zone serial number, if that job is not left entirely to a DNS server such as
knot. Furthermore, it will automatically manage catalog zones, if that is desired.
- The DNS zone files are managed in a
gitrepository in a high-level format.
- Whenever a change is committed to the repository, continuous integration (CI) can ensure basic properties of the zones.
- On success, a webhook request will inform the primary DNS of the change: continuous deployment (CD). (If this primary server is a
knotDocker image, then
dragis my webhook of choice.)
- The updated high-level zone files will be fetched from the repository using
gitand transformed to their native format with
dnstempleand the catalog zones updated.
- The primary DNS server is informed about the changes, will load the files, apply transforms (such as incrementing zone serial numbers on change or adding DNSSEC records), and then notify the secondaries of the updates.
In case anything should still go wrong, things can easily be rolled back to a previous, known-good, state.
A great way to make system administrators more confident and productive in their actions and have them sleep better at night.