On a LinkedIn forum, Dan York of the Internet Society recently asked a question about who still uses the ISC DNSSEC Lookaside Validation (DLV) registry. While commenting on the discussion, I decided to take a look at the contents of the registry, and I’m sharing some of my findings in this article.
DLV is a method to locate DNSSEC public keys off-path. See RFC 5074 and RFC 4431 for details. It is meant to be an early deployment aid until full deployment of DNSSEC happens. It’s useful in situations where the DNSSEC keys for a target zone cannot be obtained by the normal top down traversal of the DNS delegation hierarchy, typically because one or more zones between the target zone and the root aren’t signed. Another situation is where a parent zone may be signed but it was not possible for the child zone to have a Delegation Signer (DS) record installed in the parent for some reason - a common one is that the DNS registrar in use did not support the ability to do it.
Internet Systems Consortium (ISC) runs a DLV registry at dlv.isc.org. The basic idea is that if you can’t find a DS record for a zone, say “example.org”, you append the name of the DLV registry and look for DLV record at “example.org.dlv.isc.org” - the contents of the record are the same as would have been found at the DS record. Validating resolvers are pre-configured with the public key of the dlv.isc.org zone and use it to authenticate the signature associated with the DLV record.
It appears that some large DNS resolver services like Google DNS and Comcast do not use any DLV registries for validation, so only zones that have an intact chain of trust can have their data validated. I’m not sure if ISC publishes any usage statistics for their DLV registry, but from casual discussion with colleagues in the US R&E community over the years, I know quite a number of universities that do have their campus resolvers configured to use it. We use it at the University of Pennsylvania too.While upenn.edu is signed and has a secure delegation in its parent, there are some auxiliary zones that we run, like magpi.net that don’t have a secure delegation, and we make use of the ISC DLV registry to publish keys there. In MAGPI’s case, the reason is that the registrar we use, Network Solutions, still doesn’t support DS records. I suppose it’s time to switch registrars, and it’s on my todo list!
In modern versions of resolvers like ISC BIND and Unbound, a mere one line addition to the configuration file will turn this feature on. In fact, some OS distributions, like Fedora Linux already have it turned on in their default configuration.
The ISC DLV zone by design uses NSEC, so it’s trivial to write a short program to fully enumerate its contents and look at the data. Here’s what I see from a snapshot of the zone taken on August 29th 2013:
Number of distinct zones: 2760 Total number of DLV records: 6020
The number of DLV records is higher because most zones have multiple DLV records - their key digests are published with mutiple hashing algorithms (SHA1 and SHA256), and in some cases mutiple keys are published (perhaps key rollovers are in progress). Here’s a breakdown of the number of DLV records per zone, and the number of zones with that many records:
#DLV recs #Zones 8 1 6 3 4 241 2 2515
The zone with 8 DLV records (!) incidentally is hysh.jp (4 keys, 2 digests/key).
Looking at the distribution of zones across Top Level Domains (TLD), we see:
Number of TLDs represented: 111
There are 318 total TLDs at the current time, 116 of which appear to be signed, so that leaves 202 that aren’t. I maintain some more detailed statistics of the TLDs at http://www.huque.com/app/dnsstat/category/tld/
Here’s the full list of the 111 TLDs represented, sorted by descending order of the number of zones within them that are in the ISC DLV registry.
arpa 487 com 456 org 270 net 263 de 185 info 75 eu 67 uk 66 ch 50 hu 49 ro 34 us 34 cz 32 za 31 pl 31 fr 29 ru 28 ca 28 it 26 biz 25 be 25 au 25 nl 24 jp 22 id 22 name 20 me 20 mx 19 tv 18 at 17 edu 16 tw 13 tk 12 es 12 mobi 11 br 10 cx 10 co 8 is 8 nu 8 fi 8 sk 8 dk 7 se 7 gov 6 im 6 ua 6 am 6 asia 5 ws 5 cc 5 in 5 nz 5 xn--p1ai 5 pt 4 gs 3 do 3 bz 3 cn 3 hr 3 ms 3 ve 3 mil 3 nf 3 gm 2 lc 2 la 2 li 2 th 2 ph 2 hn 2 mu 2 pro 2 ar 2 io 2 ni 2 gr 1 gp 1 lv 1 to 1 tl 1 lu 1 tj 1 tg 1 ec 1 rs 1 re 1 jobs 1 cm 1 int 1 tm 1 pe 1 pn 1 aero 1 hk 1 md 1 mg 1 uy 1 mw 1 ug 1 vc 1 ae 1 ai 1 al 1 vn 1 as 1 xxx 1 kg 1 sr 1 st 1 kr 1
Interestingly of the 2760 zones, 653 of them (almost a quarter!) also have DS records in their parent zones, so technically they don’t need to be in the DLV registry at all. This includes three TLDs: th, ua, and kg. I wonder what the motivation for additionally maintaining keys in a DLV registry is. One theoretical reason might be to have an off-path database of keys that could be audited in case of an attack in the normal delegation chain.
Below are the sixteen zones inside .EDU:
bucknell.edu DS exists internet2.edu DS exists k-state.edu DS exists cs.kent.edu kent.edu not signed ksu.edu DS exists ai.mit.edu mit.edu not signed csail.mit.edu mit.edu not signed dlp.mit.edu mit.edu not signed lcs.mit.edu mit.edu not signed npitest.psu.edu psu.edu not signed ualr.edu DS exists ucaid.edu DS exists cse.ucdavis.edu DS exists math.ucdavis.edu DS exists ucr.edu DS exists maf.wisc.edu wisc.edu not signed
The EDU TLD is signed and has single registrar (Educause) that has supported DNSSEC for a long time. All the second level domains in the list above also have DS records in EDU, so they don’t really need to also have DLV records. Most of the third level domains (one at Kent State U, four at MIT, one at Penn State, and one at U of Wisconsin) have parents that are not yet signed, so that makes sense. However, the two third level domains, cse.ucdavis.edu and math.ucdavis.edu have DS records in ucdavis.edu, so don’t need DLV records either.