DNSSEC: Inevitable, but not unwelcome

I'm a big fan of up-and-coming technology, even if it seems like it's only on the horizon. For instance, I'm a firm believer that IPv6 is necessary to learn, and I am unalterably convinced that virtualization is not going away.

When I looked at the course descriptions for this year's LISA'10 Training Schedule, I jumped at the chance to interview Alan Clegg. Why? Because he is teaching a DNSSEC tutorial on Sunday morning.

I've got to admit, DNSSEC kind of sneeked up on me. When the .org top level domain (TLD) was signed, I took notice, and I feel like I'm behind. I doubt I'm the only one in this particular boat.

Fortunately, Alan is here to help us. I got a chance to ask him some questions that I (and some of my twitter followers) had, and he was kind enough to respond.


Matt Simmons: Everyone uses and is at least passingly familiar with how DNS works. What is DNSSEC, and what is the problem it's trying to solve?

Alan Clegg: DNSSEC adds digital signatures to the existing DNS data that queries return. It solves "cache poisoning" issues by allowing validating recursive servers (and applications written to be DNSSEC aware) to insure that data provided to clients has not been modified since it left the authoritative server.

A couple of other interesting things that happen to fall out of "provably unchanged" data is the ability to do cool things like putting other information into DNS that was previously transited using other technologies.

Consider SSH fingerprints that are currently compared to notes jotted down on sticky pads (if we are lucky). There is already an "SSHFP" resource record type that openSSH will use to disallow man-in-the-middle attacks against ssh connections.

Another data type that is being discussed is certificate data... suddenly, a "self signed" certificate has extra validity if there is also a fingerprint (or perhaps the entire certificate) in a DNSSEC signed zone.


MS: From the recent news, it sounds like more and more TLDs are implementing DNSSEC. Do you think this trend is going to accelerate?

AC: There will always be holdouts, but I think that the next generation of software (and solutions) from vendors will make maintenance of DNSSEC enabled zones no harder than maintenance of non-DNSSEC zones, so there will be no reason to delay deploying DNSSEC.


MS: After the transition is complete, will there be any effect on the average internet user?

AC: I hope that security is increased... however, there are interesting issues with ISPs that are currently making money from NXDOMAIN rewriting (sending users to "we know you mistyped the domain, so look at our page that someone is paying to put in front of you").

Providers that are willing to break the responses that they are giving to their customers now may or may not be willing to lose the revenue stream that they are currently getting just to provide "better security".

To actually answer your question, I'll have to respond with "maybe".


MS: From the course description, you were involved with the signing and deployment of the Portuguese TLD. Can you tell me a little more about that?

AC: Yes. Show up at tutorial S3 and I'll tell you lots about it, provide examples and maybe even show some pictures...


MS: What are some of the advantages of adding an HSM to a DNSSEC installation?

AC: It all boils down to this:

http://www.xkcd.com/538/

If you have a zone that is important enough that physical harm to employees would not be beyond the scope of a person trying to gain access to the keys, then you really want to look into an HSM.


MS: What are the limitations of DNSSEC and where does it fall short?

AC: DNSSEC does not deal with a number of other potential vulnerabilities in the DNS transport including dynamic updates and master to slave zone transfers. These are dealt with with another technology (TSIG).

DNSSEC does introduce a significant impact on the size of responses to DNS queries. When you consider that a query for "www.isc.org" (a signed RRset) produces 276 bytes (including authoritative & additional sections [your mileage may vary]) and the same query requesting the associated DNSSEC resource record signatures blossoms into 1623 bytes, you can see that there is a bit of an increase.

There are other issues with (ancient) devices that insist on 512 byte DNS packets, but if you are still running firewall type devices that doesn't understand EDNS0, you need to upgrade. EDNS0 has been a standard since 1999, after all...


MS: Is there a type of organization that is the poster child for DNSSEC, or that would benefit the most from taking these steps?

AC: People have said that I'm a poster child for a number of things, and I have ~40 zones that are all DNSSEC signed, so I'm thinking that the bar on this one is pretty low. :)

As I said above, the new tools that are becoming available will make DNSSEC deployment just as easy as the deployment of "non-DNSSEC" zones... it's going to be everywhere.


MS: What sorts of things should an organization do, or have in place before considering switching to DNSSEC?

AC: Today, a good understanding of how DNSSEC works is pretty important for those deploying because the tools to "completely automate" the process
just aren't there yet. Lots of people are working on "one-click" DNSSEC deployment, and once there, I'm not sure who wouldn't want to deploy.


MS: Do you have any tips for monitoring DNSSEC for proper operation?

AC: Just fire it up. When everyone complains that your zone has vanished in a flurry of SERVFAIL messages, then you know you have a problem.

Seriously, DNSSEC is (as I've probably said too many times already) getting much better at "self-healing" if deployed with the right tools.

I am the primary instructor for the ISC DNS/DNSSEC classes and have discovered that as BIND has matured in the DNSSEC arena, it has become harder and harder for me to provide 'broken' zones that the students in class are supposed to be debugging.

Monitoring services are in the works that will actually test DNSSEC remotely, but at this moment, I'm not sure of one that you can buy off-the-shelf.


MS: In a sentence, what is the single best reason for attending your class at LISA10?

AC: As you can tell from the answers above, I can't say anything in one sentence, but I'll try...

DNSSEC is coming, ready or not. If you want to be an early adopter or are required to sign your zones, I'm going to provide what you
need to actually get it done.

Ok, two sentences.


I want to thank Alan very much for his time. You can catch his class on Sunday morning at LISA'10 in San Jose, California. If you haven't yet, register today!

Comments

[...] got lucky enough to be able to interview Alan Clegg, who’s teaching a class on DNSSEC at LISA’10 this [...]

0 likes
0 dislikes