DNSSEC? In MY zone?

So I’ve been postponing this for a literal decade and a half, but this morning after a short night of sleep and a strong tea¹, I wondered if it wasn’t time for me to do it. Actually for some reason I felt compelled to do it right now.

I’ve been doing little DNS things because I’m migrating my domains to a cheaper registrar so it’s not a completely random thought though. They offer secondary DNS for free by the way!

So yeah I started serving DNS records with Bind and I’m still using it today. I’m really not an expert and I’m doing the most simple things with it. Also it’s sufficient for my needs, works just fine and I spend close to no time managing it, so I’m not interested in spending time learning another system.

Which means: I’m using static files for my zones, and I change them by hand when needed (like twice a year maybe).

You might already know what is DNSSEC but just in case

It’s been around for 25 years, it’s basically TLS for DNS: DNS is a very light protocol that relies on the network being secure because it has almost no security built-in; obviously assuming the network is secure is outdated, so maybe we should use some cryptography to prevent man-in-the-middle attacks.

It’s not encryption though: only authentication. The request are still clear-text on the network, but at least they’re signed using a scheme reminiscent of TLS, with root master keys, signing TLD keys, which in turn sign domain keys, which are used to authenticate responses.

Setting it up

It used to be very tedious, I found old tutorials which span pages. You had to generate keys, sign zones, add DNSSEC records manually, or use a script to do it.

But nowadays there’s dnssec-policy directly in Bind and it all makes it very easy, at least in my setup.

zone "elynx.fr" {
  type master;
  file "[...]/zones/db.elynx.fr";
  [...]
  dnssec-policy default;
  inline-signing yes;
  key-directory "[...]/keys";
};

I just added the three last directives:

• dnssec-policy default tells Bind to create, maintain and use the keys for this zone.
• inline-signing yes tells Bind to concatenate the zone file and the DNSSEC records in an temporary zone file that will be used instead of the static zone file. Bind must be able to write this temporary file in the same folder than the static zone file.
• key-directory indicates a directory where the keys will be stored, it must be writable by Bind too.

This way I can just update my static zone file and reload Bind and it all works as usual! But with DNSSEC!

Isn’t there somebody you forgot to ask?

Ho right. Now I have a key that authenticates my DNS records but nobody’s authenticating my key.

In the keys directory, Bind generated three files, and we’re interested in the public key (this one: Kelynx.fr.+013+46836.key) which we need to give to our TLD (.fr) so people wanting to authenticate our responses will know our signature is made with a key that is trusted by some authority.

We’ll use the next command to extract the key and some metadata in a suitable format from this key file:

$ dnssec-dsfromkey keys/Kelynx.fr.+013+46836.key
elynx.fr. IN DS 46836 13 2 325F1D5C17083F985DC22588D1721AD7E33899EA92917E092930024456450C54

Because my registrar asked me for that data:

• A key ID: 46836, I’m not sure where that comes from, I guess it’s derived from the key?
• An algorithm: 13 means ECDSA_P256_SHA256 which means that we’re using Elliptic Curve Digital Signature Algorithm for authentication and SHA-256 for hashing.
• A digest type for the key: 2 means SHA-256
• A digest: the long string, which is the digest of our public key.

(all this data is public, just a DNS request away)

ECDSA was used here because it’s what’s in the default policy of Bind for DNSSEC. Elliptic curves are fast and cheap so that’s nice. There’s support for Ed25519 too!

So I put all the numbers in the text fields and triple checked everything because of the red bold text above said text fields, and a few minutes later boom I was using DNSSEC!

The operation I did with my registrar turned the checkmark green for the line Found 1 DS records for elynx.fr in the fr zone in Verisign’s DNSSEC Debugger, which means the zone of my TLD (.fr) had received my key, and thus made a chain of trust from the root servers to my little records!

It wasn’t that bad

Well I’m thankful for the automatic key management of Bind for sure. I had nothing to do in particular for the DNSSEC stuff to transfer along with the zones to the slave servers!

I made this post so I can remember how I did it, but it’s public so maybe it’ll help someone else too! Obviously I’m not an expert in DNS stuff but I’m pretty sure my very simple setup is ok.

Anyways, now you’ll be sure to get all these blog posts untampered, from me and no-one else, with both TLS and DNSSEC, yay!