Automatically updating reverse DNS entries for my Hetzner servers
Some parts of my infrastructure run on Hetzner dedicated servers. Hetzner's management console has an interface to update reverse DNS entries, and I wanted to automate that. Unfortunately there's no option to just delegate the zones to my own authoritative DNS servers. So I did the next best thing, which is updating the Hetzner-managed records with data from my own authoritative DNS servers.
Generating DNS zones the hard way
The first step of automating DNS record provisioning is, well, figuring
out which records need to be provisioned. I wanted to re-use my
existing automation for generating the record data, instead of coming
up with a new system for these records. The basic summary is that
there's a Go program creatively named dnsgen that's in charge of
generating zone file snippets from various sources (these include
Netbox, Kubernetes, PuppetDB and my custom reverse web proxy setup).
Those snippets are combined with Jinja templates to generate full zone files to be loaded to a hidden primary running Bind9 (like all other DNS servers I run). The zone files are then transferred to a fleet of internal authoritative servers as well as my public authoritative DNS server, which in turn transfers them to various other authoritative DNS servers (like ns-global and Traficom anycast) for redundancy.
There's also a bunch of other smaller features, like using Bind views to server different data to internal and external clients, and resolving external records during record generation time to be used on apex records that would use CNAME records if they could. (The latter is a workaround for Masto.host, the hosting provider we use for Wikis World, not having a stable IPv6 address.) Overall it's a really nice system, and I've spent quite a bit of time on it.
Updating records on Hetzner-managed space
As mentioned above, Hetzner unfortunately does not support custom DNS servers for reverse records on IP space rented from them. But I wanted to use my existing, perfectly working DNS record generation setup since that works perfectly fine. So the obvious answer is to (ab)use DNS zone file transfers.
I quickly wrote a few hundred lines of Go to request the zone data and then use the Hetzner robot API to ensure the reverse entries are in sync. The main obstacle hit here was the Hetzner API somehow requiring an "update" call (instead of a "create" one) to create a new record, as the create endpoint was returning an HTTP 400 response no matter what. Once I sorted that out, the script started working fine and created the few dozen missing records. Finally I added a CronJob in my Kubernetes cluster to run the script once in a while.
Overall this is a big improvement over doing things by hand and didn't
require that much effort. The obvious next step would be to expand the
script to a tiny DNS server capable of receiving zone update NOTIFYs to
make the updates happen real-time. Unfortunately there's now no hiding
of the records revealing my ugly hacks clever networking solutions
:(