LUA-DNS migration

Mark Janssen — Sun, 10 Jul 2022 15:50:17 GMT

At Sig-I/O we have (mostly) been using OpenProvider for DNS registrations and hosting over the last few years. This has mostly been fine, but OpenProvider has been having some issues every now and then, and is changing things, but not allways for the better.

After a period of stagnation, they now seem to be developing new features again, but none of those appeal much, while important bugs and wishlist items remain unfixed.

We've been looking at alternatives for at least the DNS hosting parts for a while, and even started looking into setting up our own anycast network of DNS servers, but concluded that his was too much effort (and money) for what we needed, so the search for a good matching DNS provider was continued.

After looking at various options, and trying out some of them with test-domains, we were most charmed with LuaDNS.net, which is a small Romenian company with a nice working anycast DNS system and an interesting method for pushing DNS updates.

LuaDNS has a webinterface for inspecting the zones and records that are served by their servers, but this interface doesn't allow updates. For updating DNS records there are 2 possible options:

Using a REST api
Using GIT and a notify-hook

Using the REST api

We use the REST-api for updating temporary records, like the 'acme-challenge' records needed for ACME validation by Lets-Encrypt, ZeroSSL or BuyPass. This is done using the dns_lua hook in acme.sh

Using GIT and notify-hooks

The primary method to add zones and records to LuaDNS is by creating a lua-script or bind-formatted file in a git repository. This has the added benefit of having an archive of all previous DNS records. In our case, we host the git repository ourselved on a Gitea instance.

Every time a git commit is pushed to this Git repository, gitea sends a webhook to the LuaDNS api server, which then clones the git repository, parses the lua-scripts and/or bind zone files, and updates its zone files. A log of this parsing it then sent via e-mail to the admin account.

DNSSec

LuaDNS supports DNSSec, which we had enabled at OpenProvider as well, so for the migration to LuaDNS we temporarily disabled this (to ease migration). Sadly, LuaDNS doesn't allow configuring (or querying) the DNSSec keys from the API at this point, but when we asked about this, we got a quick reply that this would be added in the coming weeks.

Update 2022/07/12: I just got an e-mail from LuaDNS that this feature has been added, so there is an API endpoint for DNSSec now.

This however meant that configuring the DNSSec keys was still somewhat of a manual excersize at this time. We manually enabled DNSSec on all LuaDNS hosted zones and copy/pasted the public-keys to a textfile. We then used the OpenProvider API to reconfigure all our zones to be hosted by LuaDNS and configured the DNSSec keys at the same time.

This mostly worked, though some domains gave some issues, so these were then updated by hand.

Updating the zones in Openprovider can be done with this api-call:

curl -X PUT \
  https://api.openprovider.eu/v1beta/domains/${ID} \
  -H "Accept: */*" \
  -H "Authorization: Bearer ${OPENPROVIDER_API_BEARER}" \
  -d "{ \"ns_group\": \"luadns\", \"dnssec_keys\": [ { \"alg\": 13, \"flags\": 257, \"protocol\": 3, \"pub_key\": \"${DNSSEC}\", \"readonly\": 1 } ] }"

Where {ID} is the ID of the zone at OpenProvider (which we gathered in a previous script), and {DNSSEC} is the DNSSec key from LuaDNS, which we manually gathered.

Post Migration Checks

After migration we received an e-mail from dnssec-tools, complaining about missing records we had earlier, so we re-created some tlsa-records and did some more checks while we were at it.

Some handy tools to check your various settings and configurations:

Sig-I/O (Posts about tools)

LUA-DNS migration

Using the REST api

Using GIT and notify-hooks

DNSSec

Post Migration Checks