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.
• $INCLUDE generalization: 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.
• $DEFAULT can assign a default value to a variable, which is useful in include files.
• $ADDRESS is 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.

Together with git, drag, and knot, a comfortable DNS environment can be built:

1. The DNS zone files are managed in a git repository in a high-level format.
2. Whenever a change is committed to the repository, continuous integration (CI) can ensure basic properties of the zones.
3. On success, a webhook request will inform the primary DNS of the change: continuous deployment (CD). (If this primary server is a knot Docker image, then drag is my webhook of choice.)
4. The updated high-level zone files will be fetched from the repository using git and transformed to their native format with dnstemple and the catalog zones updated.
5. 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.