Links

Ben Laurie blathering


DNSSEC With DLV

Tony asks “what about DLV?”.

DLV is Domain Lookaside Validation. The idea is that if your resolver can’t find a trust anchor for foo.bar.example.com, then it can go and look in a lookaside zone, hosted at, say, dlv.isc.org, for trust anchors. So, it would first look for com.dlv.isc.org and then example.com.dlv.isc.org and so forth.

So, what do I think of this? It’s another way to solve the problem of having the root not signed.

How does it compare to IANA’s ITAR?

  1. It’s much less efficient – all those extra lookups for every query.
  2. It covers more than just TLDs – ITAR could, too, but it doesn’t, for whatever reason.
  3. There doesn’t seem to be a way to force it, like there is for ITAR. That is, I would like to configure my caching server to force DNSSEC for every domain that exists in DLV, but I don’t believe I can. This makes DLV practically useless, since now only clients that check the AD bit will be aware of the failure.

Also, I think it would be organisationally better if all the participating domains would run DLV for each other, rather than have any single party running it.

Anyway, I modified my setup to also use DLV. Here’s the new Makefile

all: run

run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
	named -c named.conf -d 10 -g

named.root!
	rm -f named.root
	wget ftp://ftp.rs.internic.net/domain/named.root

rndc.key:
	rndc-confgen -a -c rndc.key

itar-trusted-keys.conf: anchors2keys anchors.xml
	./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
	mv /tmp/itar-trusted-keys itar-trusted-keys.conf

anchors.xml! iana-pgp-keys
# appears to break without -v!
	rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
	gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml

anchors2keys:
	wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
	chmod +x anchors2keys

iana-pgp-keys:
	html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
	awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
	gpg --import iana-pgp-keys.tmp2
	gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
	rm iana-pgp-keys.tmp*

force-dnssec.conf: itar-trusted-keys.conf
	awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf

isc-pgp-keys:
	rm -f 363
	wget --no-check-certificate https://www.isc.org/node/363
	html2text < 363 > isc-key.tmp
	awk '/^Version:/ { print; print ""; next; } { print }' < isc-key.tmp > isc-key.tmp2
	gpg --import isc-key.tmp2
	gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
	rm isc-key.tmp* 363

isc-dlv.conf: isc-pgp-keys
	rm -f dlv.isc.org.named.conf
	wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
	gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf
	mv dlv.isc.org.named.conf isc-dlv.conf

test:
	dig -p5453 +dnssec www.dnssec.se @localhost

and here’s named.conf

options {
  listen-on port 5453 { 127.0.0.1; };
  pid-file "named.pid";
  dnssec-enable true;
  dnssec-lookaside . trust-anchor dlv.isc.org.;
  include "force-dnssec.conf";
};

// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };

// include the rndc key
include "rndc.key";
controls {
  inet 127.0.0.1 port 1953
    allow { 127.0.0.1; }
    keys { "rndc-key"; };
};

// include ITAR trust anchors
include "itar-trusted-keys.conf";

// include ISC DLV trust anchor
include "isc-dlv.conf";

Enjoy.

Incidentally, I have enabled “forced ITAR” on my main resolver, so we’ll see how that goes. I haven’t added DLV because, like I say, failure would not be noticed, so what’s the point of all the overhead?

4 Comments

  1. Don’t overstate the inefficiency – it’s no worse than out-of-hierarchy NS records.

    Comment by Tony Finch — 22 Feb 2009 @ 20:57

  2. IMHO, DLV should be used for unsigned TLD’s, and ITAR should be used for priming signed TLD’s. And DLV lookups should not be done for domains within signed zones that have an (itar) key associated with it.

    Comment by Paul Wouters — 22 Feb 2009 @ 21:15

  3. 1. It’s much less efficient – all those extra lookups for every query.

    Firstly, there is only a potential lookup on every query. In practice there are a lot less queries to the DLV servers than
    there are queries being resolved. DLV makes use of aggressive negative caching which looks at the NSEC record that have been returned from previous queries to determine whether to make a DLV query or not.

    Additionally DLV lookups only occur when the answer is provably insecure using the configured trust anchors and the cache contents. The bigger the islands of trust become the
    less DLV will be used.

    3. There doesn’t seem to be a way to force it, like there is for ITAR. That is, I would like to configure my caching server to force DNSSEC for every domain that exists in DLV, but I don’t believe I can. This makes DLV practically useless, since now only clients that check the AD bit will be aware of the failure.

    Except that is exactly what the DLV implementation does. There is no way to not perform a DNSSEC validation if there is a DLV record returned and DLV lookups are performed for whenever the initial validation attempt returns that the answer is insecure. That DLV lookup may be answered from the cache but it is performed.

    Comment by Mark Andrews — 23 Feb 2009 @ 0:06

  4. You regret that you cannot force DNSSEC validation. But you can. Why not just adding “dnssec-validation yes;”? BIND will send back a SERVFAIL is validation fails.

    Comment by Stéphane Bortzmeyer — 23 Feb 2009 @ 17:15

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress