I’ve been working on a DNS and DNSSEC monitoring project, which is available at
It looks at externally visible features of the authoritative DNS service at a selected set of institutions. The original version monitored the roughly 200 members of Internet2. It was mostly for my own benefit, and to better understand what Penn’s peers were doing. But it’s grown a bit since then, as others have found it useful and made suggestions about other organizations I should monitor and features I should add.
I’m giving a talk about the project at the Joint Techs conference next week in Palo Alto, California. Bill Owens from NySERNET has given me the most suggestions about the project, so I also recruited him to help me do the talk :-)
The talk will be webcast, and the slides are posted at the conference website. If I manage to get to the last few slides, I hope to talk a bit about application uses of DNSSEC, and in particularly DANE/TLSA which a lot of people are excited about - if DANE sees broad adoption, this might be a compelling enough use to motivate a lot more DNSSEC deployment.
I’ll give a quick overview of the project here too, and share some preliminary observations about the data.
In addition to Internet2, I now also monitor ESNet and the set of Department of Energy Labs (ESNet is the co-organizer of the Joint Techs conference, with Internet2), the Ivy League (because Penn often likes to benchmark itself against this group), NySERNET (because Bill Owens asked me to), the set of Internet2 GigaPoPs or regional networks, the US News & World Report ranked top 20 universities, the Times Higher Education ranked top 50 universities, a set of leading Tech companies, and all the DNS top level domains.
The following screenshot shows a summary of the per-category statistics as of this writing. DNSSEC deployment is still in a very fledgling state. Only 14 (6.7%) of the Internet2 members have deployed DNSSEC. There is a much higher ratio of IPv6 enabled DNS servers for every category of institution. My definition of “IPv6-enabled” is that at least one of the published nameservers has an IPv6 address, i.e. it is in theory reachable by an IPv6-only DNS recursive resolver.
The next screenshot shows a tabular view of the DNSSEC enabled domains in Internet2. Six of them have deployed NSEC3 (the version of DNSSEC that provides a defense against zone enumeration) - the number of hash iterations range from 5 to 10, and none use the NSEC3 opt-out feature. Two of them (Kansas State and Oklahoma State) have no secure delegation, which is a bit odd, since .EDU has a sole registrar (Educause) that supports delegation signer records. Kansas State does appear to have a DLV record published though, in dlv.isc.org, the DLV registry operated by Internet Systems Consortium. Oklahoma State appears to be truly an island. Penn was the earliest deployer of DNSSEC, in August 2009. If I recall correctly, Berkeley and LSU followed in 2010.
The table is followed by a summary of DNSSEC algorithms in use for the KSK (key signing key) and ZSK (zone signing key).
The text marked in red indicates a problem detected by the monitor. In this particular table, ualr.edu is showing that 5 of 7 nameserver addresses respond to UDP queries, 5 of 7 to TCP queries, and 1 of 3 IPv6 nameserver addresses respond to queries. Clicking on the domain name takes you to the detail page (in this case, http://www.huque.com/app/dnsstat/detail/ualr.edu/ ) which provides additional information that can identify the problematic servers:
DNS/UDP failed: ns2.ualr.edu., 2620:e8:0:10::1 (<class 'dns.exception.Timeout'>, ) DNS/UDP failed: ns.ualr.edu., 2620:e8:0:10::30 (<class 'dns.exception.Timeout'>, )
In this case the same two IPv6 nameserver addresses account for all the detected failures. If we look at the entire set of domains monitored, this turns out to be a pretty frequent problem. Often a sizable number of IPv6 DNS server addresses do not work. Perhaps folks are still figuring out how to properly monitor IPv6 services (and keep them running).
The rest of my remarks and observations will be without accompanying screenshots. You can check the site out yourself for details, but some things might have changed between when I’m writing this and when you’re looking at the project site (the monitor updates the data once per week).
The ESNet community has by far the highest proportion of DNSSEC (9 of 11, or 82%) and IPv6 enabled domains (11 of 11, or 100%!). However it’s a small sample size, and the likely reason is that these organizations were subject to the US federal government OMB mandate to get IPv6 and DNSSEC deployed.
Three of the sixteen gigapops have DNSSEC: MAGPI (which is run out of Penn), 3ROX (our neighbor in Pennsylvania), and MERIT. Interestingly, none have secure delegations in their parent zones. For MAGPI, this is because our registrar, Network Solutions can’t do DS records yet (last I checked), and perhaps a similar situation holds for 3rox.net. Both MAGPI and 3ROX have DLV records at dlv.isc.org. MERIT could get a secure delegation from EDU, but for some reason they don’t have a KSK (i.e. a key defined as a secure entry point). Not sure what’s going on there.
The situations in the Ivy League and the US News top 20 don’t look particularly good. In both categories, Penn is the only DNSSEC signed domain, although there are a sizable number of IPv6 enabled domains. Looking at the Times Higher Edu top 50, which includes several universities outside the US, is a bit more promising. The five in that category with DNSSEC are UC Berkeley, Cambridge University, Carnegie Mellon, Imperial College, and Penn. None of them use NSEC3.
The Top Level Domains appear to be in reasonably good shape, comparatively speaking. Of the 313 TLDs, 97 or 31.0% have DNSSEC, and 268 or 85.6% have IPv6. (Note to self: I have to decide later if I’m going to expand this category to include the swarm of new gTLDs in the pipeline!)
The “Leading Tech Companies” category looks pretty abysmal. This is my list of selected tech companies. If anyone has suggestions about other companies I should have included, I’d be happy to receive them. Of the 44 companies there now, only Comcast has deployed DNSSEC (Philadelphia appears to be a hotbed of DNSSEC activity!). Only 10 have IPv6 reachable DNS servers. Notably, Google and Facebook have no IPv6 DNS authoritative servers. This means that although their websites are available over IPv6, clients using IPv6-only DNS recursive resolvers will not be able to reach them! Google is also the only one that has no EDNS0 support.
I’ll end this article with the output of the project’s detail page for Google:
DNS zone details for: google.com (Google) Date of latest check: July 10, 2012, 9:10 a.m. Time required for check: 0.38 seconds Zone Summary information: 4 Nameserver records (IPv4=4, IPv6=0) 4 Nameserver addresses (IPv4=4, IPv6=0) Successful DNS/UDP response: 4 of 4 servers Successful DNS/TCP response: 4 of 4 servers Successful DNS/IPv4 response: 4 of 4 servers Successful DNS/IPv6 response: 0 of 0 servers Zone supports DNS over TCP queries on all its servers (4 responses of 4) DNS service is NOT accessible over IPv6 Zone does NOT support DNSSEC (DNS Security Extensions) Debugging information: Found nameserver: ns4.google.com. Found IPv4 address: 184.108.40.206 Found nameserver: ns3.google.com. Found IPv4 address: 220.127.116.11 Found nameserver: ns1.google.com. Found IPv4 address: 18.104.22.168 Found nameserver: ns2.google.com. Found IPv4 address: 22.214.171.124 NS records 4, IP4 4, IP6 0 NS: ns4.google.com. has no IPv6 address record NS: ns3.google.com. has no IPv6 address record NS: ns1.google.com. has no IPv6 address record NS: ns2.google.com. has no IPv6 address record Trying DNS/UDP query to ns4.google.com., 126.96.36.199 Trying DNS/UDP query to ns3.google.com., 188.8.131.52 Trying DNS/UDP query to ns1.google.com., 184.108.40.206 Trying DNS/UDP query to ns2.google.com., 220.127.116.11 DNS/UDP success: 4 of 4 servers Trying DNS/TCP query to ns4.google.com., 18.104.22.168 Trying DNS/TCP query to ns3.google.com., 22.214.171.124 Trying DNS/TCP query to ns1.google.com., 126.96.36.199 Trying DNS/TCP query to ns2.google.com., 188.8.131.52 DNS/TCP success: 4 of 4 servers Trying EDNS0 SOA query to ns4.google.com., 184.108.40.206 Response from 220.127.116.11 doesn't contain EDNS0 OPT RR Trying EDNS0 SOA query to ns3.google.com., 18.104.22.168 Response from 22.214.171.124 doesn't contain EDNS0 OPT RR Trying EDNS0 SOA query to ns1.google.com., 126.96.36.199 Response from 188.8.131.52 doesn't contain EDNS0 OPT RR Trying EDNS0 SOA query to ns2.google.com., 184.108.40.206 Response from 220.127.116.11 doesn't contain EDNS0 OPT RR DNS/EDNS0 success: 0 of 4 servers