HUQUE.COM has a signed delegation now

(Off topic: I've been at Verisign Labs over a month now - I'll write a separate post describing my experiences at my new job when I have more time. But the short summary is: no regrets so far; lots of interesting technical work I'm getting involved in; it was probably time for me to move on from Penn; and I think I made the right decision).

A few weeks ago, I created a set of test DNS TLSA records in my personal zone (huque.com) to help out some folks participating in the getdns-api hackathon. To correctly authenticate records in the zone, folks needed to have resolvers configured to use the ISC DLV registry, since I hadn't gotten around to setting up a secure delegation in the parent zone (.COM). This finally motivated me to get that done.

Why didn't I do this earlier? Long story, but I've used my own domain for a lot of experiments with DNSSEC configurations over the years (going back to 2007), including testing configurations that I eventually deployed in other larger, production domains. The bigger stumbling block is that the DNS registrar I was using, Network Solutions, does not support DNSSEC (specifically it provides no way for customers to transmit DNSKEY or DS record contents to the TLDs it registers domains in).

So last week, I started the process of changing to a DNSSEC capable registrar. There are a growing number of them out there, and ICANN maintains a list of them. The one I chose is GKG.net.

This was my first time switching registrars - Network Solutions has been my registrar since 1998 when I first registered the domain. At that time Network Solutions both operated the .com DNS top level domain (among others) and registered domains within it. In 2000, Verisign (where I now work) acquired Network Solutions to get into the DNS business, and in 2003 spun it off as a registrar-only business, retaining operation of the .com registry. Unfortunately, as far as I can tell, Network Solutions has announced no plans to support DNSSEC.

The whole process took about 5 days. On April 24th I logged into my network solutions account, unlocked my registration and requested an authorization code to transfer my domain registration. On the 25th I called them on the telephone to confirm the transfer intention and to expedite the delivery of the authorization code (it normally takes them 3 days), which I got shortly after. I then created an account at gkg.net, and initiated the domain transfer request with the supplied code. The charge was US $8.20, which included a 1-year registration period that extended beyond the current expiration date for my registration with Network Solutions. On the 28th, the transfer was successfully completed.

I then logged into the gkg.net account and used their DNSSEC interface to add a DS record for huque.com, which appeared in the .COM zone more or less immediately.

huque.com.      86400 IN DS 40924 8 2 (
                816524EB1C3B7D1315AE8330652DD17909C95DE0533C
                1F2DC023BFFEDB1F5E9B )
huque.com.      86400 IN RRSIG DS 8 2 86400 (
                20140509035959 20140502024959 56657 com.
                UkLdvaDKUcHmqAe8JQyXrxn+luWRKrkjfNzG4/xd/PXy
                zQr03L1ZXNzJHnVp7PZSau2UVfsfz5BmYGN5jepIScPc
                57zd/CnKXTZgucT9ry7dHvkdmxr+UCGY1Zg4LQ0pDyAY
                2avC9Hd2gJKBNJGWfZlGU/KHa1KvRv8fqlNWWQo= )

Below is a screen capture of their DNSSEC interface. You need to supply the parameters from your zone's DNSSEC key: the keytag, algorithm, digest type, and the digest string.

Here's a graphical view of the current chain of trust for my zone from the DNSviz tool. As you can see, there are two secure entry paths into my zone, one via the just created normal delegation path through .COM, and one via the DLV Registry at dlv.isc.org. I will be removing the DLV entries shortly.

World IPv6 Launch Measurements

From the Internet Society's most recent (January 16th 2014) round of IPv6 measurements, here again are the top 100 lists ranked by the two measures of (1) percentage of requests that used IPv6, and (2) total volume of IPv6 requests.

My past articles on this topic:
  * Measurements from December 12th 2013
  * Measurements from  September 17th 2013
  * Measurements from June 6th 2012

ISOC's blog post highlights that Deutsche Telekom, a large German telecommunications carrier, (of which T-Mobile US is a subsidiary*) has been experiencing very substantial IPv6 traffic growth. They've reached a figure of 15.5% of requests composed of IPv6 (to the select set of content providers providing measurement data). In terms of total volume of IPv6 requests, they are in 6th place behind five other large ISPs (See the second ranked list below). Comcast still leads the pack, followed by AT&T, KDDI, Free, and Verizon Wireless.

(*Note: T-Mobile's traffic is counted separately in the measurements from Deutsche Telekom)

Interestingly, while Verizon Wireless has a substantial IPv6 deployment, Verizon FIOS (their fiber-optic landline network) has made no visible progress in IPv6 deployment. Although many people, myself included, have noted this lack of deployment over the years, they were just recently taken sharply to task by folks on the NANOG (North American Network Operators Group) mailing list.

Looking at the rankings by proportion of IPv6 requests from each network, there is a new entry at the top - NYSERNet (a regional R&E network in New York State), coming in at a staggering 99.95%. On the Internet2 IPv6 working group list, I asked Bill Owens of NYSERNet if he wanted to comment. He claims that we shouldn't be too impressed because this is just the small NYSERNet office network and the backbone, with a relatively small population of clients. Regardless, I think it's a noteworthy achievement. As I've mentioned before, a number of universities and other educational organizations still show up prominently in this ranking. Two small american colleges, Gustavus Adolphus in Minnesota at 74.22% and Marist College in upstate New York at 65.77%! And Panamerican University, in Mexico City is at 66.22%.

Penn is slowly inching up at 45%. We'll have IPv6 deployed more extensively on our wireless network pretty soon, at which point I expect our numbers to go up noticeably.


World IPv6 Launch Measurements, by % IPv6 requests:
---------------------------------------------------

   1 NYSERNet 99.95%
   2 SpeedPartner GmbH 95.83%
   3 TOP-IX Consortium 86.99%
   4 Fundacao Parque Tecnologico Itaipu - Brasil 79.92%
   5 DirectVPS 78.63%
   6 interscholz Internet Services GmbH & Co. KG 75.49%
   7 Gustavus Adolphus College 74.22%
   8 Google Fiber 71.87%
   9 Universidad Panamericana 66.22%
  10 Marist College 65.77%
  11 University of Vermont 65.13%
  12 Virginia Tech 65.11%
  13 mur.at - Verein zur Frderung von Netzkwerkkunst 64.97%
  14 Association tetaneutral.net 55.67%
  15 Utility Line Italia srl 53.40%
  16 ThaiSarn 53.23%
  17 DegNet GmbH 52.84%
  18 Trunk Networks Limited 52.60%
  19 Ji?? ?trohalm 52.20%
  20 Alhambra Eidos 52.12%
  21 Louisiana State University 51.93%
  22 Ponto de Presen?a da RNP na Bahia 51.30%
  23 SuperInternet Access Pte Ltd 50.45%
  24 University of New Hampshire 50.44%
  25 Region 7 ESC 50.24%
  26 PREGINET 50.20%
  27 CICA/Junta de Andaluc?a 50.05%
  28 Tanzania Network Information Center 50.00%
  29 Karlsruhe Institute of Technology (KIT) 49.03%
  30 Maxiweb Internet Provider 48.76%
  31 Critical Colocation 48.23%
  32 University of Pennsylvania 45.38%
  33 SPAWAR 44.15%
  34 AMS-IX 42.99%
  35 University of Iowa 42.81%
  36 Kasetsart University 41.99%
  37 DreamHost 41.79%
  38 University of Minnesota 40.80%
  39 Rensselaer Polytechnic Institute 40.74%
  40 Bulgaria NREN 40.57%
  41 Verizon Wireless 40.03%
  42 CZ.NIC 39.02%
  43 guifi.net 37.86%
  44 Hughes Network Systems 35.60%
  45 Sauk Valley Community College 35.52%
  46 Tulane University 34.96%
  47 Free 34.28%
  48 ARNES 33.73%
  49 Greek Research & Technology Network 33.14%
  50 Leibniz Supercomputing Centre 32.71%
  51 Host Virtual, Inc 31.74%
  52 Netwerkvereniging Coloclue 28.41%
  53 Opera Software ASA 27.54%
  54 UNESP 27.26%
  55 UNINETT 27.13%
  56 FCCN 26.00%
  57 VOO 24.12%
  58 RCS & RDS 23.80%
  59 mc.net 23.37%
  60 UFSCar 22.96%
  61 EPT Luxembourg 22.43%
  62 FranTech Solutions 22.03%
  63 AAISP 21.22%
  64 Comcast 20.61%
  65 Chubu Telecommunications 18.90%
  66 Swisscom 18.66%
  67 XS4ALL 17.66%
  68 UFSC - Universidade Federal de Santa Catarina - Brazil 17.50%
  69 LENTEL 16.73%
  70 StarHub 16.28%
  71 Deutsche Telekom AG 15.50%
  72 NIIF/Hungarnet 14.56%
  73 LITNET 14.50%
  74 Red Acad?mica de Centros de Investigaci?n y Universidades Nacionales REACCIUN 13.85%
  75 Indiana University 13.68%
  76 ATT 13.53%
  77 SARENET 13.13%
  78 DMZGlobal 12.97%
  79 NetAssist 12.89%
  80 Academia Sinica Network 12.14%
  81 Cisco 11.95%
  82 Solcon 11.46%
  83 CESNET 11.04%
  84 Funet 10.94%
  85 PT. Wifian Solution 10.19%
  86 FidoNet 10.12%
  87 prgmr.com 9.89%
  88 T-Mobile USA 9.58%
  89 Monash University 9.28%
  90 OVH 9.26%
  91 KDDI 8.94%
  92 Spectrum Networks 8.30%
  93 AMRES - Serbian National Research and Education Network 7.84%
  94 Belnet 7.65%
  95 SWITCH 7.62%
  96 Hurricane Electric 7.58%
  97 M1 Limited 7.22%
  98 RedIRIS 6.96%
  99 Init7 6.93%
 100 CJSC Progressive Technologies 6.71%


World IPv6 Launch Measurements, by volume of IPv6:
--------------------------------------------------

   1 Comcast 20.61%
   2 ATT 13.53%
   3 KDDI 8.94%
   4 Free 34.28%
   5 Verizon Wireless 40.03%
   6 Deutsche Telekom AG 15.50%
   7 Time Warner Cable 3.88%
   8 RCS & RDS 23.80%
   9 Liberty Global 2.43%
  10 Swisscom 18.66%
  11 Telefonica del Peru 4.60%
  12 Hughes Network Systems 35.60%
  13 SoftBank BB 1.46%
  14 Chubu Telecommunications 18.90%
  15 Opera Software ASA 27.54%
  16 VOO 24.12%
  17 XS4ALL 17.66%
  18 StarHub 16.28%
  19 T-Mobile USA 9.58%
  20 Google Fiber 71.87%
  21 China Telecom 0.23%
  22 Forthnet 2.79%
  23 M1 Limited 7.22%
  24 Internode 3.94%
  25 EPT Luxembourg 22.43%
  26 Janet 3.81%
  27 its communications Inc.(iTSCOM) 2.64%
  28 CESNET 11.04%
  29 MediaCat Div./Community Netowork Center Inc. 6.58%
  30 Kasetsart University 41.99%
  31 NTT Communications 4.51%
  32 Belnet 7.65%
  33 ARNES 33.73%
  34 Leibniz Supercomputing Centre 32.71%
  35 LITNET 14.50%
  36 NIIF/Hungarnet 14.56%
  37 OVH 9.26%
  38 Cisco 11.95%
  39 BelWue 5.71%
  40 FCCN 26.00%
  41 UNINETT 27.13%
  42 Altibox AS 0.90%
  43 Monash University 9.28%
  44 SWITCH 7.62%
  45 TUBITAK ULAKBIM / ULAKNET 1.50%
  46 Australian Academic and Research Network (AARNet) 2.00%
  47 Indiana University 13.68%
  48 University of Minnesota 40.80%
  49 AAISP 21.22%
  50 UniNet 3.36%
  51 Xfone 018 0.96%
  52 Ji?? ?trohalm 52.20%
  53 Voxel / Internap 3.51%
  54 GITN Sdn Berhad 2.69%
  55 Louisiana State University 51.93%
  56 University of Pennsylvania 45.38%
  57 SuperCSI 1.69%
  58 JARING Communications Sdn Bhd 0.38%
  59 Solcon 11.46%
  60 CJSC Progressive Technologies 6.71%
  61 Starlink 1.88%
  62 inexio KGaA 2.44%
  63 Virginia Tech 65.11%
  64 green.ch AG 3.26%
  65 Hurricane Electric 7.58%
  66 Dhiraagu 0.60%
  67 Gustavus Adolphus College 74.22%
  68 LENTEL 16.73%
  69 DMZGlobal 12.97%
  70 DegNet GmbH 52.84%
  71 RedIRIS 6.96%
  72 Academia Sinica Network 12.14%
  73 GlobalConnect 1.44%
  74 University of Iowa 42.81%
  75 Funet 10.94%
  76 University of Wisconsin - Madison 6.16%
  77 Storm Internet 3.76%
  78 AMRES - Serbian National Research and Education Network 7.84%
  79 National Informatics Centre 2.32%
  80 SoftLayer Technologies 0.84%
  81 RENATER 4.57%
  82 Karlsruhe Institute of Technology (KIT) 49.03%
  83 guifi.net 37.86%
  84 Init7 6.93%
  85 Host Virtual, Inc 31.74%
  86 Rensselaer Polytechnic Institute 40.74%
  87 Choopa, LLC 0.55%
  88 NetAssist 12.89%
  89 Tulane University 34.96%
  90 DreamHost 41.79%
  91 Bulgaria NREN 40.57%
  92 FranTech Solutions 22.03%
  93 Greek Student Network 0.47%
  94 RESTENA 5.33%
  95 UNESP 27.26%
  96 iway AG 4.06%
  97 FX Networks 0.49%
  98 Tanzania Network Information Center 50.00%
  99 edpnet 1.11%
 100 ADDIX Internet Services 3.05%

EDU Top Level Domain statistics

Some DNS Top Level Domain (TLD) operators publish statistics about their DNS zones. Some others have a zone file access program that allows others to examine their data and publish statistics. Frederic Cambus (@fcambus on Twitter) maintains a site called statdns ( http://www.statdns.com/ ) that keeps statistics for several of the TLDs.

The EDU top level domain is conspicuously absent from the statdns site because the operators don't publish any statistics and also don't have a zone file access program in place. The EDU domain has a very complicated operational policy arrangement. It is managed by Educause (a higher education IT consortium), but operated by Verisign, under a contract with the United States Department of Commerce. I recently spoke with colleagues at Educause about current prospects for publishing some statistics or making the zone data available. The good news is that a zone file access program request is in fact in the queue to be approved by the Dept of Commerce. But it's stuck behind a few other requests, so it may still take some time to come to fruition.

In the meantime, to satisfy my own curiosity, I've been looking at other ways to obtain some statistics. In particular I'm interested in seeing how much DNSSEC deployment has happened so far, and how EDU compares with some of the other TLDs in this respect. One way to gain visibility into zone contents is to examine passive DNS databases. A number of folks and organizations run such databases that collect historical information seen from DNS responses at collections of resolvers. By searching records over a period of time in these databases, it's possible to reconstruct a substantial portion of the active records in a zone. I did this for EDU and analyzed the results recently.

The passive DNS database search managed to find about 7,158 second level domains under EDU. Of these, 6955 domains turned out to be valid (the others probably existed at one point but don't any more). EDU is known to have in the neighborhood of 7,000 delegations, so this is most probably a pretty good approximation of the active contents of the zone.

EDU Zone Statistics:

Number of Domains from passive DNS db: 7158
Number of Valid Domains: 6955

Total NS records: 19527
Unique NS records: 9757
Number of (glue) IPv4 address records: 4555
Number of (glue) IPv6 address records: 246

DNSSEC Specific Stats for EDU:

Number of DNSSEC Signed Zones: 94 (1.37%)
Number of NSEC3 Zones: 29 (30.1% of the signed zones)
Number of Zones with DS records: 76
Number of Zones with DLV records at dlv.isc.org: 7

As expected, only a very small fraction (1.37%) of domains have deployed DNSSEC. This compares with about 0.25% in .COM, 0.41% in .NET, and 0.30% in .ORG.

The 94 zones in EDU signed with DNSSEC are:

acadiana.edu
baker.edu
beloit.edu
berkeley.edu
bucknell.edu
cameron.edu
carnegiemellon.edu
catc.edu
chattanoogastate.edu
cltc.edu
cmu.edu
coloradomesa.edu
cookman.edu
csupomona.edu
cuhk.edu
desales.edu
drake.edu
example.edu
fhsu.edu
fhtc.edu
gfcmsu.edu
gsu.edu
gtc.edu
hfg.edu
highlands.edu
indiana.edu
indianatech.edu
internet2.edu
iu.edu
iub.edu
iup.edu
iupui.edu
jhuapl.edu
kestrel.edu
kiropraktik.edu
k-state.edu
ksu.edu
kutztown.edu
lctcs.edu
lsu.edu
ltc.edu
ma.edu
mansfield.edu
mcpherson.edu
merit.edu
mesa.edu
millikin.edu
mnsfld.edu
monmouth.edu
monterey.edu
mst.edu
nau.edu
northcentral.edu
northshorecollege.edu
nwltc.edu
okstate.edu
pacificu.edu
penn.edu
pitt.edu
psc.edu
richland.edu
rockefeller.edu
rose-hulman.edu
scl.edu
sdsmt.edu
sfcollege.edu
shoreline.edu
suu.edu
tbu.edu
tiasnimbas.edu
tilburguniversity.edu
tiss.edu
truman.edu
uaa.edu
ualr.edu
ucaid.edu
ucb.edu
ucberkeley.edu
ucdavis.edu
ucr.edu
uiowa.edu
umbc.edu
uni-stuttgart.edu
unt.edu
untsystem.edu
upenn.edu
upf.edu
usnwc.edu
uwm.edu
uwstout.edu
valencia.edu
waketech.edu
washjeff.edu
weber.edu

The 29 zones that use the NSEC3 variety of DNSSEC are:

csupomona.edu
cuhk.edu
gfcmsu.edu
internet2.edu
jhuapl.edu
kestrel.edu
kiropraktik.edu
k-state.edu
ksu.edu
lsu.edu
ma.edu
mansfield.edu
mcpherson.edu
millikin.edu
mnsfld.edu
pitt.edu
richland.edu
rose-hulman.edu
sdsmt.edu
suu.edu
tiasnimbas.edu
tilburguniversity.edu
ualr.edu
ucaid.edu
ucr.edu
uni-stuttgart.edu
unt.edu
untsystem.edu
washjeff.edu

There are 18 zones that do not have DS records published (not sure why):

beloit.edu
cameron.edu
cookman.edu
iup.edu
kiropraktik.edu
kutztown.edu
mansfield.edu
merit.edu
mnsfld.edu
okstate.edu
shoreline.edu
tbu.edu
tiasnimbas.edu
uaa.edu
usnwc.edu
uwm.edu
uwstout.edu
waketech.edu

There are also 7 zones with DLV records published at ISC's DLV registry, but this set is disjoint with the set that doesn't have DS records:

bucknell.edu
internet2.edu
k-state.edu
ksu.edu
ualr.edu
ucaid.edu
ucr.edu

-- Shumon Huque

New DNS Top Level Domains

If you follow DNS news, you may know that ICANN has put in place a program to introduce many new generic top level domains (GTLD) into the DNS. I haven't been a fan. ICANN says there is market demand for GTLD expansion (perhaps), and that it allows innovation in the DNS ecosystem (how?). It probably will have an effect of diluting the entrenched market power of the big TLD operators (.com, .org etc), which may be a good thing. But the system may end up being primarily a significant financial windfall for ICANN. Even Esther Dyson (original ICANN chair) has spoken out against the program.

There appear to be some trademark protection mechanisms built in to the new system. But it seems clear that many organizations will rush to defensively register their names under some of the new TLDs. Strictly speaking, DNS domain names have no intended or actual relation to trademarks, but we have to deal with the real world. My university's upper administration has already contacted the IT department to discuss the topic. A while back, we defensively registered "upenn.xxx" to protect against possible reputational damage (and no, I wasn't involved in that decision).

On a more technical note, one interesting and welcome feature of the new GTLDs, is that they must be deployed with DNSSEC. This should significantly increase the proportion of signed top level domains in the DNS. My dnsstat DNS monitoring site has been monitoring the TLDs for a while now, and I just updated it with the latest list of TLDs.

    http://www.huque.com/app/dnsstat/category/tld/

Since late August, 32 new TLDs have been introduced, 27 normal GTLDs, 5 IDN (Internationalized domains) TLDs. But 11 IDN TLDs have also disappeared. That's a net gain of 21 TLDs, bringing the total count to 339.

Some DNSSEC specific stats: 143 (or 42.2%) of the TLDs are signed with DNSSEC. Here's a breakdown of type key and zone signing algorithms in use for the signed TLDs:

Key Signing Keys (KSK):
RSASHA256 (8) = 119 (63.0%)
RSASHA512 (10) = 6 (3.2%)
RSASHA1 (5) = 16 (8.5%)
RSASHA1-NSEC3-SHA1 (7) = 48 (25.4%)

Zone Signing Keys (ZSK):
RSASHA256 (8) = 133 (62.4%)
RSASHA512 (10) = 8 (3.8%)
RSASHA1 (5) = 17 (8.0%)
RSASHA1-NSEC3-SHA1 (7) = 55 (25.8%)

Note: new GTLDs continue to be added, so the numbers in this article might be out of date soon.

Here are the added TLDs so far (as of November 20th 2013):

+ bike
+ camera
+ clothing
+ construction
+ contractors
+ diamonds
+ directory
+ enterprises
+ equipment
+ estate
+ gallery
+ graphics
+ guru
+ holdings
+ kitchen
+ land
+ lighting
+ photography
+ plumbing
+ sexy
+ singles
+ tattoo
+ technology
+ tips
+ today
+ ventures
+ voyage

Here are the new IDN TLDs:

+ xn--80asehdb
+ xn--80aswg
+ xn--mgba3a4f16a
+ xn--ngbc5azd
+ xn--unup4y

Here are the deleted IDN TLDs:

- xn--0zwm56d
- xn--11b5bs3a9aj6g
- xn--80akhbyknj4f
- xn--9t4b11yi5a
- xn--deba0ad
- xn--g6w251d
- xn--hgbk6aj7f53bba
- xn--hlcj6aya9esc7a
- xn--jxalpdlp
- xn--kgbechtv
- xn--zckzah

Note: one IDN TLD (xn--l1acc) has had a severely busted DNSSEC deployment for a while. My monitoring system detects that its DS records in the root of the DNS do not match any DNSKEY records in the zone, and furthermore, the signatures on the DNSKEY records have expired. I hope they get their act together soon.

--Shumon Huque

TLSA Record Generator

Last year I wrote a blog article on DNSSEC and Certificates. Occasionally I get questions from folks who've tried to follow my instructions to create the content of TLSA records, but have failed because they are using a version of openssl that is too old to generate SHA-256 and SHA-512 hashes.

I've written a small web application to help generate TLSA records. I hope this is of use to some folks:

        https://www.huque.com/bin/gen_tlsa

(I apologize in advance for my rather primitive webpage design skills!)

Here is a screenshot of it in action to generate the TLSA record for my own website:

And the resulting TLSA record that was generated:



-- Shumon Huque

IPv6 and DNSSEC at LISA in DC

Once again, I'm teaching a couple of courses at the USENIX LISA conference, this time in Washington, DC. The first is a half day course on DNSSEC on Sunday, November 3rd. And the second is a full day course on IPv6 on Monday, November 4th. I hope to see you there if you're interested in learning or talking about these topics. Early bird registration discounts for the conference end on October 22nd (sorry for the short notice).

Matt Simmons (@standaloneSA) interviewed me about both classes: DNSSEC and IPv6.

-- Shumon Huque

Singh Nanotechnology Center

The grand opening of Penn's new Singh Center for Nanotechnology is tomorrow (Friday, October 4th). Computing directors in my department got to see it a week early when we held a special meeting in the Forum room.

This post contains a few photos from my visit - of the building exterior, hallways, and conference rooms. The labs weren't open yet. The full set can be found at Google Plus.

The Nanotech center has been featured in some recent articles:

* Philadelphia Inquirer - "Changing Skyline - Inga Saffron"
* The Daily Pennsylvanian
* Philadelphia Inquirer - "Penn going all out for small science"

Building exterior, from Walnut Street close to the 33rd Street intersection, looking east:

This cantilevered section houses a conference room - the Glandt Forum room.

The Forum room, where our meeting was held.

At the edge of the cantilevered section.

Looking westward along Walnut St towards the rest of campus. Directly in front (right side) is the Laboratory for Research on the Structure of Matter (LRSM). To the left is the David Rittenhouse Lab.

View from the green rooftop terrace.

Rooftop terrace.

Hallways.

"We Lost" sculpture by Tony Smith.

DNSSEC and Certificates

DNSSEC is a system to verify the authenticity of DNS data using public key signatures. With increasing deployment of DNSSEC comes the possibility of applications using the DNS to store and retrieve TLS/SSL certificates in an authenticated manner. And possibly obviating the need for public/global certification authorities (CA), and empowering domain owners to issue their own certificates instead.

For those of you who know me a little better, you're probably aware that I've been griping about the inherent deficiencies of the public CA model for years. Certainly my colleagues at Penn have been subjected to many a diatribe on this topic, and occasionally I've done so more publicly (no pun intended).

In brief, the problems are that applications (such as web browsers) are pre-configured to trust a very large number of global CAs. These CAs have absolutely no constraints on the namespace for which they can issue certificates. Any of them can issue a certificate for any of your services (whether you have a business relationship with them or not). And thus, we have what is tantamount to least common denominator security - the collective security of the system is equivalent to the CA with the weakest security and laxest policies. It gets worse - many of these CAs in turn issue subordinate CA certificates for their customers, again with no namespace constraints.

Another issue is that most of these CAs are capable only of issuing certificates with the most basic capabilities. If you need to deploy a certificate with some more exotic feature (eg. an alternate name form or extension), you're basically out of luck.

Incidentally the PKIX specifications do have the capability of constraining the namespace (see RFC 5280 Section 4.2.1.10: Name Constraints extension), but deploying it in the existing public CA model will require a huge amount of work (both technical and political), including deployment of a hierarchical global CA architecture, as well as enhancing client software to validate name constraints (which practically none do today).

Introducing DANE and TLSA

Recent work in the IETF holds some promise to improve things. RFC 6698 (DANE) defines the new DNS record type TLSA, which holds what is called Certificate Association data. In conjunction with DNSSEC signatures, this will permit better and more secure ways for applications to authenticate certificates. The record can be used in 4 different ways (defined by a "Usage" field):

• (Usage 0) Specify authorized public CAs - this can prevent certificates signed by CAs that you didn't explicitly specify from being trusted by client software.
• (Usage 1) Specify which specific server certificate can be trusted. The public CA certificate validation chain all the way to the server certificate must still be validated.
• (Usage 2) Authorize a new non-public CA (eg. a CA that the domain owner operates itself)
• (Usage 3) Directly specify the server certificate in the DNS - no certificate chain from a public CA needs to be used. This is called a "Domain issued certificate"

If you're looking for a way to not use public CAs, Usage 3 is probably the one for you.

The owner name of the TLSA record defines the port, transport protocol, and server host name. Here's an example for the HTTPS service (port 443, TCP) at www.example.com:

  _443._tcp.www.example.com. IN TLSA ( 0 0 1
                                d2abde240d7cd3ee6b4b28c54df034b9
                                7983a1d16e8a410e4561cb106618e971 )

The right hand side ("rdata" or resource data) of the TLSA record contains 3 numbers and the raw certificate data in hexadecimal. The 3 numbers are the usage field (previously described), the selector field (which says whether the certificate data takes into account the full certificate or only the subject's public key), and the matching-type field (which says whether the certificate data is the full content that the selector field specifies, or whether it is a cryptographic hash of it). See RFC 6698 for a more detailed description.

Deploying a TLSA record for my website

After seeing several prominent mentions of DANE at this week's ICANN'45 DNSSEC workshop, (see Dan York and Paul Wouters' presentations for example) I felt motivated to install a TLSA record for my website.

Now billions of users with TLSA capable web browsers and DNSSEC validating resolvers will be able to securely reach my website! Okay, that's a slight exaggeration, but perhaps one day, in the not too distant future!

I wanted to see if I could do this using standard tools already available on most UNIX systems. It wasn't too hard. My site already has an SSL certificate issued by StartCom Ltd, but I want to specify that the server certificate can also be authenticated directly without a CA (TLSA Usage type 3). I'll also use a SHA256 hash (match-type 1) of the full certificate (selector 0) as the certificate association data (so the 3 numbers in the rdata will be 3 0 1).

OpenSSL can be used to easily generate the certificate association data portion. We first convert my PEM encoded certificate (in file huque.crt) into the binary DER encoding (openssl x509 -outform DER) and then pipe the output to "openssl sha256". This generates the 256-bit SHA hash represented as a string of 64 hex digits (each hex digit is 4 bits):

  $ openssl x509 -in huque.crt -outform DER | openssl sha256
  (stdin)= 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

The resulting TLSA DNS record will thus look like:

  _443._tcp.www.huque.com. IN TLSA 3 0 1 ( 
       8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1 )

One quick nsupdate command  (details omitted) and the record was installed in my DNSSEC signed zone. We can check that the record (and its signature) is present with dig:

$ dig +dnssec +noall +answer +multi _443._tcp.www.huque.com. TLSA

_443._tcp.www.huque.com. 893 IN TLSA 3 0 1 (
                                8CB0FC6C527506A053F4F14C8464BEBBD6DEDE2738D1
                                1468DD953D7D6A3021F1 )
_443._tcp.www.huque.com. 893 IN RRSIG TLSA 8 5 900 (
                                20121117202722 20121018192722 14703 huque.com.
                                OJ4b/O7J+Fh3KVDGG8nH9X5dRSXgl3j7/S/PbB1RczcY
                                fYxdu5C9xZSALCz0MgVFW6Kcne74ou5R/Wd+CDKm7mYY
                                Ga28MrtE1boNLuOTa6kOpFcNjW+UYnMFQuc6S8zhU1G7
                                LH0n3TbM3rJS0wH0u6J4NgtiowZS2VlkwPez3D8= )

(If you're using an older version of BIND/dig that doesn't understand the TLSA record type, you can replace TLSA in the command line above with TYPE52.)

Note: the huque.com zone does not currently have a secure delegation from the .COM TLD. This is mainly because my current DNS registrar (Network Solutions) is incapable of processing DS records, sigh, and I've been too lazy to switch. In the meantime, it has a DLV record published in the DLV registry operated by ISC, so any validating resolver configured to use that registry (and many are) should be able to authenticate records in huque.com.

Not surprisingly, there are already tools out there that make it easy to generate TLSA records. Paul Wouter's hash-slinger package can do it (supposedly integrated into newer Fedora Linux releases). With the "tlsa" program included in that package, we can do this via:

  $ tlsa --create --output rfc --usage 3 --certificate huque.crt www.huque.com
  _443._tcp.www.huque.com. IN TLSA 3 0 1
       8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Obviously DANE needs to be widely adopted by the Internet community for it to be successful, and it's not yet clear how long that will take. And obviously browsers and other application sofware will have to evolve to make use of TLSA records. But preliminary work appears to already be in progress - there are a few browser extensions that try to validate TLSA records for HTTPS websites. I plan to look into those next ..

Incidentally, I'm teaching a half-day DNS and DNSSEC course at the upcoming USENIX LISA conference in San Diego, December 9th-14th. I hope to talk more about DANE and TLSA there.

Shumon Huque

-------------------------------------------------------------------------
Updates:

* (June 2013)  I thought I'd mention I have a small program that generates the resource data for a TLSA record from a certificate file and given parameters. You can find it on github: tlsa_rdata ]

* (September 2013) Randy Bush pointed out to me that OpenSSL versions on a number of operating systems like current versions of Mac OS X and FreeBSD are too old to support sha256. It appears that the sha256 digest command in OpenSSL is fairly new, appearing in version 1.0.1, which is newer than many current operating system distributions provide.  So I'll provide a few alternatives to "openssl 256" for them:

On Mac OS X, you can use shasum (/usr/sbin/shasum):
  openssl x509 -in certfile.crt -outform DER | shasum -a 256
On FreeBSD, you can use sha256 (/sbin/sha256):
  openssl x509 -in certfile.crt -outform DER | sha256
On Redhat Linux, you can use sha256sum (/usr/sbin/sha256sum):
  openssl x509 -in certfile.crt -outform DER | sha256sum

Or you can use Python's hashlib module (going back as far as Python 2.5). I've put up a small program on github called dgst that provides a simple command line utility to generate various cryptographic hashes of files or whatever is fed on standard input:

    https://github.com/shuque/dgst