DNSSEC with an authoritative nameserver running BIND

I’ve just noticed that my domain-registrar published, alongside with a new interface, a form to upload DNSSEC data to the parent. Which means that I am finally able to setup DNSSEC as well. I was waiting for that for two years now.

It seems that a lot of stuff has been simplified in the meanwhile. Anyway, here’s a quick explanation on how to set it up:

mkdir /var/named/keys
cd /var/named/keys
mkdir example.de
dnssec-keygen -a ECDSAP256SHA256 -3 -n ZONE example.de
dnssec-keygen -a ECDSAP256SHA256 -3 -n ZONE -f KSK example.de
chown bind:bind /var/named -R

All my zones are in /var/named/zones hence I did create a folder „keys“ below /var/named. For every domain I do use a domain.tld folder within keys/ just as the example in the BIND DNSSEC Guide shows. Differently from most guides I am not using RSA (see below) but ECDSA for the keys.

dnssec-keygen -a RSASHA256 -b 1024 example.com
dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com

ECDSA is an elliptic curve algorithm which is shorter and should be faster. It has its drawbacks, as well. There’s a nice article on Cloudflare: ECDSA: The missing piece of DNSSEC in case you’d like to get more information.

The parameters to dnssec-keygen are pretty simple: -a chooses the algorithm. -b is not required for ECDSA; with RSA it’s there to define the keysize. -3 is just to tell dnssec-keygen to use a NSEC3-capable algorithm (ECDSAP256SHA256 is one of those). -n specifies the owner type and defaults to ZONE. If -f is not given you’ll create a ZSK (zone signing key) and we do need both a ZSK and a KSK. The public KSK is later uploaded to the parent zone, hence remember which one it was (a simple cat on the file will tell you if you forgot)

Make sure bind is able to read the keys (hence the chown above). Apart from that I am adding three lines to my zone-declaration:

zone "example.de" {
    type master;
    file "/var/named/zones/example.de";
    allow-query { any; };
    key-directory "/var/named/keys/example.de";
    inline-signing yes;
    auto-dnssec maintain;

key-directory points to the key-directory I’ve just mkdir’d above. inline-signing automates stuff; it will transparently and automatically convert zones to signed zones with the keys found in key-directory. auto-dnssec is set to maintain so that it will automate the key-management tasks you’d have with dnssec. So there is no extra tool required.

rndc reload
rndc flush

I’ve done that to reload the configuration and flush the cache on the master.

rndc refresh example.de
rndc flush

and that on the slave. You might also use retransfer example.de with rndc. Verify that both your master and your slave is aware of the DNSKEY stuff by issuing something like:

dig DNSKEY example.de @your-dns

you should get something like this:

example.de.		86400	IN	DNSKEY	257 3 13 tgX[..]vkgw==
example.de.		86400	IN	DNSKEY	256 3 13 mX0[..]qQ==

I’ve shortened the above output a bit. If that works, I’d really suggest to use two test tools to verify it really works. There’s DNSVIZ and the DNSSEC Analyzer.

The DNSSEC form at my domain-registrar wants me to enter the following information (because it’s german I’ve translated it roughly):

  • DNSSec Schlüssel-Flags (1) [key flags]
  • DNSSec Schlüssel-Protokoll (1) [key protocol]
  • DNSSec Algorithmus (1) [algorithm]
  • Öffentlicher Schlüssel [BASE64 kodiert] (1) [public key base64 encoded]

The key flags are simple. It’s 257 (the KSK). The key protocol is the number followed by the key flags. Here it’s 3. The algorithm here is 13. If you used RSA like I’ve shown in the beginning, it might be 8. The public key base64 encoded is retrievable by issuing cat on the specific KSK .key file (the public one, not the .private one).

Finally (I might have done that earlier) I’ve just set NSEC3 Parameters using rndc. According to the manpage rndc signing -nsec3param is only possible with inline-signing. You should replace XXXXXXXX with a SALT of your choice.

rndc signing -nsec3param 1 0 10 XXXXXXXX example.de.

Just a few notes which might be helpful:

  • In case you’ve got an authoritative and resolving nameserver in one you need to split them (you should do so anyway but thats another topic).
  • It took ~3 hours once the DS key has been in the parent zone (.de). Be patient
  • I had trouble because I’ve sometimes forgot to make sure bind can read the keys (forgot chown)
  • Then I had trouble because my slave wasn’t aware of the DNSSEC stuff (test properly)
  • Different registrar, different rules: It seems .eu is buggy with my domain-registrar because they want KEYDATA while my registrars form submits DSDATA and I can’t do anything about that currently
  • You might need to remove the DNSSEC stuff because things didn’t work. For sure you took a backup. No you didn’t? Okay: remove the .signed and .signed.jnl (zones) and move the keys to some other directory and issue rndc signing -clear all example.de. That plus a reload/restart should help you to get rid of it.
  • If key-creation takes a long time, install haveged


Just done the same for .info; With .info it’s a bit different; the form asks me for:

  • DNSSec KeyTag (1)
  • DNSSec Algorithmus (1)
  • DNSSec Digest-Typ (1)
  • DNSSec Digest (1)

the KeyTag is the ID. It’s written in the keyfile. The algorithm is 13 again. Digest-Type is 2 here, because we need to submit the digest differently:

root@dns1:/var/named/keys/jeanbruenn.info# dnssec-dsfromkey Kjeanbruenn.info.+013+22833.key 
jeanbruenn.info. IN DS 22833 13 1 29DD422F65B762CC0D0403389F294EB750BFB163
jeanbruenn.info. IN DS 22833 13 2 972F146D20837F099C5A2F75C88998E8F2F70901964B021A12206C35F0E30DDC


  • Sebastian Klute

    27. April 2017 at 10:51 Antworten

    Thanks for this helpful post.
    Working smoothly now with ECDSAP256SHA256 on two Domains, so far on bdl-mainz.de and repaircafe-vg-nieder-olm.de

    Registrar is netcup at the moment, but I got some trouble on another registrar to access the required settings, waiting for reply from their support.

    • jean

      29. April 2017 at 14:07 Antworten

      Mhm. Dnsstuff moans about your SOA records, probably due to the usage of cloudflare. Not sure. Apart from that, looks good, yeah 🙂

Post a Comment