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
+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.