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?
- It’s much less efficient – all those extra lookups for every query.
- It covers more than just TLDs – ITAR could, too, but it doesn’t, for whatever reason.
- 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?
Don’t overstate the inefficiency – it’s no worse than out-of-hierarchy NS records.
Comment by Tony Finch — 22 Feb 2009 @ 20:57
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
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
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