ISC DLV registry usage
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.
Shumon Huque