A Solution for Authoritative DNS
I’ve been thinking about improving my DNS setup. So many things will use e-mail verification as a backup authentication measure that it is starting to show as a real weak point. An Ars Technica article earlier this year talked about how “[f]ederal authorities and private researchers are alerting companies to a wave of domain hijacking attacks that use relatively novel techniques to compromise targets at an almost unprecedented scale.”
The two attacks that are mentioned in that article, changing the nameserver and changing records, are something that DNSSEC could protect against. Records wouldn’t have to be changed on my chosen nameservers, a BGP-hijacking could just give another server the queries for records on my domain instead and then reply with whatever it chooses.
After thinking for a while, my requirements come down to:
- Offline DNSSEC signing
- Support for storing signing keys on a HSM (YubiKey)
- Version control
- No requirement to run any Internet-facing infrastructure myself
After some searching I discovered GooDNS, a “good” DNS hosting provider. They have an interesting setup that looks to fit all of my requirements. If you’re coming from a more traditional arrangement with either a self-hosted name server or a web panel then this might seem weird, but if you’ve done a little “infrastructure as code” then maybe it is not so weird.
The inital setup must be completed via the web interface. You’ll need to have an hardware security module (HSM) for providing a time based one time password (TOTP), an SSH key and optionally a GPG key as part of the registration. You will need the TOTP to make any changes via the web interface, the SSH key will be used to interact with the git service, and the GPG key will be used for any email correspondance including recovery in the case that you lose your TOTP HSM or password.
You must validate your domain before it will be served from the GooDNS servers. There are two options for this, one for new domains and one “zero-downtime” option that is more complex but may be desirable if your domain is already live. For new domains you can simply update your nameservers at the registrar to validate your domain, for existing domains you can add a TXT record to the current DNS setup that will be validated by GooDNS to allow for the domain to be configured fully before switching the nameservers. Once the domain is validated, you will not need to use the web interface again unless updating contact, security or billing details.
All the DNS configuration is managed in a single git repository. There are three branches in the repository: “master”, “staging” and “production”. These are just the default branches, you can create other branches if you like. The only two that GooDNS will use are the “staging” and “production” branches.
GooDNS provides a script that you can install at
elsewhere in your path) which provides some simple helper commands for working
with the git repository. The script is extremely readable and so it’s easy
enough to understand and write your own scripts if you find yourself needing
something a little different.
When you clone your git repository you’ll find one text file on the master branch for each of your configured zones:
irl@computer$ git clone email@example.com:irl.git Cloning into 'irl1'... remote: Enumerating objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 Receiving objects: 100% (3/3), 22.55 KiB | 11.28 MiB/s, done. Resolving deltas: 100% (1/1), done. irl@computer$ ls irl1.net learmonth.me irl@computer$ cat irl1.net @ IN SOA ns1.irl1.net. hostmaster.irl1.net. ( _SERIAL_ 28800 7200 864000 86400 ) @ IN NS ns1.goodns.net. @ IN NS ns2.goodns.net. @ IN NS ns3.goodns.net.
In the backend GooDNS is using OpenBSD 6.4 servers with nsd(8). This means that the zone files use the same syntax. If you don’t know what this means then that is fine as the documentation has loads of examples in it that should help you to configure all the record types you might need. If a record type is not yet supported by nsd(8), you can always specify the record manually and it will work just fine.
One thing you might note here is that the string
_SERIAL_ appears instead of
a serial number. The
git-dns script will replace this with a serial number
when you are ready to publish the zone file.
I’ll assume that you already have you GPG key and SSH key set up, now let’s set up the DNSSEC signing key. For this, we will use one of the four slots of the YubiKey. You could use either 9a or 9e, but here I’ll use 9e as 9a is already the SSH key for me.
To set up the token, we will need the
yubico-piv-tool. Be extremely careful
when following these steps especially if you are using a production device. Try
to understand the commands before pasting them into the terminal.
First, make sure the slot is empty. You should get an output similar to the following one:
irl@computer$ yubico-piv-tool -s 9e -a status CHUID: ... CCC: No data available PIN tries left: 10
Now we will use
git-dns to create our key signing key (KSK):
irl@computer$ git dns kskinit --yubikey-neo Successfully generated a new private key. Successfully generated a new self signed certificate. Found YubiKey NEO. Slots available: (1) 9a - Not empty (2) 9e - Empty Which slot to use for DNSSEC signing key? 2 Successfully imported a new certificate. CHUID: ... CCC: No data available Slot 9e: Algorithm: ECCP256 Subject DN: CN=irl1.net Issuer DN: CN=irl1.net Fingerprint: 97dda8a441a401102328ab6ed4483f08bc3b4e4c91abee8a6e144a6bb07a674c Not Before: Feb 01 13:10:10 2019 GMT Not After: Feb 01 13:10:10 2021 GMT PIN tries left: 10
We can see the public key for this new KSK:
irl@computer$ git dns pubkeys irl1.net. DNSKEY 256 3 13 UgGYfiNse1qT4GIojG0VGcHByLWqByiafQ8Yt7/Eit2hCPYYcyiE+TX8HP8al/SzCnaA8nOpAkqFgPCI26ydqw==
Next we will create a zone signing key (ZSK). These are stored in the
folder of your git repository but are not version controlled. You can
optionally encrypt these with GnuPG (and so requiring the YubiKey to sign
zones) but I’ve not done that here. Operations using slot 9e do not require
the PIN so leaving the YubiKey connected to the computer is pretty much the
same as leaving the KSK on the disk. Maybe a future YubiKey will not have this
restriction or will add more slots.
irl@computer$ git dns zskinit Created ./keys/ Successfully generated a new private key. irl@computer$ git dns pubkeys irl1.net. DNSKEY 256 3 13 UgGYfiNse1qT4GIojG0VGcHByLWqByiafQ8Yt7/Eit2hCPYYcyiE+TX8HP8al/SzCnaA8nOpAkqFgPCI26ydqw= irl1.net. DNSKEY 257 3 13 kS7DoH7fxDsuH8o1vkvNkRcMRfTbhLqAZdaT2SRdxjRwZSCThxxpZ3S750anoPHV048FFpDrS8Jof08D2Gqj9w==
Now we can go to our domain registrar and add DS records to the registry for our domain using the public keys. First though, we should actually sign the zone. To create a signed zone:
irl@computer$ git dns signall Signing irl1.net... Signing learmonth.me... [production 51da0f0] Signed all zone files at 2019-02-01 13:28:02 2 files changed, 6 insertions(+), 0 deletions(-)
You’ll notice that all the zones were signed although we only created one set of keys. Set ups where you have one shared KSK and individual ZSK per zone are possible but they provide questionable additional security. Reducing the number of keys required for DNSSEC helps to keep them all under control.
To make these changes live, all that is needed is to push the production
branch. To keep things tidy, and to keep a backup of your sources, you can push
the master branch too.
git-dns provides a helper function for this:
irl@computer$ git dns push Pushing master...done Pushing production...done Pushing staging...done
If I now edit a zone file on the master branch and want to try out the zone before making it live, all I need to do is:
irl@computer$ git dns signall --staging Signing irl1.net... Signing learmonth.me... [staging 72ea1fc] Signed all zone files at 2019-02-01 13:30:12 2 files changed, 8 insertions(+), 0 deletions(-) irl@computer$ git dns push Pushing master...done Pushing production...done Pushing staging...done
If I now use the staging resolver or lookup records at
irl1.net.staging.goodns.net then I’ll see the zone live. The staging resolver
is a really cool idea for development and testing. They give you a couple of
unique IPv6 addresses just for you that will serve your staging zone files and
act as a resolver for everything else. You just have to plug these into your
staging environment and everything is ready to go. In the future they are
planning to allow you to have more than one staging environment too.
All that is left to do is ensure that your zone signatures stay fresh. This is easy to achieve with a cron job:
0 3 * * * /usr/local/bin/git-dns cron --repository=/srv/dns/irl1.net --quiet
I monitor the records independently and disable the mail output from this
command but you might want to drop the
--quiet if you’d like to get mails
from cron on errors/warnings.
On the GooDNS blog they talk about adding an Onion service for the git server in the future so that they do not have logs that could show the location of your DNSSEC signing keys, which allows you to have even greater protection. They already support performing the git push via Tor but the addition of the Onion service would make it faster and more reliable.
Unfortunately, GooDNS is entirely fictional and you can’t actually manage your DNS in this way, but wouldn’t it be nice? This post has drawn inspiration from the following:
- DNS-API - git-based DNS hosting
- DNSSEC signing with Knot DNS and YubiKey - from the cz.nic blog
- dnssec-reverb - a tool for managing DNSSEC keys and zone signing
This post was syndicated on: