Links

Ben Laurie blathering


Doing DNSSEC Right

Since posting about DNSSEC, I’ve had lots of great feedback. So, in no particular order…

Various people have pointed out that DLV is not as bad as I suggested

  • DLV is only activated for queries that cannot be proved secure in the cache
  • DLV employs aggressive negative caching – it works out whether existing cached NSEC (and NSEC3?) records would prove nonexistence of a record before bothering to query it
  • DLV is not used for domains that have trusted keys

Although the second measure is, as I remember it, strictly speaking against the rules (one is not supposed to calculate negative responses from the cache), clearly it can be stipulated that a DLV server must behave when serving NSEC records. Anyway, the net result is that the overhead of DLV is actually quite reasonable. I still say it should be run by every DLVed domain for every other, though. In any case, I am going to switch it on in my own caching resolver.

One thing I wanted to achieve is that a DNSSEC-ignorant resolver downstream of my caching resolver would only get validated results. I tried to do this with the dnssec-must-be-secure configuration option – but this is wrong. That option requires everything to be signed, whereas in DNSSEC it is perfectly OK for a zone to be unsigned so long as its parent delegates to it with no keys (bear in mind that with DNSSEC the nonexistence of the keys is provable, and so this is secure). In fact, BIND 5.3 behaves as I want it to with just DNSSEC enabled. In BIND 5.4 onwards I will have to switch it on with the dnssec-validation option (gee, thanks, ISC for making a backward incompatible change!).

Jelte Jansen operates a domain with various broken entries – this is very handy for testing and I now include its key in my configuration. Note that if you want to see a record that fails validation, then you need to set the CD bit (with dig, +cd or +cd +dnssec if you want to see the DNSSEC records).

Paul Hoffman wonders why I would prefer a signature (for anchors2keys) to download over HTTPS. The reason is that HTTPS download doesn’t really prove the file hasn’t been interfered with – the server will serve anything that happens to be in the filesystem over HTTPS, of course. A signature would be done with a key that I would hope is very strictly supervised, and so is far more trustworthy.

Incidentally, for DNSSEC newbies, one of the interesting features of DNSSEC is that it can be done entirely with offline keys. Proving negatives (i.e. the nonexistence of names) with such a constraint is an interesting problem – and one that I spent three years working on, leading in the end to RFC 5155.

I’m sure everyone is tired of reading my config and makefile, so there’s a tarball here.

Finally, thanks very much to all the experts for the excellent feedback.

2 Comments

  1. Nice work! Sort of works on Mac with Macports. I had to change the Makefile rules “foo!” to “foo:” and haggle with some of the packages.

    When running “make test”, the success test works. However the fail test does not because I cannot resolve bogussig.test.jelte.nlnetlabs.nl with the named.conf provided.

    +trace along with +dnssec isn’t working .. will have to poke around some more.

    Comment by Jeff P — 26 Feb 2009 @ 1:07

  2. […] had feedback since I wrote about DNSSEC that my makefile didn’t work on many platforms. Why Linux and FreeBSD have to use different […]

    Pingback by Links » DNSSEC: Update — 7 Mar 2009 @ 18:26

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress