DNSSEC Part II: the Implementation

Kyle Rankin — Tue, 08 Apr 2014 21:11:00 +0000

This article is the second in a series on DNSSEC. In the first one, I gave a general overview of DNSSEC concepts to lay the foundation for this article, which discusses how to enable DNSSEC for a zone using BIND. If you want to deploy DNSSEC but aren't sure what I mean when I say KSK, ZSK, DLV or DS record, you may want to go back to Part I to refresh yourself on the concepts, because in this article, I'm going to dive right in to implementation.

Adding DNSSEC to a zone using BIND involves a few extra steps on top of what you normally would do to configure BIND as a master for your zone. First, you will need to generate a Key-Signing Key (KSK) and Zone-Signing Key (ZSK), then update the zone's config and sign it with the keys. Finally, you will reconfigure BIND itself to support DNSSEC. After that, your zone should be ready, so if your registrar supports DNSSEC, you can update it or otherwise use DLV with a provider like dlv.isc.org. Now, let's look at the steps in more detail using my greenfly.org zone as an example.

Make the Keys

The first step is to generate the KSK and ZSK for your zone. As I mentioned in my previous article, the KSK is used only to sign ZSKs in the zone and to provide a signature for the zone's parent to sign, while ZSKs sign the records in each zone. Having separate keys also allows you to create a stronger KSK and have a weaker ZSK that you can rotate out each month. So first, let's create a KSK for greenfly.org using dnssec-keygen:


$ cd /etc/bind/
$ dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK greenfly.org

By default, the dnssec-keygen command dumps the generated keys in the current directory, so change to the directory in which you store your BIND configuration. The -a and -b arguments set the algorithm (RSASHA1) and key size (2048 bit), while the -n option tells dnssec-keygen what kind of key it is creating (a ZONE key). You also can use dnssec-keygen to generate keys for DDNS and other BIND features, so you need to be sure to specify this is for a zone. I also added a -f KSK option that tells dnssec-keygen to set a bit that denotes this key as a KSK instead of a ZSK. Finally, I specified the name of the zone this key is for: greenfly.org. This command should create two files: a .key file, which is the public key published in the zone, and a .private file, which is the private key and should be treated like a secret. These files start with a K, then the name of the zone, and then a series of numbers (the latter of which is randomly generated), so in my case, it created two files: Kgreenfly.org.+005+10849.key and Kgreenfly.org.+005+10849.private.

Go to Full Article

DNSSEC Part I: the Concepts

Kyle Rankin — Mon, 24 Feb 2014 18:42:29 +0000

by Kyle Rankin

Like IPv6, DNSSEC is one of those great forward-looking protocols that unfortunately hasn't seen wide adoption yet. Before I implemented it myself, I could see why. Although some people think BIND itself is difficult to set up, DNSSEC adds an extra layer of keys, key management and a slew of additional DNS records. One day I decided to set up DNSSEC on a personal zone to familiarize myself with the concepts and process, and it turns out that the implementation isn't all that bad once you grasp a few concepts. In this article, I cover some of the general concepts, and in my next article, I'll describe the steps for using DNSSEC on your own zone.

How DNS Works

It can be difficult to understand how DNSSEC works if you don't completely grasp how DNS itself works. Really, I could spend a whole article just talking about how DNS works, but for the purposes of this article, here's a very high-level trace of a typical uncached DNS query that resolves a domain of mine: www.greenfly.org. When you type a URL in a Web browser and press Enter, behind the scenes, the OS starts a process to convert that hostname into an IP address. Although some people run DNS caching services on their personal computers, for the most part, you rely on an external DNS server you've either configured by hand or via DHCP. When your OS needs to convert a hostname into an IP, it sends a DNS query to a name server defined in /etc/resolv.conf (these days, if this file is managed by resolvconf, the real name servers can be trickier to track down). This starts what's known as a recursive query, as this remote DNS server acts on your behalf to talk to any other DNS servers it needs to contact to resolve your hostname to an IP.

In the case of resolving www.greenfly.org, the recursive DNS server starts by sending a query to one of the 13 root DNS servers on the Internet (192.33.4.12), asking for the IP for www.greenfly.org. The root name servers reply that they don't know that information, but the name servers for .org might know, and here are their names and IP addresses. Next, the recursive DNS server sends a query to one of the .org name servers (199.19.54.1), asking the same question. The .org name server replies that it also doesn't know the answer, but the name servers for greenfly.org might know, and here are their names and IP addresses. Finally, the recursive DNS server asks one of the greenfly.org name servers (75.101.46.232) and gets back the answer that www.greenfly.org is at 64.142.56.172.

If you are curious how this might work for a domain you own, just use the dig command with the +trace option. Here's example output for www.greenfly.org:

Go to Full Article