DNSSEC is one of those things that have been on the “I should poke at that sometime” list, but today I decided to actually get in and play around with it. Turns out it’s pretty trivially easy to setup, but I got bitten by a few “gotchas” during testing, that I thought worthwhile to document. Since I like to explain things, a lot of this article isn’t “how to” so much as “how does”.
Configuring The Resolver
First off, you need a resolver1 that you can trust, and which
implements DNSSEC validation. In theory, you could use your ISP’s
resolvers (if they’re DNSSEC-enabled), or even Google’s public resolvers
184.108.40.206), but it’s really not recommended – how much do
you trust those, really? More importantly, how much do you trust the
network path between them and you? Frankly, running a local on-host caching
resolver is trivial, consumes next-to-no resources, and is highly
recommended. It’s what I did.
unbound, finally casting free the venerable
dnscache, which has
served me well for many years. I chose unbound because it fits the “do one
small thing, and do it well” philosophy that I cherish (unlike BIND), and
because it’s what all the cool kids appear to be using these days.
Installing it was as simple as
apt-get install unbound – it’s available
in pretty much every distro, I believe.
Out of the box, unbound in Debian wheezy comes configured for DNSSEC
validation. Other methods of installation might not be so amenable, so just
make sure your
unbound.conf liiks like this, so that DNSSEC is enabled:
server: auto-trust-anchor-file: "/var/lib/unbound/root.key" val-log-level: 2
val-log-level line isn’t strictly required, but I found it useful to
have unbound log info on validation failures to syslog. Season to taste.
You also have to configure your system to actually use your new, shiny
local resolver. Editing
/etc/resolv.conf would, in an ideal world, work
Just Fine, but between Magical Unhelpful Pixies (I’m looking at you,
NetworkManager) and DHCP, it often isn’t that easy. Ultimately, though, you
should configure your system so that the only resolver in
/etc/resolv.conf is always
127.0.0.1. Anything else is a security hole
waiting to happen. If you’re using DHCP and a recent version of ISC
supersede domain-name-servers 127.0.0.1; to
dhclient.conf should do the needful.
Weighing the (Trust) Anchor
Whatever local resolver you choose, you need to tell it about “trust anchors”. This is a key (or keys) which are trusted to sign all the other data that the resolver will find. Like the rest of the DNS, DNSSEC is hierarchical, and you need to know who to “start with” before you can start.
To resolve a name using DNS, you ask the “root servers” for the answer to a
question (say, “what is the address of
www.example.com?”). The root
server doesn’t know the answer, but it knows who to ask, and it tells you
where to go (typically, “go ask the DNS servers for
.com, which are X, Y,
and Z”). Then you ask those servers, and they probably don’t know, but
they know who to ask, and they tell you to go ask those servers. This
continues until you finally get a server which says, “oh, yes, I know the
answer to that!” and hands over the information you’re after.
In DNSSEC, you get digital signatures that prove that the answers you get
from each DNS server you ask are legit, and not forged. So when you ask the
root servers, “what is the address of
www.example.com?”, they answer, “I
don’t know, but go ask DNS servers at addresses X, Y, and Z – and by the
way, you can trust this answer is legit because here’s this signature you
can check”. To verify a signature is legit, you need to know that the key
used to make the signature is trustworthy, and it wasn’t just any ol’ key
that made it – similar to how an ink scribble on a page doesn’t mean
anything unless you know what the signature you’re looking at should look
DNSSEC has two ways to make sure you know who to trust. Firstly, those “trust
anchors” I mentioned three paragraphs ago. These are the keys that the root
servers use to sign the responses they send out. You tell unbound (or your
local DNSSEC-enabled resolver of choice), “if you see a signature provided
by this trust anchor key, you can trust it to be legit”. The second way to
trust is key is to have someone you already trust say, “oh, you can trust
this key, too”. This is done by providing more data in the answer that
you get from the root servers. So the full answer you get from the root
servers when you ask, “what is the address of
www.example.com?” looks like
I don’t know, but you should ask the DNS servers at addresses X, Y, and Z. You can trust their answers because they’ll sign their responses with key K. Finally, you can trust that I’m legit because of this signature I’m providing you, generated from key T.
Assuming that T is the trust-anchor key you’ve already told unbound to
trust, it can then trust all of the information it got from that first
question. When it then goes to DNS server X and asks, “Hey, do you know
the address of
www.example.com?”, that server can send back its own
Gee, shucks, I don’t know, but DNS servers at P and Q can help you. You can trust them because they’ll sign responses with key S. And just to show you I’m on the level, check out this nifty signature I made, signed with key K.
Since a server we trust told us to trust key K, and then we got a response signed by key K that told us to trust key S, when we then go and ask server P and get a response signed by S, we’re still demonstrably secure. Neat setup, right?
Anyway, now you know all about trust anchors. How do you set it up? For unbound, it’s capable of “priming” the trust anchor itself. It does this by retrieving a copy of the trust anchor from [a well-known HTTPS URL]((https://data.iana.org/root-anchors/root-anchors.xml), which provides a reasonable measure of security – the trust anchor file should be safe as long as that HTTPS server is trustworthy. For the properly paranoid, you should determine an alternate means of verifying that you have the correct root key (a web search for “DNSSEC root key attestation” would probably be a good start).
It’s always handy to know that something’s working as you expect. For something that’s important for security, that goes double. So, how do you test that your DNSSEC-capable resolver is, indeed, working as designed?
Well, firstly, you can test that the resolver, by itself, is working. This is simple: do a query for a zone known to have broken DNSSEC. Thankfully, some nice people (Comcast, specifically) have already set this up. You can test a resolver for DNSSEC-correctness with this command:
dig @127.0.0.1 www.dnssec-failed.org
dig gives you back an IP address, something is broken. The
correct, “my DNSSEC works!” response should be a
That’s all well and good, but having a resolver that works isn’t much good if nothing’s actually using it. Your system configuration has probably got some other resolvers configured into it (such as those provided by a DHCP server), and you’ll want to make sure those aren’t getting used2. The trivial test is to visit http://www.dnssec-failed.org in your browser. If that comes back with a page, then something’s still wrong.
A more user-friendly test of your DNSSEC configuration is provided by http://dnssectest.sidnlabs.nl/test.php, which will display a page either way, and give you a tick or a cross depending on whether you’re DNSSEC-enabled or not.
One thing to be wary of when you’re doing browser tests is caching. I spent far too long trying to work out why “unbound wasn’t working”, when in actual fact it was working fine, it’s just that both my browser and local caching proxy (squid) were caching DNS requests3. So, even after I’d correctly setup unbound, visiting the test sites was providing me with erroneous results.
Fixing up the browser was simple enough. In Chromium, visiting
chrome://net-internals#dns will show you what’s being cached, what
resolv.conf settings are being used, and allow you to clear the browser’s
Squid was similarly simple, although it took me a while to figure out that it was causing me grief (software that “just works”, being so rare, tends to slip your mind, and so I often forget that squid is actually doing me good). Restarting squid has the appropriate result (clears the DNS cache), but in the end I decided that having another layer of caching wasn’t going to help significantly when I’ve got an on-host DNS cache already, in unbound. So, I just turned the knobs for DNS caching in squid right down:
negative_dns_ttl 1 second positive_dns_ttl 1 second
And voila! All was well.
DNSSEC is cool. It’s easy to get going with, and over time it will provide more and more practical benefits (I am a DANE fanboi). Get started with it now, and you’ll be ahead of the curve.
A “resolver” is a program which takes a name, does all the DNS queries required to get the data associated with that name, and return it to whoever wanted to know. This can be a library which links to a client application, or it can be a separate program which receives DNS requests itself.
There are usually both types of resolvers in use for a typical Linux system to resolve names. On every machine, in every program, there is the so-called “stub resolver”, which is part of
libc, and does nothing except create DNS requests and send them to the addresses listed in
resolv.conf. Also present, although not always running on every machine (typically your ISP or network admin has some running for everyone to share) are one or more “recursive resolvers”, which are separate programs which take DNS requests, do all of the queries themselves, and return the result to the stub resolver for presentation to the client program which made the request in the first place.
You will see this material again. ↩
You can configure dhclient to use your local resolver instead of the DHCP-provided ones by simply setting:
supersede domain-name-servers 127.0.0.1;
It also didn’t help that I hadn’t correctly knobbled
dhclientthe first time around, and so even when I thought I was only resolving against my local unbound server, it was still actually using the DHCP-provided resolvers… ↩