Sunday, September 8, 2013

DNSSEC Validation in the Internet2 community

As a follow-up to my examination of the ISC DLV registry, I conducted an informal poll of some of my peers in the Internet2 community to find out 1) who is using DNSSEC validation on their resolvers, and 2) who additionally uses the ISC DLV.

A while back I setup a small project to monitor the status of DNS signed zones in Internet2 and few other selected communities. There is no easy way to programmatically determine who is using DNSSEC validation though, so the easiest way is to ask others [1]. I got responses from a number of universities and regional R&E networks. Here's a summary:

Institution                             Uses ISC DLV?
University of Pennsylvania              Yes      
Virginia Tech                           Yes
Univ of California, Los Angeles         No
Univ of Massachusetts, Amherst          No
Kansas Research & Education Network     Yes

Kansas State University                 <unknown>
Fort Hays State University              <unknown>
Louisiana State University              No
Univ of California, Berkeley            Yes
Energy Sciences Network (ESNet)         Yes
Lawrence Berkeley National Lab (LBNL)   <unknown>
North Dakota State University           Yes
Univ of Delaware                        Yes

3ROX (3 Rivers Optical Exchange)        Yes
Pittsburgh Supercomputing Center (PSC)  <some resolvers>
University of Idaho                     No

I'm sure I'm missing others - I'll add to this list as I discover them. If you know of anyone, feel free to let me know!

[1] Although Geoff Huston and others have conducted some large scale studies of validation use, using a method of buying and analyzing ad impressions at popular websites, directing clients to carefully constructed URLs located in zones with differing DNSSEC signature statuses.

-- Shumon Huque

Sunday, September 1, 2013

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 The basic idea is that if you can't find a DS record for a zone, say "", you append the name of the DLV registry and look for DLV record at "" - 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 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 is signed and has a secure delegation in its parent, there are some auxiliary zones that we run, like 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 (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

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:                 DS exists                DS exists                  DS exists         not signed                      DS exists          not signed       not signed         not signed         not signed     not signed                     DS exists                    DS exists              DS exists             DS exists                      DS exists        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, and have DS records in, so don't need DLV records either.
Shumon Huque