Log in

No account? Create an account


DNSSEC with BIND 9.8.0

« previous entry | next entry »
4th May 2011 | 18:03

The latest version of BIND makes DNSSEC validation very easy to set up. Just put the following lines into the "options" section of your named.conf:

  dnssec-validation auto;
  dnssec-lookaside auto;

When you upgrade from an older version of BIND you need to delete the managed-keys.bind pseudo-zone - BIND will only add its built-in root and DLV trust anchors when it first creates the file.

That's it! Easy! Do it!

Publishing signed zones is getting easier too. If you are an old-skool DNS admin who is a dab hand at editing flat text master files, then the main thing that takes some getting used to is wrangling dynamic DNS instead. Signed zones need to be dynamic so that BIND can refresh the RRSIG records periodically, so you might as well use nsupdate to make changes too, and enjoy the shiny future.

To sign a zone, cd to named's working directory where you will create a set of keys for the zone. (You can tell BIND to look for keys elsewhere using a key-directory statement in each zone block or set it globally in the options section.) Then run these commands:

  dnssec-keygen -f KSK $zone
  dnssec-keygen $zone

This creates two key pairs with the default settings: a key signing key pair and a zone signing key pair. Ensure they are readable by the BIND user.

Then create an initial zone file. It has to have at least a SOA and an NS record. I start off with a copy of my local empty zone and change the SOA and NS later.

  $TTL 1h
  @ SOA localhost. root.localhost. 1 1h 1000 1w 1h
    NS  localhost.

Then add a zone statement to named.conf.

  zone "$zone" {
    type master;
    file "$zone";
    update-policy local;
    auto-dnssec maintain;

The update-policy statement lets you run nsupdate -l on the same machine as the nameserver to make changes to the zone. The auto-dnssec statement tells named to handle re-signing automatically. (It will also handle key rollovers if you pre-generate keys and set their lifetimes.)

Then run rndc reconfig and you are all set!

A couple of other non-default settings are possibly worth noting. There is a new feature which makes adding and deleting zones marginally neater. If you put allow-new-zones yes in your options section then you can use the rndc addzone and delzone commands instead of editing named.conf. When adding a zone you still have to create the keys and zone file first. The other tweak is to set dnssec-dnskey-kskonly yes which reduces the size of the zone apex RRSIG RRset (which should probably be the default).

| Leave a comment |

Comments {6}


from: anonymous
date: 6th May 2011 01:54 (UTC)

Isn't the KSK and ZSK stuff divide made so that the ZSK is used to only sign a few records (that being the DNSKEY and DS RR sets for the zone apex if I understand correctly) so that it won't have to be rolled over as frequently due to frequency/replay attacks?

Reply | Thread

Tony Finch

Re: KSK-only

from: fanf
date: 6th May 2011 09:08 (UTC)

Basically, yes.

The idea is that the KSK (not ZSK as you said) just signs the DNSKEY records at the apex of the zone. The ZSK signs the rest of the zone. (In fact any key in the DNSKEY RRset can sign any RRset in the zone, but you normally only make use of this flexibility during a key rollover.)

There is a flag called the "secure entry point" bit which is used to mark KSKs. This says to third parties that if the hostmaster has told them they can set up their own trust anchors for the zone, then these are the keys they should use. In fact this is almost never done and instead you rely on the chain of trust from the root, though you might want to install trust anchors for your own zones on your own resolvers. So the SEP bit usually just informs tools which keys are KSKs and which are ZSKs.

At your delegation point in the parent zone there is at least one DS record that corresponds to a KSK. The DS record is signed by the parent to authenticate the security of the delegation.

Now you don't want gratuitous churn with your KSK, because of the work this creates to update your delegation in the parent zone and the disruption to people who have configured it as a trust anchor. So you want the KSK to be kept very secure - ideally offline - so that it isn't accidentally compromised. But you need an online key for everyday signing duties - signing changes to the zone, and re-signing as signatures expire.

The KSK/ZSK split allows you to keep the KSK offline, and only bring it out occasionally just to sign the DNSKEY RRset, which you can keep more stable than the rest of the zone. If a ZSK is compromised it isn't too much of a disaster since you can quickly produce a new DNSKEY RRset and re-sign the zone without also having to deal with third parties. The dnssec-dnskey-kskonly option helps to keep this separation clear.

For most purposes this level of operational complexity isn't necessary. You can in fact just have one key for a zone and sign everything with it. (This isn't particularly risky if the key is stored in a hardware security module.) But the tools encourage the split keyset model since you have to use non-default settings to make the single key model work - see the "update-check-ksk" option.

Reply | Parent | Thread