Adventures with DNSSEC Part 2: Signing my Domain

[Update 21 August 2016: The dnssec-tools package is no longer available in the Debian “jessie” release. Another blog post describes how I dealt with that.]

As I mentioned in a previous article, I have been meaning to deploy DNS security extensions (DNSSEC) on my personal domain for some time. Today I completed the biggest piece of that: signing my domain and getting my domain registrar to publish Delegation Signer (DS) records to allow others to verify the validity of the signatures.

For a couple of years now, I have been waiting for my domain registrar, name.com, to support DNSSEC for the .net top-level domain. I waited and hoped that the new ICANN registrar accreditation agreement, effective this past January, would cause them to provide this support.  But since they seem instead to be much more interested in selling domain registrations under new top-level domains like .ninja, I made the preparations to sign with DNSSEC and expected to change registrars.

Before beginning, I’ll describe my DNS structure. I operate my own primary/master DNS server using BIND 9 on a virtual private server running Debian Linux. This server is also a slave DNS server for a few domains operated by friends. For my slave servers, I have been using a free service provided by Hurricane Electric to its users and participants in its IPv6 certifications (I am one of the latter).

As with my recent deployment of DNSSEC signature checking, a tutorial on HowToForge provided most of the help I needed. With the procedures given in that tutorial, I was able to generate the necessary keys and sign my zone.  I changed my BIND configuration to refer to the signed version of my zone file, and everything seemed to work. I tested my name server using the ‘dig +dnssec’ command, and saw the Resource Record Signature (RRSIG) record that accompanies each resource record returned.

On a hunch, I tried querying one of my Hurricane Electric slave servers. No RRSIG record. I logged into their administrative console to look at the zone file they have, and the RRSIG records were there; they just weren’t being returned in response to queries.

I asked on one of their online forums, and they confirmed that they don’t provide DNSSEC support. I can’t complain; this is a free service, but I was a bit surprised, considering the leadership position HE has taken on IPv6 deployment, that they weren’t further along on DNSSEC. But I thank them for their service and the quick and straightforward response to my question.

So I leased an additional Debian virtual private server (from a different provider, to provide resilience); at $5/month, it won’t break the bank. I set up BIND and a firewall on that server, and made it the secondary/slave for my domain. Of course, I had to ask my registrar to change the DNS “glue” records to allow this new server to be found. After the old name service records timed out, all of my name servers began returning DNSSEC-signed responses.

Step 5 in the tutorial showed how to adjust the trust chain in a resolving DNS server to allow me to verify that the zone was properly signed, prior to actually submitting the DS records to the registrar. This is potentially important to test because if the domain is incorrectly signed, DNSSEC-aware caching servers and resolvers will return SERVFAIL errors, making the domain unresolvable. So I tried this test, but could never get the “ad” (authentic data) flag in my results. I’m still not sure why; it may have been because I used one of my authoritative name servers for this test, rather than setting up a third machine running BIND. All of my other testing had been successful, however, so I decided to go ahead and publish my DS records since my domain is small and only affects me and my family. I would not take that risk on a corporate domain!

As a result of the signing process, a file (dsset-<domain name>) is created on the primary name server containing the DS records for the zone. It is these records, when published (and signed) in the zone of the next-higher domain (.net in my case), that provide a secure linkage between my domain and the rest of the DNS infrastrusture. The process for getting this publication done depends on the domain registrar being used.

As I said, name.com does not support DNSSEC for .net domains. But I happened to see an obscure link at the bottom of the “Nameservers” tab for my domain that said I could create registry-level DNSSEC records for my domain on the DNSSEC Management Page. So I clicked on it. And waited about 1 and a half minutes…

When the page did display, it said, “No supported DNSKEY records were found in DNS. This usually means that your name servers are not properly configured for DNSSEC.” But I checked again, and the DNSKEY records were indeed there so I ignored the warning message.  I viewed the contents of the dsset file and pasted the key tag, algorithm, digest type, and digest into the window. After pressing Submit and another significant delay, the first DS record (digest type 1, SHA-1) was published. But the web page wouldn’t accept the second DS record (digest type 2, SHA-256). Eventually I figured out that an embedded space in the fingerprint was the problem, and the record was accepted successfully.

Given name.com’s stated lack of support for registering DS records in .net, I didn’t expect to get this far. I probably will, in the near future, switch to another registrar that officially supports DNSSEC (as well as providing two-factor authentication for domain management). But starting today, I’m doing what Jeff Moss referred to at Trustycon as protecting others: my domain is DNSSEC-signed.

Image “Desk and quill pens, Carpenter’s Hall” by Flickr user Jim Bullard used under Creative Commons CC-BY-2.0 license.