DNSSEC Mastery

Securing the Domain Name System with BIND

by Michael W Lucas

Tilted Windmill Press

Praise for other books by Michael W Lucas

SSH Mastery

“…SSH Mastery is a title that Unix users and system administrators like myself will want to keep within reach…” — Peter Hansteen, author of The Book of PF

"This stripping-down of the usual tech-book explanations gives it the immediacy of extended documentation on the Internet. Not the multipage how-to articles used as vehicles for advertising, but an in-depth presentation from someone who used OpenSSH to do a number of things, and paid attention while doing it." — DragonFlyBSD Digest

"one of those technical books that you wouldn’t keep on your bookshelf. It’s one of the books that will have its bindings bent, and many pages bookmarked sitting near the keyboard." — Steven K Hicks

Network Flow Analysis

"Combining a great writing style with lots of technical info, this book provides a learning experience that's both fun and interesting. Not too many technical books can claim that." — ;login: Magazine, October 2010

"This book is worth its weight in gold, especially if you have to deal with a shoddy ISP who always blames things on your network." — Utahcon.com

"The book is a comparatively quick read and will come in handy when troubleshooting and analyzing network problems." —Dr. Dobbs

"Network Flow Analysis is a pick for any library strong in network administration and data management. It's the first to show system administrators how to assess, analyze and debut a network using flow analysis, and comes from one of the best technical writers in the networking and security environments." — Midwest Book Review

Absolute FreeBSD, 2nd Edition

"I am happy to say that Michael Lucas is probably the best system administration author I’ve read. I am amazed that he can communicate top-notch content with a sense of humor, while not offending the reader or sounding stupid. When was the last time you could physically feel yourself getting smarter while reading a book? If you are a beginning to average FreeBSD user, Absolute FreeBSD 2nd Ed (AF2E) will deliver that sensation in spades. Even more advanced users will find plenty to enjoy.” — Richard Bejtlich, CSO, MANDIANT, and TaoSecurity blogger

“Master practitioner Lucas organizes features and functions to make sense in the development environment, and so provides aid and comfort to new users, novices, and those with significant experience alike.” — SciTech Book News, Vol. 32, No.1

“…reads well as the author has a very conversational tone, while giving you more than enough information on the topic at hand. He drops in jokes and honest truths, as if you were talking to him in a bar.” — Technology and Me Blog

Cisco Routers for the Desperate, 2nd Edition

“If only Cisco Routers for the Desperate had been on my bookshelf a few years ago! It would have definitely saved me many hours of searching for configuration help on my Cisco routers. . . . I would strongly recommend this book for both IT Professionals looking to get started with Cisco routers, as well as anyone who has to deal with a Cisco router from time to time but doesn’t have the time or technological know-how to tackle a more in-depth book on the subject.” — Blogcritics Magazine

"For me, reading this book was like having one of the guys in my company who lives and breathes Cisco sitting down with me for a day and explaining everything I need to know to handle problems or issues likely to come my way. There may be many additional things I could potentially learn about my Cisco switches, but likely few I'm likely to encounter in my environment." — IT World

"This really ought to be the book inside every Cisco Router box for the very slim chance things go goofy and help is needed 'right now.'" — MacCompanion

Absolute OpenBSD

"My current favorite is Absolute OpenBSD: Unix for the Practical Paranoid by Michael W. Lucas from No Starch Press. Anyone should be able to read this book, download OpenBSD, and get it running as quickly as possible." — Infoworld

"I recommend Absolute OpenBSD to all programmers and administrators working with the OpenBSD operating system (OS), or considering it." — UnixReview

“Absolute OpenBSD by Michael Lucas is a broad and mostly gentle introduction into the world of the OpenBSD operating system. It is sufficiently complete and deep to give someone new to OpenBSD a solid footing for doing real work and the mental tools for further exploration… The potentially boring topic of systems administration is made very readable and even fun by the light tone that Lucas uses.” — Chris Palmer, President, San Francisco OpenBSD Users Group

PGP & GPG

"...The World's first user-friendly book on email privacy...unless you're a cryptographer, or never use email, you should read this book." — Len Sassaman, CodeCon Founder

“An excellent book that shows the end-user in an easy to read and often entertaining style just about everything they need to know to effectively and properly use PGP and OpenPGP.” — Slashdot

“PGP & GPG is another excellent book by Michael Lucas. I thoroughly enjoyed his other books due to their content and style. PGP & GPG continues in this fine tradition. If you are trying to learn how to use PGP or GPG, or at least want to ensure you are using them properly, read PGP & GPG.” — TaoSecurity

Author: Michael W Lucas

Technical Review: Doug Barton

Copyediting: Aidan Julianna "AJ" Powell

Cover: Bradley K McDevitt

Print Layout: Jess McDevitt

Published by Tilted Windmill Press (http://www.tiltedwindmillpress.com) in April 2013.

For information on book distribution or translations, please contact Tilted Windmill Press (accounts@tiltedwindmillpress.com).

Copyright 2013 Michael W Lucas. All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

The information in this book is provided on an "As Is" basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor Tilted Windmill Press shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

About the Author: http://www.michaelwlucas.com/

Acknowledgments

A special thanks to my pre-publication reviewers: Henrik Lund Kramshøj, Fredrik Ludl, Jan-Piet Mens, Scott Murphy, Mike O'Connor, and Eivind Olsen. Notably, Alan Clegg and Carsten Strotmann went above and beyond in reviewing this book.

Before even starting this book, I asked poor Doug Barton of BlueCat Networks to be my lead technical reviewer. Mutual friends tell me that he's stopped moaning "Oh, the pain," and should be able to speak coherently any day now. I do hope he's learned his lesson.

Any errors in this book crept in despite the efforts of these fine folks.

As an experiment, I published in-progress versions of this manuscript on LeanPub (https://www.leanpub.com). To my surprise, many people bought the incomplete book. To my greater surprise, several people chose to overpay for it. I want to thank everyone who purchased the in-progress book. While I won't publically name and shame those who wanted to give me a tip, I will say thanks to parts of their email addresses: sven, nawfal, bonetruck, alejandro, olgamirth, axel, shori, marcus, cdjk and dikshie.

Sadly, those early drafts included plain bad advice caught by the technical reviewers. My best fans got ripped off. I hope that they, too, have learned a valuable lesson.

This book is for the folks trying to keep their name service intact despite all the miscellaneous scumbags trying to break it. For all the folks on Twitter who encouraged @mwlauthor to write it. And, of course, for She Who Must Be Obeyed.

Brief Contents

Acknowledgments

Brief Contents

Full Contents

Chapter 1: Introducing DNSSEC

Chapter 2: Cryptography and DNSSEC

Chapter 3: How DNSSEC Changes DNS

Chapter 4: DNSSEC Resolver

Chapter 5: dig and DNSSEC

Chapter 6: Securing Zone Transfers

Chapter 7: KSKs and ZSKs

Chapter 8: Signing Zones

Chapter 9: Debugging DNSSEC

Chapter 10: Key Rollover

Chapter 11: Delegations and Islands of Trust

Chapter 12: DNSSEC for Data Distribution

Afterword

Full Contents

Table of Contents

Acknowledgments

Brief Contents

Full Contents

Chapter 1: Introducing DNSSEC

DNSSEC and your Network

BIND Configuration

Recursive and Authoritative Servers

Chapter 2: Cryptography and DNSSEC

Chapter 3: How DNSSEC Changes DNS

RRset

DNSKEY

DS

DLV

RRSIG

NSEC/NSEC3

NSEC Records

NSEC3 Records

DNS Lookaside Validation

Root Private Key Security

Stealth Master

Hardware Security Module

Nothing

At the Registrar

At the DLV

Address Space Provider

Chapter 4: DNSSEC Resolver

Chapter 5: dig and DNSSEC

Chapter 6: Securing Zone Transfers

Key Creation

Add the Key to named.conf

Assign Key To Server

Let Keys Transfer Zones

Chapter 7: KSKs and ZSKs

Chapter 8: Signing Zones

auto-dnssec maintain;

Signing Dynamic Zones

Signing Static Zones

Chapter 9: Debugging DNSSEC

Key Verification

Parent Zone Verification

Verifying DLV Keys

Date and Time Verification

Logging

Chapter 10: Key Rollover

Double Signature

Pre-publish

Rollover Method Recommendations

Your Zone's Time-To-Live

Slave Expiration

Parent Zone Propagation Time

Time Formats

Setting Key Dates

Creating Rollover ZSKs

Loading Keys Into named

Checking Publication

Checking Activation

Checking Inactivation and Deletion

Create the New KSK

Notify Parent Domain

Remove Old DS Record From Parent

When To Remove Old KSK?

Chapter 11: Delegations and Islands of Trust

Delegating Subdomains

Adding DNSSec to Delegations

Choosing Private Domains

Prepare a Trust Anchor

Add a Trust Anchor to Client-Facing Servers

Testing the Island of Trust

Chapter 12: DNSSEC for Data Distribution

Create SSHFP Records

Configure The Client

CA Use Policies

Self-Signed Certificate TLSA

Generating a Certificate Hash

DNSSEC Validator

Extended DNSSEC Validator

Testing TLSA

Afterword

Chapter 1: Introducing DNSSEC

The Domain Name System (DNS) maps hostnames like www.michaelwlucas.com to IP addresses, so that computers can find Internet sites without people needing to remember strings like 192.0.2.87 or 2001:db8::ab01. It also tells devices where to find their configurations, phones where to find their servers, and distributes lots of information. DNS has been used for over 30 years, and is the most successful distributed database in history. There's just one little problem:

DNS is gullible.

That's not its fault. DNS was designed back when the fact that the Internet worked at all was a technological miracle. Nobody really tried to break the network – not even the young students who liked to poke into dusty corners and access restricted systems. DNS was a vast improvement over the centrally managed hosts file that preceded it.

But then the Internet became mainstream. The hobbyists joined, then their families, then every office worker and grandparent and bank and power plant and hospital. People began conducting business over a network never designed for it. DNS in particular was never intended for a network with actively hostile users. And now that Grandma does her banking on the Internet, those hostile users have a large financial motivation to break DNS. Injecting invalid DNS information into a network isn't as easy as it used to be, but when an intruder pulls it off it's extremely effective.

Can an organization guard against these attacks? Sure. But very few organizations have a full-time DNS administrator. DNS support is usually rolled into another team, such as network administration or server management. You folks have switches to install. Desktops to image. Servers to patch. Users to infuriate or pacify. Tasks that you think of as "your real job," of which DNS support is just a tiny inconsequential piece.

When DNS does outright fail, it has a disproportionate impact. A nameserver daemon is a tiny piece of software that can run in kilobytes of memory, but if it dies every other device on the network loses its freaking mind. People only care about DNS when it breaks, and they think of it in binary terms. Does it work? Or not? A working but corrupted DNS doesn't get any attention at all.

Attacks against your company's DNS do impact your real job, however. If an attacker can make the world think that the web site for your organization is on a server he runs, he can intercept the incoming traffic. Users who should come to your site will go to the intruder's instead. If the intruder is savvy, he will silently record the user's data and send the actual transaction on to your server for processing. You'll realize what happened only when your customers tell you that the day that they bought your widgets, someone stole their credit cards.

Additionally, DNS attacks against third parties can easily impact your organization. If an intruder attacks the DNS of a bank, one of your suppliers, or a major Internet site, the intruder can trick your users into handing over personally identifying information, financial records, confidential or secret data, or just about anything else.

But what about SSL certificates on Web sites? A SSL certificate verifies the identity of a web site, but it only works once the traffic reaches the correct site. To reach that site, the client must have correct DNS to point the browser to the right IP address. To make matters worse, certificate authorities have repeatedly issued certificates for large organizations to people utterly unrelated to the organization. Certificate problems are (usually) quickly corrected, but enforcing correct DNS data avoids a whole class of problems.

Any of these can ruin your day. You do not want to be in the meeting where the accountant asks why an auction site used his company credit card to buy authentic ceremonial head-bopping sticks from Farawayistan. Nor in the meeting where your company president wants to know how the plans for the firm's revolutionary low-lubricant propshaft went to an unscrupulous competitor rather than the usual prototype shop up the street.

The case for securing DNS boils down to: you don't have time for all that crap.

Domain Name System Security Extensions (DNSSEC) ensure the authenticity of DNS data.

What's the Problem?

What's wrong with the way DNS currently maps addresses and hostnames?

It's not enough that the various DNS servers have had a spotty security history – the protocol itself is subject to abuses. Many smart people have worked very hard to secure DNS, and have done pretty well, but successful protocol security is never an afterthought. The problems go deeper than issues with particular DNS server software suites – they exist in the underlying protocol. Intruders successfully attack DNS at the authoritative servers, the recursive servers, and the client level. To understand how this works, let's look at the DNS data set.

The basic unit of DNS organization is the zone. Many people think of a zone as a domain, such as michaelwlucas.com. A domain is a zone, but zones also include parent domains like .com, or reverse DNS zones like 2.0.192.in-addr.arpa. Zones contain records about the hosts, child zones, and major characteristics of the zone. The zone for .com contains the nameserver (NS) records for the child zone michaelwlucas.com. The root zone contains the nameserver records for its child zone .com. Once you get down to my domain, the zone contains A and AAAA records for my hosts, my mail exchanger, and so on. Everything ties to the NS records in the parent domain.

If an intruder can compromise the authoritative servers for a zone, he can enter any data he likes into the zone. Everyone will treat the information as valid – after all, it comes from the authoritative server, the final authority on the zone. This is the most effective way to compromise DNS data, but it's also one of the most difficult if the target is security conscious.

The recursive servers, such as the client-facing nameservers in a typical organization, get information by querying authoritative nameservers. These queries might be hijacked as they cross the network, giving the recursive server incorrect responses. An intruder might slip extra information into an otherwise valid answer. The intruder has any number of ways to taint the data in a recursive server, and people keep finding more.

Finally, an attacker can interpose themselves between the client and the recursive nameserver to feed the client false information, or taint the client's information directly on the client.

DNSSEC protects you from all but the most determined and technologically savvy of these attacks.

How DNSSEC protects you

DNSSEC retains the core design of DNS, but adds cryptographic verification to prove that the information received by a client is identical to the information transmitted by the server. DNS information is largely public, so DNSSEC does nothing to ensure data confidentiality. And DNSSEC doesn't secure the underlying DNS servers – an intruder can break into a poorly secured server despite DNSSEC protecting the nameserver data. But DNSSEC provides a mechanism for a client to verify that the data that arrives is the data that the system provided, and it also helps clients to reject information signed by an intruder-created key. These features ensure that the nameserver data used by the client matches what the authoritative nameserver provided.

DNSSEC shares much in common with other security protocols such as HTTPS and PGP, except the precise encryption methods. If you're familiar with cryptographic hashes and digital signatures, the principles behind DNSSEC won't surprise you.

DNSSEC secures authoritative zone data by cryptographically signing zones, so that an intruder who wants to insert bogus data into a zone must compromise the private key as well as the authoritative server. Keeping the private key off-line, or signing the zones on a separate server and copying the zone files to the DNS server, makes compromising DNS information nearly impossible. Similarly, DNSSEC uses digital signatures to verify the integrity of a recursive server's queries. A DNSSEC-validating recursive client verifies DNS data provided by the server, and rejects answers with incorrect signatures. An intruder could still attack the desktop – after all, if you control the desktop you control the user experience – but DNSSEC eliminates one broad path of attack.

Why This Book?

DNSSEC, and the software to support it, has evolved quickly over the last ten years. If you search for tutorials on implementing DNSSEC, you'll find painfully complicated instructions from a decade ago, using obsolete software. Those instructions probably still work, sort of, but will cause you much unnecessary work. Articles and blog posts cover edge cases that don't apply any longer, or describe complicated procedures that software now handles transparently. My goal is to remove all that clutter and make DNSSEC as simple as possible. DNSSEC is still not trivial – but it's not horrible, either.

This book is a one-stop-shop to help you deploy DNSSEC, using current software and best practices. You can skip sifting the Internet for relevant documentation, and instead get back to your real job. To help keep this book short, I assume that you can resolve edge cases involving your operating system or network. Please plan time to play with your problems. DNSSEC isn't as hard as the reams of obsolete instructions make it seem, but it's not trivial.

Mind you, my recommendations come from sources such as my technical reviewers, the bind-users mailing list, and the BIND Administrator Reference Manual. Guidance on key length and algorithms comes from the National Institute of Standards and Technology's (NIST) Special Publication 800-81r1, the Secure Domain Name System (DNS) Deployment Guide, available freely on their web site. Updates from these sources supersede anything I say in this book – no, actually, they supersede anything I say anywhere.

Why Not This Book?

This book is not a complete in-depth DNSSEC tutorial. The global DNS has thousands of edges, some blunt, some sharp. If you hit an edge because your zone has one hundred fifteen views where most people have one or two, you'll need to do additional research. I'm covering the most common use cases for DNSSEC, which will suffice for 95 percent of the DNS administrators out there.

Sysadmin Background

This book is for Domain Name System administrators who want to incorporate DNSSEC into their services, and for application administrators and protocol designers who want to use DNS to reliably distribute information. I will fling around words like "zone" and "reverse DNS" and expect you to understand. I won't explain basics like A, PTR, NS, MX, and SOA resource records.

I assume you know how to install specific software on your preferred platform. Maybe you don't know how to compile BIND from source, but you can install packaged software on your operating system. Every Unix-like operating system has recent BIND packages. My reference platforms are FreeBSD and OpenBSD, but BIND behaves identically across almost all platforms. (How your operating system packages BIND might differ, however.)

The DNSSEC theory, best practices, and diagnostic guidance herein applies to all DNS server software. I use the Internet Systems Consortium's (ISC) BIND 9.9, available since January of 2012, and many of the processes in this book will not work on older versions of BIND. BIND 9.9 makes DNSSEC manageable by normal overworked sysadmins. If you want to tweet or email me to ask if this stuff works on BIND 9.8, the answer is: no. It doesn't. If your operating system doesn't yet include a BIND 9.9 package, you must build the software yourself or use a different operating system.

DNSSEC works equally well with IPv4 and IPv6. I mostly (not always) use IPv4 examples, mainly because they're shorter, but everything applies equally to IPv6.

This book is not intended as a comprehensive DNSSEC grimoire. I cover the common cases of securing the information in your forward and reverse zones, as well as a couple of case studies of ways DNS can be extended when DNSSEC is in place. I recommend best practices as per the various Internet standards. If you want to play games with cryptographic keys, if you want to smuggle SSH over DNS despite the security extensions, or if you want to study the intimate details of DNSSEC, this isn't the book for you. My goal is to help you upgrade your skills to basic DNSSEC competence, and point you in the direction to learn more.

DNS is traditionally fairly forgiving. Very few implementations adhere strictly to the protocol. This has made it easy to get DNS up and working. I've seen sites with fifteen year old nameservers, where the root zone file hadn't been updated since the server was installed, and DNS still worked. I've seen zone files with all kinds of weird shortcuts and abuses, but they parsed and loaded and worked. People have made up subdomains without delegating nameservers to each level of subdomain, and it worked. Some bad practices have become institutionalized because they worked.

You should know that DNSSEC is not forgiving. If the data doesn't adhere fairly closely to the DNS specifications, it won't validate. No nameserver for your subdomains? It won't validate. If you're not certain about your DNS skills, test first. Spin up a nameserver and a test domain, and try there before deploying DNSSEC out at your organization. Don't let DNSSEC scare you away, but do have a certain amount of respect for it.

Server Prerequisites

Configuring your DNS server platform properly before configuring DNSSEC reduces deployment problems. Install your server as per the operating system vendor recommendations and your local security standards. Install all operating system patches the vendor recommends, and configure your system to deploy updates and patches automatically if possible. In almost twenty years of systems administration I've never had an operating system update make BIND refuse to run. While it's possible that an OS update will give the nameserver trouble, it's much more likely that a failure to update will permit a security breach.

A DNSSEC-validating recursive nameserver makes additional DNS queries to gather all the necessary information, and it uses additional processor time to verify zone signatures. A DNSSEC authoritative server uses additional processor power to compute signatures and process keys when signing the zone. DNSSEC increases the amount of memory and bandwidth needed just because the zones contain more information. Without DNSSEC, you can serve thousands of clients on 20-year-old hardware. DNSSEC demands greater computing resources. It's still not much; my recursive nameservers usually have about 256MB of RAM and a single slow CPU. Basically, you need cutting-edge 10-year-old hardware instead of the 20-year-old hardware you could use before.

DNSSEC increases the size of your zone files. Signing a small zone increases a zone file roughly ten times, while large zones expand only two to three times. Even signed zone files are pretty small, though, especially compared to the size of modern disks. If your nameserver already uses a substantial amount of disk space for zone files, you'll need more space.

Disable all unnecessary services on the machine. Use a program like netstat(1), sockstat(1), or lsof(8) to see which programs are listening to the network. Identify all of them. Turn off and disable anything not necessary to running a DNS server.

Restrict command-line access to a short list of management IP addresses, and require public key authentication for your SSH services. If you don't know how to do that, permit me to suggest my book SSH Mastery (Tilted Windmill Press, 2012). Nobody except systems administrators should have command-line access to the server.

Have the system correct its time at boot, and use network time protocol (ntpd) to maintain correct time. DNSSEC signatures have timestamps. If your server time is incorrect by more than a couple seconds, your server might fail to validate good DNSSEC data. An incorrect clock will cause DNS outages. I strongly encourage you to use your monitoring system to make sure that the system clock doesn't start losing time, especially on a virtual machine.

After making these changes, reboot your server. Verify that any changes remain in place after a reboot. Yes, all this is kind of tedious and annoying. DNS failures are exciting, however. I like boring, and recommend it for everyone.

DNSSEC and your Network

Traditional DNS queries use UDP port 53, because queries and simple query responses alike can fit inside a single UDP packet. In the late 1990s, Extended DNS (EDNS) let DNS queries use multiple packets. If your server can't use multiple packets to deliver a DNS reply, the query might fall back to TCP port 53.

Many protocols routinely use multiple UDP packets. Why wouldn't DNS do that easily? Some firewall administrators believe that DNS only uses UDP, and block TCP port 53. Worse, some firewall products have filters intended to permit only DNS transactions over port 53, preventing people from tunneling other protocols over that port. Some of these products work by assuming that all DNS queries are 512 bytes or smaller, and dropping anything larger. Others drop all UDP fragments, rather than reassembling them. Cable and DSL modem/firewall products are notorious for this behavior. Some host-based firewalls (including PF on various BSDs and iptables from Linux) commonly drop UDP fragments. If your firewall has a naïve DNS filter, you will get spotty results from your DNSSEC-aware resolver.

How do you know if your environment has one of these limits? The DNS Operations Analysis and Research Center (OARC) offers a test. Check your network infrastructure with the OARC DNS Reply Size Test Server at https://www.dns-oarc.net/oarc/services/replysizetest, or by running the DNS diagnostic tool dig against a large zone. A command like dig paypal.com any should generate a sufficiently large response. You can force a TCP response by adding the +tcp flag (dig +tcp paypal.com). If you get good answers from the OARC test and can use DNS over TCP, you're probably fine.

If the test indicates that your nameserver suffers from improper packet filtering, stop your deployment. DNSSEC will not work until you resolve the network issues. You might even have to break out a packet sniffer like dnscap, tcpdump, or Wireshark to discover which part of your network abuses your packets.

BIND Configuration

To follow this book's examples, you'll need BIND on your DNS servers. Many operating systems come with a BIND install, but it's frequently version 9.8 or older. This book uses BIND version 9.9 or newer, because BIND 9.9 vastly simplifies running DNSSEC. Check your version of BIND by running named –v.

If your operating system splits the BIND server software and its related utilities (such as dig and host) into separate packages, install them all. Also verify that your server only has one version of BIND installed. The various utilities included in one version of BIND don't always work correctly with another version – for example, named-compilezone changed between 9.8 and 9.9, and the older version can't compile dynamic zone files from the newer BIND.

BIND usually runs in a chroot, with the configuration directory linked to /etc/namedb on BSD and many Linux systems. My examples use this configuration, but if yours differs just change the path in the examples to match your system. If your BIND doesn't run in a chroot, I highly recommend configuring one.

I also assume that you can configure rndc. If you've never configured rndc before, run rndc-confgen -a and restart named. You should be able to run rndc status and get a response from your server. I assume that you use rndc to control your nameserver, but generically, shutting down and restarting the whole server does trigger configuration updates.

Finally, if you expect to have named automatically maintain your signatures and keys, the user running named must have write access to your zone file directory and your key directory. I'll cover how to configure these in the appropriate chapters.

Recursive and Authoritative Servers

Historically, many DNS attacks relied on a nameserver performing both authoritative and recursive services. The purpose of a recursive server is to accept data from the public Internet, while the purpose of an authoritative server is to provide data for the public Internet. An intruder who wants to feed bogus data into a nameserver via DNS needs the nameserver to accept data. Authoritative servers that refuse to accept data eliminate that entire class of attacks. Additionally, authoritative servers never return DNSSEC-secured answers for the zones they are authoritative for. If you want to secure your own domain with DNSSEC, and you want the clients to get DNSSEC-secured data, the clients cannot ask the authoritative servers directly.

I recommend configuring one set of nameservers to serve your clients' DNS needs. These nameservers should not be authoritative for any of your public zones. (Modern recursive servers should be authoritative for private address space, to avoid flooding the root servers with irrelevant queries.) Configure a second set of nameservers as authoritative for your domains, and entirely disable recursion on them. Back when every server required dedicated hardware this was expensive, but with virtualization it's almost trivial.

What Is In This Book?

Chapter 1 is this introduction. Every tech book has one, but this one is mine.

Chapter 2, Cryptography and DNSSEC, explains the cryptography essential to understanding DNSSEC. If you're already familiar with public key and symmetric cryptography, you'll at least want to read the parts on how DNSSEC uses cryptography and the types of keys DNSSEC uses.

Chapter 3, How DNSSEC changes DNS, explains some of the resource records you must understand to implement and troubleshoot DNSSEC. I also cover how the Chain of Trust works, protecting your private keys, and interacting with your registrar.

Chapter 4, DNSSEC Resolvers, takes you through configuring a BIND server to ask for and validate DNSSEC information, and provide DNSSEC to clients that request it. We consider client operating systems and see what they do with DNSSEC.

Chapter 5, Dig and DNSSEC, uses the basic DNS diagnostic tool dig to recognize and examine DNSSEC issues.

Chapter 6, Securing Zone Transfers, covers securely copying zones between DNS servers with transaction signatures.

Chapter 7, KSKs and ZSKs, covers creating DNSSEC keys, the related files, and how to extract the necessary records from those keys.

Chapter 8, Signing Zones, uses the keys from Chapter 7 to actually sign and secure your zones.

Chapter 9, Debugging DNSSEC, covers how and why DNSSEC fails. I address useful troubleshooting tools and some of the on-line resources for debugging your DNSSEC environment.

Chapter 10, Key Rollover, covers key lifecycles and how to change your keys when needed. For such a short description, it's a fairly long chapter.

Chapter 11, Delegations and Islands of Trust, covers securing subdomains with DNSSEC and implementing DNSSEC on networks using private address space.

Chapter 12, DNSSEC for Data Distribution, shows how to provide information other than hostnames and IP addresses via DNS. We'll put SSH host keys, web site SSL certificates, and IPSec certificates in DNS, using DNSSEC to ensure that clients receive this information correctly.

Now let's dive into crypto.

Chapter 2: Cryptography and DNSSEC

DNS Security Extensions cryptographically verify that the information received by a client matches what the server intended to transmit. If the authoritative DNS server's records show that the host www.michaelwlucas.com is at the IP address 192.150.247.34, this should be the address that clients get. If someone forges DNS response packets or poisons a DNS server's cache, the DNSSEC-validating recursive nameserver recognizes the contamination and rejects the bogus data. But what does it mean to "cryptographically verify" something?

Most people think of cryptography as a way to transform readable "plaintext" into unreadable "ciphertext" and back. Only someone who knows the secret key and the encryption method can perform either transformation. This is the stuff of spy novels and thriller films, but while cryptography started as secret messages, it now includes all sorts of related tools and techniques. This book isn't a complete crypto tutorial; if you want details on cryptography, you'll need a different book. I cover practical cryptographic techniques in my book PGP & GPG (No Starch Press, 2006). One of the techniques DNSSEC uses is the cryptographic hash.

Cryptographic Hashes

A cryptographic hash is a mathematical algorithm that takes a chunk of text and computes a fixed-length string from it. Different algorithms produce hashes of different length, but the length of any hash produced by a specific algorithm never changes. For example, all hashes produced by the SHA-1 algorithm are 40 characters long, all MD5 hashes are 32 characters long, and so on.

The interesting thing about a hash is that minor changes in the original text dramatically change the hash generated from the text. Here's the MD5 hash of the text This is an important message:

393f37098965afbcf3bb5a14683b18f2

I change this text to This is an unimportant message, completely changing the meaning in only two characters. The MD5 hash becomes:

f168f399300404e1148580a6444d3b97

These two strings are wildly different. Even the most casual observer can see that the hash does not match.

It is possible that two chunks of text, or messages, will have the same hash. A message might contain thousands or millions of characters, but even the SHA512 hash algorithm has only 128 characters. Logically, innumerable files will have a given hash. The trick is, it's almost impossible to create a file that has a given hash value. I might know that a file has a hash value of f168f399300404e1148580a6444d3b97, but for a secure cryptographic hash function there's no realistic way to create another file that has that exact same hash. If I could find another message that had the same hash, it would almost certainly bear no resemblance to the original message. You might be able to replace This is a secure message with a string of binary garbage, but your human brain will recognize it as corrupt data.

As computers get faster, older hash algorithms become easier to break. The MD5 algorithm is no longer considered secure, because it's possible to create a file to match a specific hash value. (I used MD5 for my example only because the hash is short enough to fit nicely on the page.) New algorithms are created continually as older algorithms become vulnerable. Today's most widely recommended algorithm is SHA-256.

One way to extend a hashing algorithm's life is through using a salt. A salt is a value that is added to the original text before the hash is computed. Suppose I want to use the salt GiveLucasYourGelato with my original text of This is an important message. I would compute the hash based on the string This is an important messageGiveLucasYourGelato. I use a different salt for every piece of plaintext. The salt is generally known – for example, when DNSSEC uses a salt in its algorithms, the actual salt appears in a DNS record. When a salted password hash appears in a Unix-like system's password file, the salt appears right next to the salted password.

Why are salts important? If I hash the same text four times with the same algorithm, the resulting hashes will be identical. If I generate four hashes of the same plaintext, but if I use different salts for each, the resulting hashes will differ wildly. An intruder won't realize that these four hashes all represent the same plaintext.

Applications can use cryptographic hashes to verify that the contents of a message have not changed since creation. If a server sends a message (such as a response to a DNS query) and includes a hash for the message contents, the recipient can use the hash to verify the original message. The problem is, of course, that an intruder who has access to change the data could also tamper with the hash as he tampers with the message. Here, we use public key cryptography to make any tampering self-evident.

Public Key Cryptography

Symmetric encryption algorithms use a secret key (or just a key) to transform plaintext to and from ciphertext. Most algorithms use the same key to encrypt and decrypt text. If you have the key and know the algorithm, you can decipher the message. The secrecy of messages exchanged with these algorithms relies on the secret key remaining known only by authorized parties. This is the traditional encryption algorithm used throughout history.

Some algorithms use different keys for encryption and decryption. A message encrypted with one key can only be decrypted with the other key. These asymmetric algorithms work because the keys are very large numbers, and very large numbers behave strangely when multiplied together. Someone with one key can encrypt messages that only someone with the other key can decrypt, or can decrypt messages encrypted with the other key. If the bad guys have only one key, the bad guys can encrypt messages readable only by the owner of the other key and can read messages encrypted with the other key – but they cannot decrypt messages encrypted with the key they have.

Having two different keys that only work in concert creates interesting possibilities. You can make one key public and keep the other private. Any message encrypted by the private key can be read by the whole world. Does this keep the message secret? No. But it does prove that the person who encrypted the message has access to the private key. If only one person has the private key, the recipient can assume that the message actually comes from the private key owner. This concept underlies public key cryptography. A set of private and public keys is called a key pair.

DNSSEC uses public key cryptography and hashes to digitally sign DNS data.

Digital Signatures and DNSSEC

Combining hashes with public key encryption leads to digital signatures. The goal of a digital signature is to ensure that a message is authentic – it comes from the source it claims to have signed it, and a third party hasn't changed the message.

You digitally sign a message by generating a hash of the message, encrypting it with a private key, and attaching it to the message. Anyone with access to the public key (e.g., everyone in the world) can compute the hash for the message and compare it to the decrypted hash. Only the private key holder can encrypt the hash such that this particular public key can decrypt it, so the digital signature demonstrates that the private key holder signed the message.

If the received message has a different hash than the one in the digital signature, the digital signature is considered invalid. The message was changed after transmission. If a DNSSEC-aware program determines that the signature on a record is invalid, it discards the entire message.

Fortunately, you don't need to compute all these checksums yourself. DNSSEC-aware software checks for the presence of DNSSEC signatures in DNS transactions, and validates them if present. BIND includes several tools for creating, validating, and examining the cryptographic aspects of DNSSEC data, such as dnssec-keygen, dnssec-verify, dnssec-signzone, and dig.

DNSSEC Key Types

An intruder might try to get your private key without stealing it from the server by reverse-engineering it from publicly available information. A cryptographically savvy attacker can use high-powered computers to reverse-engineer the signatures on your DNS entries and computationally grind out your public key. One thing that helps cryptographic attackers is having a large number of encrypted samples with known plaintext, which is exactly what digital signatures provide. If you have a zone with many entries, a prospective intruder will get many different samples of encrypted text with known text. To mitigate this risk, DNSSEC can use different types of keys (Key Signing Keys and Zone Signing Keys) and lets you change your keys on a regular basis as covered in Chapter 10.

A DNSKEY record is a DNS record that contains all the keys for a zone. We'll cover DNSKEY records, along with other DNSSEC-related key records, in Chapter 3.

The Zone Signing Key (ZSK) is used to sign a zone. Every zone has its own ZSK. You can change the ZSK whenever you desire.

The Key Signing Key (KSK) is a key only used to sign the Resource Record set containing all the DNSKEYs for the zone, including KSKs and ZSK. Every zone has its own KSK. Changing a KSK requires coordination with outside parties, such as a domain registrar or IP address registry. A KSK is sometimes called a Secure Entry Point (SEP), because you can configure a nameserver to completely trust a KSK.

Essentially, your zones are double-signed. Your DNS data is signed with the ZSK, and the ZSK is signed with the KSK. An attacker who wants to computationally reverse-engineer your private key has a very small sample size; only one signature. This is extremely difficult – essentially impossible with modern computing equipment. When brute force computation approaches the point where the 2048-bit RSASHA1 keys commonly used today might be vulnerable, you'll need to upgrade your KSK and ZSK to the next recommended algorithm and bit length.

To further complicate an attacker's job, you can limit the lifetime of a key. Keys do not expire. (Digital signatures do expire, but named automatically renews those signatures.) You can assign an inactivation and deletion date to your keys and periodically replace (or rollover) your keys to new keys. Key rollover is not absolutely required to make DNSSEC work, but is highly advisable. I cover key rollover at length in Chapter 11.

Now that you understand something about encryption, let's see how DNSSEC extends DNS.

Chapter 3: How DNSSEC Changes DNS

Rather than creating an entirely new protocol, DNSSEC secures the domain name system by extending DNS itself. DNS already supports many resource record types, for many different services. DNSSEC works by adding new record types and performing additional computations to validate data. DNSSEC uses these records to create a Chain of Trust to validate any given resource record.

DNSSEC Record Types

Resource records are DNS data types. You've certainly seen resource records such as A (address), CNAME (canonical name), PTR (pointer), MX (mail exchanger), and so on. DNSSEC introduces new resource records that contain the encryption information and hashes necessary to perform DNSSEC validation. The five record types are DNSKEY, DS, DLV, RRSIG, and NSEC/NSEC3.

It's not necessary that you memorize all the details of these resource record types. You do need to be familiar with what they look like, so you can recognize when you have a problem. You'll need to dive in more deeply if your DNSSEC deployment fails.

RRset

A Resource Record Set, or RRset, is a collection of records of the same domain name, record class (IN), and record type. Resolvers return entire RRsets when answering queries. If you make a DNS query for the host www.michaelwlucas.com, you'll get a single A record because that zone only has one A record for that host. That's a complete RRset. If you ask for the host www.google.com, however, you'll get six A records back. Those six records are a single Resource Record Set. Google obviously has more resources than yours truly.

Resource Record Sets are fairly standard DNS stuff. Why do I bring it up? DNSSEC does not sign individual DNS records. DNSSEC signs complete RRSets. We'll see how this works in the RRSIG section later this chapter.

DNSKEY

The DNSKEY resource records contain a zone's public keys. When you view the record with dig it will look something like this.

isc.org. 3600 IN DNSKEY 257 3 5 AwEAAce/lMDzNxn…

The first string (isc.org) is the domain, and the second (3600) is the time-to-live in seconds for this data. The IN DNSKEY string shows that this is an DNSKEY record in the Internet class. The next field is for the key flags. DNSKEY records use only two flags: a 256 means that this record is a ZSK, while 257 means it's a KSK. Next is the protocol, which should always be 3 – if the protocol is not 3, this record is not for DNSSEC. (Just because a protocol isn't standard doesn't mean that someone won't wedge it into their DNS.) Finally there's the algorithm. The older RSASHA1 algorithm is number 5, the only algorithm DNSSEC implementations must support. NIST recommends new zones use RSASHA256 or algorithm 8. The root zone is signed with RSASHA256, so in practice every DNSSEC-aware server supports RSASHA256. Finally, there's the actual public key.

The DNSKEY record appears in the zone it supports; I get the DNSKEY record for michaelwlucas.com by querying the authoritative nameserver for michaelwlucas.com.

You cannot store arbitrary public keys in a DNSKEY record, only public keys used by the DNS system itself. You can use other record types for storing public keys, as we'll see in Chapter 11.

DS

The DS (Delegation Signer) resource record contains a hash of the zone's active KSK, as well as information about the algorithm used and the associated key tag. DS records look like this.

michaelwlucas.com. 86400 IN DS 12088 5 2 BF258808…

The first string is the domain, and the second is the time-to-live in seconds for this data. The IN DS labels this as an Internet DS record. The fifth field (12088) is the key tag. A tag is unique for any zone at any given time, but isn't unique between zones. The next field (5) is the algorithm, which again is RSASHA1. The next field (2) is the digest type field, or the algorithm used to compute this hash. 1 is SHA1, 2 is SHA256. The actual hash of the public key appears last.

A DS record appears in the parent zone of its zone. To get the DS record for michaelwlucas.com, you must query the .com nameservers. Yes, the .com nameservers should have DS records for every single domain that uses DNSSEC.

DS records are based on a zone's Key Signing Key.

DLV

A DLV (DNS Lookaside Validation) resource record is almost exactly like a DS record, but it's only provided by the DNS Lookaside Validation registry. We haven't covered the DLV yet, so for now just nod and smile as we go over this record type.

michaelwlucas.com.dlv.isc.org. 2644 IN DLV 31650 7 2 229C4…

michaelwlucas.com.dlv.isc.org. 2644 IN DLV 31650 7 1 E2BB2…

The first field is the domain name this key is distributed under. Zones anchored to the Chain of Trust by the DLV appear as subdomains under dlv.isc.org, so the domain michaelwlucas.com appears in the DLV as michaelwlucas.com.dlv.isc.org.

The second field is the time-to-live. This record will remain cached for another 2,644 seconds.

The third and fourth records (IN DLV) identify this as an Internet DLV record.

The fifth field is the key ID (31650).

The next field (7) is the algorithm, which in this case is NSEC3RSASHA1. The next field (2) is the digest type field. The actual public key hash appears last.

The DLV was originally intended for testing DNSSEC before the root zone was signed. Today, the DLV is a temporary workaround for registrars who do not support DNSSEC. If you need a DLV record, you need to push your registrar to join the 21st century.

RRSIG

The RRSIG (Resource Record Signature) record gives the digital signature of a set of resource records. If a DNSSEC-secured zone has an RRset for www.michaelwlucas.com, that RRset includes a RRSIG record. A RRSIG record looks like this:

www.michaelwlucas.com. 3600 IN RRSIG A 5 3 3600 20130225054537 20130126052421 39543 michaelwlucas.com. fh+6N+tfnkw97oE…

The first field is the name of the RRset that this data applies to. The second is the time-to-live in seconds for this data. The third and fourth field (IN RRSIG) identify this as an Internet RRSIG record. The fifth field (A) tells you what kind of DNS resource this signature applies to. This can be an A, a SOA, an NS, a MX, or any other sort of DNS record that appears in your zone or that DNSSEC adds to your zone (e.g., NSEC).

The sixth field (5) gives the algorithm used to generate this key. Algorithm 5 is RSASHA1. Chapter 7 covers key algorithms.

The seventh field (3) gives the number of labels in the resource set. For example, www.michaelwlucas.com has 3 labels, while michaelwlucas.com has 2. This helps DNSSEC validation by letting the client determine if this RRset includes wildcard DNS entries.

The eighth field (3600) gives the original time-to-live in seconds for this data, without any subtractions made by any intermediate caching nameservers. Validating a DNSSEC signature requires the original time-to-live number.

The next two fields give the date the signature expires, and the date the signature becomes valid. These datestamps are another reason that time synchronization is so important on DNSSEC-aware nameservers. This signature is not valid before the creation date or after the expiration date. BIND 9.9 can renew signatures automatically, as we'll see in Chapter 9.

The eleventh field (39543) gives the key tag (or key id) of the DNSKEY record that signed this signature.

The twelfth field is the signer's name. This should be the zone the record is part of, where the DNSKEY can be found. In this example, the signature on the RRset for the host www.michaelwlucas.com is signed by a DNSKEY in the michaelwlucas.com zone, exactly as you would expect it to be.

The record ends with several lengthy strings comprising the actual digital signature.

The signature is generated by signing the zone data with the ZSK. The DNSKEY RRset containing the ZSK and the KSK is in turn signed with the KSK.

NSEC/NSEC3

The "next secure" resource record offers proof of nonexistence of a record. If you try to find a record that does not appear in DNS, you want a statement from the authoritative DNS server that the record does not exist. Proving freeporn.michaelwlucas.com doesn't exist is just as important as proof that it does exist. Perhaps even more important.

NSEC records have an interesting side effect in that they can be used to enumerate the entries in a zone. An attacker can use them to list all the hosts in your zone by asking for the NSEC records for known hosts. NSEC3 records hash the names of the existing hosts, so that all attackers can learn is that there's another host. I cover creating NSEC3 records in Chapter 8.

Why is this important? When a client asks for a hostname, a zone with NSEC says that the closest surrounding host names are X and Y. For example, if you ask for the host support.michaelwlucas.com, an NSEC response would tell you that the closest hosts to that are mail.michaelwlucas.com and www.michaelwlucas.com. The client would know two valid hostnames in the zone. If the client came back and asked for the host www0.michaelwlucas.com, he'd get a response telling him that the closest hosts are www.michaelwlucas.com and zyzygy.michaelwlucas.com. You can ask a server for the first NSEC record in the zone, and then request the next. An intruder can easily get every NSEC record in the zone, which is roughly equivalent to letting everyone in the world perform a zone transfer.

For some zones, notably reverses, this doesn't matter. Everybody knows that 3.2.0.192.in-addr.arpa follows 2.2.0.192.in-addr.arpa, and can perform exactly this same sort of zone reconnaissance without performing a zone transfer. Forward zones contain more information than reverses, however: aliases, mail exchangers, service records, and so on. Some of this information might be sensitive to your organization.

Let's look at the specifics behind NSEC and NSEC3 records.

NSEC Records

An NSEC record looks like this.

pestilence.michaelwlucas.com. 900 IN NSEC www.michaelwlucas.com. A TXT AAAA RRSIG NSEC DNSKEY

The first field is the name of a valid host in the zone. The second field (900) is the time-to-live for this resource record. The third and fourth field identify this as an Internet NSEC record. The fifth field is the name of the next valid host in the zone. There are no hosts between pestilence.michaelwlucas.com and www.michaelwlucas.com. We then have a list of the types of records associated with the host at the beginning of the entry. The host pestilence.michaelwlucas.com has associated A, TXT, AAAA, RRSIG, NSEC, and DNSKEY records. The TYPE field is used to validate "no data" responses.

NSEC3 Records

An NSEC3 record looks like this.

DRVR6JA3E4VO5UIPOFAO5OEEVV2U4T1K.michaelwlucas.com. 3600 IN NSEC3 1 0 10 03F92714 GJPS66MS4J1N6TIIJ4CL58TS9GQ2KRJ0 A RRSIG

The first field is a hash of a valid hostname in the zone. The second field (3600) is the time-to-live for this resource record, while the third and fourth field identify this as an Internet NSEC3 record.

The fifth field (1) is the algorithm used to generate the hash.

The sixth field (0) are for NSEC3 flags.

The seventh field is the number of times the hostname is passed through the hashing algorithm, and the eighth is the hexadecimal salt used for that calculation.

The ninth field is the hashed hostname of the next host in the zone.

Finally, we have a list of valid resource records associated with this host. The host in our example has A and RRSIG records in the zone.

A zone using NSEC3 also includes an NSEC3PARAM record, which defines various cryptographic characteristics the client uses to dissect NSEC3 records. You don't really need to know the innards of NSEC3PARAM records, but you should know that they exist and are necessary for the proper working of NSEC3.

Now that you know what kind of records appear in DNSSEC zones, let's see how those records are used to build the chain of trust.

The Chain of Trust

A trust anchor is a "known good" public key used to sign DNS records. Trust anchors are the root of the DNSSEC system. Validating nameservers trust information provided by the trust anchor server and signed by the trust anchor key. BIND 9.8 and newer ship with the public keys for the root zone and for the DNS Lookaside Validation (DLV) service included. When you build BIND, those public keys are compiled into the software. Trust anchors are trusted for specific parts of the DNS namespace, although you can override them in the configuration file.

DNSSEC uses these trusted keys as the first link of the Chain of Trust used to develop trust for other domains, in the same manner as a recursive DNS lookup. Without DNSSEC, a nameserver looking for the IP address of a host – say, www.michaelwlucas.com – asks the root server for information. The root server responds with a message basically saying "I don't know that host, but here are the nameservers for .com, go ask them." The recursive server asks a .com nameserver, which directs the client to the michaelwlucas.com nameservers, which finally returns an answer.

DNSSEC uses a similar process to build trust in answers from your server, but in reverse. Trust is built from the bottom up. The client nameserver sees a signature on an RRset, and looks for a key that can validate that signature. If that key isn't trusted, it looks for a key to validate that key in turn.

So, suppose your resolver sees a signature on the www.michaelwlucas.com RRset. The resolver gets the DNSKEY record for the zone. To validate the signature, the resolver needs to find a signature for this record, made by a trusted key. The resolver checks the parent zone for a trusted key. The .com zone doesn't have a trusted key in it, but it has signed the KSK for michaelwlucas.com with a key. So your resolver checks for a trusted key in the parent zone for .com. The root zone has a trusted key, which validates the key on .com, which validates the key on michaelwlucas.com, which validates the signature on www.michaelwlucas.com.

You trust the root, so you trust everyone the root tells you to trust. DNSSEC lets you verify that trust at every link in the chain. If the cryptographic signature on any response fails validation, the response is discarded. Your nameserver will tell a desktop client that there's no such host. See Chapter 9 for details on debugging DNSSEC validation failures and some pretty diagrams on how everything breaks – er, works.

DNS Lookaside Validation

Some top-level domains are not signed; these include ones you'd expect signatures on, such as the top-level domains for many countries. If your top-level domain is not signed, your zone's digital signature can't be verified by a DS record in your parent zone. The chain of trust from your domain to the root breaks. The DNSSEC Lookaside Validation Registrar (DLV) provides a trust anchor for domains not linked to the root zone trust anchor. While anybody could theoretically open a DLV, the Internet Software Consortium runs the only popular one and everybody (including the ISC) hopes it will go away soon.

When a nameserver is looking for DNSSEC validation on a domain, but the normal recursive search shows a break in the chain of trust, the nameserver can check ISC's DNS Lookaside Validation servers for a DLV record. If the domain has a DLV record signed by the DLV key, your nameserver accepts that as a valid anchor for the Chain of Trust.

The DLV was originally created as a tool for testing DNSSEC. You can manually add trusted keys for specific domains to your nameserver, but that doesn't scale to the Internet. The DLV was a trust anchor for early DNSSEC adopters. The original plan was that when the signed root zone went public in January 2010, the DLV could be shut down. Theoretically, all of the domain registrars could support DS records and immediately make DNSSEC globally available. Sadly, many registrars do not yet support DS records for their clients. If you use a registrar that doesn't support DS records, the registrar doesn't support DNSSEC. You're stuck using the DLV.

The DLV presents trust issues, however. The root zone keys have careful access controls and advanced hardware protection. Using those keys requires multiple activation cards and different PIN codes and generally resembling the procedure for launching nuclear missiles. The DLV keys are controlled by some well-meaning folks at ISC. Some organizations, including some governments, specifically forbid trusting the DLV. If you rely on the DLV, you trust ISC and you trust those who trust ISC.

Today, I use the DLV. If your organization requires very strong security, however, you shouldn't. The DLV will become irrelevant, but that day isn't quite here yet.

I strongly recommend only using domain registrars that support DS records. If your registrar doesn't support DS records, ask them when they will. If they have no plans to support DS records, change registrars and tell them why. Domain registration is too important to leave with an organization unwilling to keep up with standards. A mob with torches and pitchforks is impractical these days, but should you have the urge to organize one, an obsolete registrar merits it.

Root Private Key Security

So, if BIND ships with two vital public keys in the source code, and those keys are compiled into the binaries, what happens if someone steals the private key? The private keys for the trust anchors are very well protected (see the "DNSSEC Practice Statement for the Root Zone KSK Operator" document at https://www.iana.org/dnssec/icann-dps.txt), but admittedly, nothing is utterly secure. There are hundreds of root servers scattered around the Internet, but none of them have the root zone private key. They have a copy of the root zone that is signed by the root zone private key. That actual private key is kept in a hardware security module, in two redundant off-line facilities managed by ICANN. ICANN periodically signs new ZSKs, which Verisign uses daily to sign the actual root zone. Verisign then sends the root zone to the root servers. The actual private key to the root zone KSK is protected by an air gap.

There's a mechanism for automatically updating the trust anchor key, documented in RFC5011. You don't need to be familiar with the innards of this mechanism, but it resembles the key rotation methods discussed in Chapter 11. In a worst-case situation, you can manually configure trust anchors and their keys, but if that's necessary it'll be widely publicized.

Don't worry too much about the root zone's private key. Worry about your own.

Managing Your Private Keys

Just how tightly will you protect your keys? Greater key protection requires more ongoing work. You need to decide how much work you're willing to do in exchange for what level of security.

It's common these days to have hosts keep their private keys on the local server. Many server software suites, such as OpenSSH, Apache, and various VPN products, must have their private keys available when they start. That's what these programs do, after all – they use their private key to do useful work. You could copy the private key to these servers to start the service, and remove the private key when the services are running, but that's a lot of work. System administrators habitually store private keys on the server, accepting the risk that an intruder could steal the key in exchange for the ability to conveniently restart the services. It's a tradeoff.

Forged DNS data presents a different threat level. An intruder who steals your web server's private SSL key can build a machine that can pretend to be your web site. An intruder who steals your DNSSEC private key can direct people to her rogue web server and publish an SSL certificate via DNSSEC, eliminating any need to steal the web server's private key. With DNSSEC control she can publish a rogue VPN SSL certificate via DNSSEC, and lead people into thinking that they're connecting to you when they're actually connecting to her site. She can publish fake SSH host keys for your servers via DNSSEC. By stealing your DNSSEC private keys, she can pretend to be anything on your network.

Admittedly, not all of these attacks are useful yet. Web browsers do not yet support DNSSEC-stapled SSL certificates. SSH clients other than OpenSSH do not support checking host keys via DNSSEC, and even OpenSSH doesn't do it by default. But free SSL certificates managed entirely within an organization are a powerful business case for DNSSEC, and once that happens, you'll see DNSSEC use skyrocket. Once DNSSEC is widely deployed, you'll see clients using all of these functions and more. From the start, treat your DNSSEC private keys as the precious resources they will become in the next few years.

There are three common approaches to protecting private keys.

Stealth Master

One approach to key protection is the stealth master. The master server is tightly secured, behind a firewall, perhaps in private address space. The public cannot access the master server for any service.

All nameservers that offer public services are slaves of the stealth master, and those public nameservers have no access to the master beyond DNS. These servers do not need the private key for the zones that they serve, as they only have zone files. If a public nameserver is compromised, the private key is safe.

Hardware Security Module

Another approach is to not store the private key as a file. A hardware security module plugs into the server hardware. Private keys can be stored on the HSM, or deleted from it, but not copied from it. When using a HSM on your master nameserver, you generate the private key directly on the HSM. There's never a file for an intruder to steal. And if an intruder can steal the hardware security module, the multiple security cards needed to power it on, and the multiple PIN codes needed to activate it, then the security of your private keys is the least of your worries.

Nothing

Storing your private key on your server, without any special protection, is certainly an option. It might even be a popular option. But it's not a secure option. If you choose to keep your private keys on your master nameserver, then anyone who breaks into your server can steal it. Even if nobody has ever broken into one of your servers, that doesn't mean that they can't or won't.

At the very least, become well-acquainted with the key rollover procedure in Chapter 11. Practice rolling over your keys. When someone steals your private keys, start replacing them immediately. I'll explain how to do this, but it's better to avoid the situation in the first place.

Publishing Public Keys

Before anyone can verify your signatures, you must make your public key available in the appropriate parent zone. This isn't terribly different from registering your nameservers with your registrar; you go to a web form, enter the information, and wait for the updates to propagate. Some registrars have APIs where you can submit updates via software.

DNS uses Delegation Signer (DS) records to publish hashes of KSKs. Your parent zones need the DS records for your domains. We'll look at creating the keys and extracting the DS records from them in Chapter 8, but before you get that far, verify that you know how to get your DS records into the public eye. There's three ways to do this: at your registrar, the DNSSEC Lookaside Validation (DLV) Registry, and your address space provider. You don't have to publish the key yet – in fact, you specifically must not publish public keys before signing your zone – but you do need to know which path you will follow. We'll consider each separately.

At the Registrar

The best way to publish your DS record is through the registrar where you registered your domain name. The catch is, not all registrars support DNSSEC. How can you tell if yours does? Search the registrar's documentation for "DS records" and then "DNSSEC." If your registrar doesn't appear to support DNSSEC, ask their support team. Some registrars support DNSSEC only through manual intervention, such as emailed requests. Familiarize yourself with your registrar's process for updating your DS records.

If the registrar really doesn't support DNSSEC, then you must either use the DLV or change registrars. The registrar I've personally used for ten years does not support either DNSSEC or IPv6, so I use the DLV for my personal domains. As my domains come up for renewal, however, I am moving them to a registrar that supports both DNSSEC and IPv6. (I don't say where I'm moving to because I don't want to appear to endorse any one company over another; many registrars provide excellent service.) I've been happy with my registrar's service, but they aren't keeping up with the times. I encourage you to follow my example.

Some registrars support DNSSEC, but only permit one DS key at a time. A registrar should permit two DS keys to support rollovers.

Many registrars need about 24 hours to get updates into the public nameservers. Some are much faster – those using Extensible Provisioning Protocol (EPP) can do nearly real-time updates. You have a better idea how fast your registrar propagates changes than I do.

At the DLV

If your parent domain is not signed or your registrar does not support DNSSEC, your domain's digital signature can't be verified by the root zone's signature, breaking the Chain of Trust. The DNSSEC Lookaside Validation Registrar (DLV) provides a trust anchor for domains whose registrars can't get their DS records into parent domains like .com.

Go to the DLV site at https://dlv.isc.org and create an account. You'll get the usual email for verification. Once you have that account, you can enter DS or DNSKEY records for a zone in the web interface.

When you enter a DS or DNSKEY record for a zone at the DLV, the web form presents you with a "cookie" TXT record to enter into the zone. The DLV will not activate your entry until its automated check sees this TXT record in the zone. The first check usually takes place in 5-10 minutes, but subsequent checks take longer. I recommend creating your DLV entry when it's convenient to add the TXT record to the zone. Once the DLV activates your keys, remove the DLV TXT record from the zone.

Address Space Provider

To enter DS records for your reverse DNS, you need to have the DS record inserted into your parent zone for your addresses. This is most easily done at Regional Internet Registries (RIRs), the entities that issue IP addresses. These organizations include ARIN (North America), RIPE (Europe), APNIC (Asia-Pacific), and so on. The RIRs all support managing DS records from web interfaces.

If you get your address space from a reseller, however, you need to ask them if they support DS records. If they do not yet support DNSSEC, they can't support the Chain of Trust internally, but that doesn't prevent them registering a DS record for you at their RIR. If you have a /24 network or larger, they can enter a DS record on your behalf at the RIR. Whether they will or not is a separate matter.

If your ISP cannot support your DNSSEC initiative, you're stuck with the DLV. Encourage your ISP to join the 21st century. You are also entitled to feel technologically superior to your ISP. Enjoy.

Now that you have a basic understanding of how DNSSEC works, and what outside support you need to fully implement it, let's get a nameserver to validate DNSSEC.

Chapter 4: DNSSEC Resolver

Start your DNSSEC adventure by configuring your recursive nameservers to validate DNSSEC on domains that offer it. This easy step is probably the biggest security improvement you can make in thirty minutes or less.

To enable DNSSEC, you need to have a place for named to store key files and a few entries in named.conf.

Key Management Directory

To manage and update a record of public keys, named needs a place to put files. If you don't specify a location, named will try to put the files in its own root directory – usually /etc/namedb. Most operating systems run named as an unprivileged user who deliberately doesn't have write privileges to this directory. (Allowing a daemon to overwrite its own configuration files is a security risk.) In named.conf, specify a directory for named to store keys.

If your server is strictly a recursive server, and is not authoritative for any domains, define a working directory. The named daemon will use this directory for all of its temporary and dynamic files, as well as any debugging output or logs.

options {

…

directory "/etc/namedb/working";

};

If your nameserver is both an authoritative and a recursive server – that is, serving as a master or a slave for a domain and helping clients – then define a directory specifically for managed keys. (Again, I recommend separating your recursive and authoritative servers, but you're free to ignore my advice on the matter.)

options {

…

directory "/etc/namedb/working";

managed-keys-directory "managed-keys";

};

A directory shown by its full path (as in the first example) is in the location shown. A directory name without a leading slash (as in the second example) is relative to named's working directory. My working directory is /etc/namedb/working, so the second example gives a managed keys directory of /etc/namedb/working/managed-keys.

In either case, the user running named must have write access to that directory. My servers run named as the user bind, but your system might have a different unprivileged user. Create the directory if it doesn't already exist, set it to be owned by the user running named, and set the directory permissions so the owner can write to it, like so.

# mkdir /etc/namedb/managed-keys

# chown bind:bind /etc/namedb/managed-keys

# chmod 755 /etc/namedb/managed-keys

Verify your work by running named-checkconf(8). It should return silently; any messages it displays indicate a configuration problem. You can use echo $? immediately afterwards to get the return value, which should be 0.

This is a great time to double-check your system time with date(1). DNS forgives inaccurate clocks; DNSSEC does not.

Activate DNSSEC Resolution

Now that named can write its key files, activate DNSSEC resolution in /etc/named.conf. For the widest range of valid DNSSEC, trust both the root zone and the DLV server.

options {

…

dnssec-enable yes;

dnssec-lookaside auto;

dnssec-validation auto;

};

Restart named. You're done. Really.

You now validate DNSSEC data, using the public keys hard-coded into the BIND source tree. If you look in your managed keys directory, you'll see a file containing the managed keys and the dynamic journal for key updates.

Testing DNSSEC Validation

How can you tell it works? Fire up dig and run some queries. Here we have a platypus-and-egg problem: you need a DNSSEC-validating resolver to play with dig, and you need dig to verify your supposedly validating resolver really validates DNSSEC. I cover dig in Chapter 5.

I recommend querying isc.org; they wrote BIND, and they're really pushing hard for DNSSEC, so we can realistically expect their DNSSEC to be working. Remember that dig uses the resolvers configured in /etc/resolv.conf, so if you want to test a specific nameserver you must specify it on the command line.

$ dig +dnssec www.isc.org

You should see RRSIG and DNSKEY records. Additionally, dig displays the ad flag (for authenticated data) if the recursive server can validate the response.

To test your DLV functions you need to find a domain that uses DNSSEC via the DLV. Many of my own domains do so, but as I gleefully destroy my own environment in the pursuit of knowledge, using it as a test probably isn't wise. Use the domain that the DNS-OARC established for just this purpose.

$ dig +dnssec nsec3.dlvtest.dns-oarc.net

Both of these dig queries should return RRSIG records and have the ad flag set.

If you don't care about the DNSSEC-specific records, but want to know if a zone validates, use the +ad option.

$ dig +ad paypal.com

In the next chapter, we'll delve deep into dig and DNSSEC.

Clients and DNSSEC

Most desktop systems have a stub resolver – they send DNS queries to a recursive nameserver, but don't actually process the responses any further. They do not validate DNSSEC responses on their own. If the recursive nameserver claims that a DNS response is signed, that's good enough for the client.

If an attacker is on the network between the recursive nameserver and the client, it's possible that they could spoof responses from the recursive server. The "proper" solution to this is to have stub resolvers validate DNSSEC, but that's in the future.

As of Windows 7, Microsoft clients are aware of DNSSEC. They cannot independently validate DNSSEC queries, instead relying on the local DNS server to perform this validation. Microsoft recommends securing this traffic by deploying an IPSec VPN between the client and server. Check Microsoft's site for information on setting up DNSSEC with DNS servers.

If you want a Unix-like workstation to validate DNSSEC, enable named on the machine. Configure such a nameserver to only accept queries from the local host and to perform its own recursive queries. Such a configuration uses only a tiny amount of resources. You can't just forward queries to another nameservers, as forwarders do not perform their own DNSSEC validation.

If you're looking for an application to perform client-side DNSSEC validation, I recommend Unbound (www.unbound.net) or Unbound with DNSSEC-trigger (https://www.nlnetlabs.nl/projects/dnssec-trigger/). The TLSA Firefox plugin discussed in Chapter 12 uses these tools, as do various other client-side DNSSEC validators.

Testing DNSSEC at the Client

Even though DNSSEC validation at the client is currently the weak part of the Chain of Trust, enabling DNSSEC changes client behavior. Configure a client to use only DNSSEC-validating nameservers. Open a Web browser, and go to one of the DNSSEC testing sites. A search engine will show several, but my favorite is http://dnssec.vs.uni-due.de – it's very responsive and unambiguously tells you if you resolve DNSSEC or not. Any web site maintained as an aside by busy sysadmins might be down at any given time, of course, so try several until you find one that works well for you.

In the next chapter, we'll see how to make more sophisticated debugging queries.

Chapter 5: dig and DNSSEC

The dig(1) program is the standard DNS diagnostic tool. It lets you perform recursive and iterative searches using chosen nameservers, gather detailed information from a nameserver's cache, and scrutinize exactly how a specific nameserver behaves. Your BIND install should include dig; if it doesn't, go look for an operating system package. Microsoft users should install the BIND package from ISC's BIND site – it's fast, small, integrates with Windows, and doesn't spam your system with unrelated junk. If you don't want BIND, use Cygwin.

Do not try to debug DNSSEC with nslookup. The nslookup program has been deprecated for years. I admit, I used nslookup far beyond when I should have stopped. When you enter DNSSEC-land nslookup is not merely not useful – in some cases it gives incorrect, incomplete, or harmful answers. The nslookup command does not display the response codes vital in DNSSEC debugging. Skip nslookup.

When used without options, dig queries the system's nameserver for a host's IP address.

$ dig www.michaelwlucas.com

 ; <<>> DiG 9.9.2 <<>> www.michaelwlucas.com

;; global options: +cmd

;; Got answer:

 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36382

 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

 ;www.michaelwlucas.com. IN A

;; ANSWER SECTION:

 www.michaelwlucas.com. 7200 IN A 192.150.247.34

Here I asked dig for the IP address of my web server, and it returned 192.150.247.34. But let's look more closely at the output. At  you'll see the version of dig used. Most utilities use BIND's version number, so this is the dig that shipped with BIND 9.9.2.

The header line at  declares what sort of operation this is, and if the DNS server returned an error. This particular dig request is a QUERY, and the status of NOERROR means that the server queried has an answer for you, either from the cache or from the authoritative server.

The  flags give more detail about the query. Flags provide vital clues when debugging DNSSEC issues – or general DNS issues. The flags you'll see are:

- qr (query response) – this message is the response to a query. This is always present in a response.

- aa (authoritative answer) – this message is an authoritative answer. This flag should always appear when you query a domain's authoritative nameserver about that domain, and only then.

- rd (recursion desired) – the client asked the nameserver to find an answer, even if the nameserver had to perform a recursive search for it.

- ra (recursion available) – the nameserver is willing to perform recursive searches.

Additionally, you can see the following flags when working with DNSSEC.

- ad (authenticated data) – the nameserver has validated this data's digital signature.

- cd (checking disabled) – the client has requested that the nameserver not perform DNSSEC validation on the data.

You'll see the  query echoed in the output, followed by the nameserver's  response. Most people skip directly to this response, but everything before it is important.

A couple lines after the flags, you'll see the Extended DNS (EDNS) section. There's a flag field here. Only one flag is defined now, do, for DNSSEC OK. The client has specifically requested DNSSEC validation, and the server can perform that validation for the client.

DNS Errors

Note the status field in our previous example shows noerror. That means that everything worked. Maybe we got an answer. Maybe we didn't. But the DNS client went out, got some data, and returned it to us.

When something goes wrong, you might see a status of SERVFAIL. This means that DNSSEC validation failed, or the authoritative server isn't, or any number of other things. The Domain Name System has failed to fetch an authoritative response to this query.

If the record you're looking for doesn't exist, you'll get a NXDOMAIN error. For example, there is no host www2.michaelwlucas.com. If you query for that, you'll get an NXDOMAIN.

You might also get an authoritative answer with no results, or no data. After the flags field you'll find an ANSWER section. If this is 0, the information you're looking for doesn't exist. For example, the DNS record for www.michaelwlucas.com includes A and AAAA records. If I request the NS record for that host, I get no data. Answers exist, just not the type of answers we're looking for.

Digging DNSSEC

To view DNSSEC information on a zone, add the +dnssec option. For my examples, I'm also adding +multi to make the output easier to read. I'm examining the DNSSEC records on www.isc.org with my validating resolver. As those folks are DNSSEC gurus, I expect their main web site to always have fully functional DNSSEC.

$ dig www.isc.org +dnssec +multi

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56342

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13

Note the ad flag in the result. This data is authenticated by DNSSEC. How does that authentication appear in DNS? Look further down in the response for the answer.

…

;; ANSWER SECTION:

www.isc.org. 600 IN A 149.20.64.42

isc.org. 7200 IN RRSIG NS 5 2 7200 (

20130413181154 20130314181154 50012 isc.org.

C+/FFrY6RF5DjdXk+e8mVwxNO27d+FIQUf5saqVjvQ5V

…

The RRSIG record is the actual signature on the RRset. It's part of what our recursive nameserver used to validate the DNSSEC data, and is probably the part of the answer we're most interested in.

If a validating resolver cannot validate the DNSSEC signature on data, it gives a SERVFAIL error. To end users, this appears as if the host has vanished from the Internet. I show assorted failures, and how to diagnose them, in Chapter 9.

A non-validating resolver will show a zone's DNSSEC records if you request them. But it won't verify the signatures on the zones. That's what makes a non-validating resolver non-validating. Non-validating resolvers always return any data the authoritative server has for the zone, even if the signature is invalid. Or, if you prefer, non-validating resolvers behave exactly like they always have.

digging Authoritative Servers

Try asking ISC's authoritative servers about www.isc.org, and you'll see something surprising.

$ dig www.isc.org +dnssec @199.6.1.30

…

;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13

The authoritative nameserver for the domain, when queried, does not display the ad flag. This data is not authenticated. The aa flag states that the response is authoritative, however. Reading further shows that the answer has RRSIG records, so the answers are signed. Shouldn't a response directly from the master nameserver be cryptographically secured?

An answer received directly from an authoritative nameserver never appears cryptographically secured. The authoritative server doesn't validate its own answers. The authoritative server considers itself correct, just like any other authority in any other field of knowledge, from network administration to brewing absinthe. Only a validating resolver not authoritative for the domain will validate those signatures.

digging the DLV

Domains using the DLV trust anchor can also be diagnosed with dig if you remember two things. First, your domain is shown as a subdomain of dlv.isc.org. Second, you must query the nameservers for the zone dlv.isc.org, not the server dlv.isc.org itself. Rather than looking up the nameservers directly, you can use the dlv modifier to dig. Here I search for the DLV record for absolutenetbsd.com.

$ dig absolutenetbsd.com.dlv.isc.org dlv

…

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 7

…

;; ANSWER SECTION:

absolutenetbsd.com.dlv.isc.org. 3438 IN DLV 13558 5 2 D853B57CD6639CAB7…

absolutenetbsd.com.dlv.isc.org. 3438 IN DLV 13558 5 1 45DF2C727B563BB14…

The ad flag is set, indicating that your nameserver has authenticated this data. And the DS records let validating resolvers build the Chain of Trust for the domain absolutenetbsd.com.

Disabling Validation

Remember that when DNS data fails DNSSEC validation, the nameserver rejects the data and additionally provides a SERVFAIL response to the client. One way to differentiate between a DNSSEC failure and a generic DNS failure is disabling DNSSEC validation. Use the +cd option for this.

$ dig www.michaelwlucas.com +cd

If a DNSSEC-enabled request results in a SERVFAIL error, but you get a response with DNSSEC checks disabled, then your DNS server cannot validate the DNSSEC signatures on the data. Chapter 9 will walk you through figuring out why a signature does not validate.

External Checks

Sometimes you need to test your DNS configuration against a nameserver that has no special knowledge of your network, so you can verify that your zones are configured the way you need. In my case, I set up a recursive server that isn't attached to my DNS infrastructure. You can also use the OARC's open DNSSEC resolvers, documented at https://www.dns-oarc.net/oarc/services/odvr.

$ dig michaelwlucas.com @149.20.64.20 +dnssec

The nameserver 149.20.64.20 is not related to my domain in any way. If this shows the ad flag for this query, I know that my DNSSEC setup is correct. If it doesn't show the ad flag, it might be a problem with my zone or the resolver – nothing says that the fine folks who run OARC cannot have a time problem on one of these servers. Try a few unrelated validating resolvers before concluding that your zone is broken.

We'll dig much more through this book, but this will get you started.

Chapter 6: Securing Zone Transfers

Having your master server digitally sign zones is nice, but if an intruder can attack your zone data as it travels between your master and slave servers then the digital signature isn't helpful. Before deploying full-on DNSSEC on your zones, you really should secure zone transfers between a master and its slaves. BIND uses Transaction Signatures (TSIG) to guarantee data integrity. While DNS transactions include dynamic updates, NOTIFY messages, and dig queries, TSIG is most commonly deployed to protect zone transfers.

Purists will note that TSIG is not strictly part of DNSSEC. If you're going to the trouble of securing your zone data on your authoritative servers, however, you should certainly secure that data as it goes between authoritative servers. And you should do it before deploying DNSSEC, or: now.

TSIG works via symmetric encryption. The server and the client share a key. Any bad actor with the secret key could extract a zone transfer from a master or update a dynamic zone protected by these keys, but BIND lets you restrict a TSIG key so that it's only usable by a specific IP address. While not perfect, this is a significant improvement over purely IP-based access control. (I leave perfection up to other people.)

Also note that TSIG doesn't encrypt the data in transit. Its digital signature preserves the integrity of master-slave communications, not confidentiality. If you want confidentiality between your masters and slaves, set up a VPN.

Create a separate shared secret key for every slave server. If an intruder compromises a slave server, you only need to replace the keys stored on that host. If an intruder breaks into your master nameserver, replace all keys for all secure protocols on that host – SSH, HTTPS, DNSSEC, LDAP, and anything else.

TSIG Configuration

To configure TSIG you must create TSIG keys for each pair of hosts, tell named about the key, and assign the key to a specific server. We'll cover these in order.

Key Creation

Create TSIG keys with dnssec-keygen(8). You must know the algorithm, the number of bits in the key, and the name of the key.

TSIG keys can use several different algorithms, but the current NIST recommendation is HMAC-SHA256. Strictly speaking, an organization can use any algorithm implemented on the masters and all slaves. You could use a different algorithm for each, but for most cases that would be silly. Upgrade your older nameservers.

The number of bits in the key varies by algorithm, but HMAC-SHA256 can use between 1 and 256 bits, with 112 being the NIST recommendation. 112 bits is a minimum, but longer keys are more secure. They also take more computing power, but if you control both your masters and slaves, you might want to use them. You copy-and-paste the secret into named.conf, so you never have to type 512 bits of secret key. I recommend using the NIST standard, 112 bits.

# dnssec-keygen -a HMAC-SHA256 -b 112 -n HOST key-name.

The only part of this command you need to change is the key name. Use the hostnames involved in the key name, so you can easily identify the file later. It's traditional to end the key name in a period. Below I create a file to secure transactions between two machines, bewilderbeast and pestilence. I abbreviate the hostnames in the key name, because I'm not that much of a masochist.

# dnssec-keygen -a HMAC-SHA256 -b 112 -n HOST bwb-pst.

Kbwb-pst.+157+13738

This creates two files, Kbwb-pst.+157+13738.key and Kbwb-pst.+157+13738.private. Here we see a weird detail of dnssec-keygen's behavior, in that it always generates two files. TSIG uses a symmetric key. Both files contain the same secret key.

Look at the file ending in .private. You'll see a line much like this:

Key: L2kf18Hz+ODr519beRA=

The text after the Key: is the shared secret key. You'll copy that string into named.conf next.

Add the Key to named.conf

Add a key statement to named.conf on both the master and the slave. You need the key name and the secret key.

…

key keyname {

algorithm hmac-sha256;

secret "secret-from-private-file";

};

…

For example, to add my bwb-pst. key to this nameserver, I would add this entry to named.conf.

key bwb-pst. {

algorithm hmac-sha256;

secret L2kf18Hz+ODr519beRA=

};

Now that named knows about the key, tell it to use this key for a specific server.

Assign Key To Server

BIND lets you configure settings for each server it communicates with. This named.conf entry on the master server specifies the IP address of a slave and the name of the key.

server 192.0.2.34 {

keys {bwb-pst. ;};

};

The slave server needs a similar entry, using the master server's IP address.

Reload the nameservers, and they will have the ability to use TSIG between them. They won't use TSIG until you activate it, however.

Let Keys Transfer Zones

The allow-transfer option in named.conf permits a specific host to copy the zone. It's normally used on master servers to allow a slave to get a copy of the zone. You can specify the key name in the option. Here I tell named to let the key bwb-pst. transfer a zone.

allow-transfer {127.0.0.1; key bwb-pst. ;};

Any host that identifies itself with this TSIG key can copy this zone. The master server will sign the zone with the secret key to guarantee data integrity. And remember that you can include allow-transfer in specific zones as well as in the global nameserver configuration, so you can prevent random slave servers from arbitrarily downloading all of your zones.

Does TSIG Work?

The easy way to tell if TSIG works is to update the zone and see if the slaves pick up the changes. Masters notify their slaves when the zone is updated, so the slaves should attempt to transfer the zone immediately. You can also run rndc retransfer zonename on the slave to force an attempt to transfer the zone.

If TSIG is correctly configured, you'll see confirmation in your debugging log.

client 192.0.2.34#15519/key bwb-pst (michaelwlucas.com): transfer of ' michaelwlucas.com /IN': AXFR started: TSIG bwb-pst

client 192.0.2.34#15519/key bwb-pst (michaelwlucas.com): transfer of michaelwlucas.com /IN': AXFR ended

If the transfer doesn't work, you'll get "denied" messages instead. Check your configuration. The most common errors I have in new TSIG installations is that I incorrectly type something in named.conf. The key name must be identical everywhere it's used, and tied the key to the server's correct IP.

If TSIG fails on a new server, check the clocks on both the master and the slave server. TSIG, like much of DNSSEC, requires synchronized time. When the clocks differ, the log shows a BADTIME error.

Once TSIG works, you can delete the key files unless you need them for dig.

dig Versus TSIG

I frequently use dig to test zone transfers between machines. When using TSIG, you need to tell dig about the TSIG key file with the –k argument.

# dig -k /etc/namedb/tsig/Kbwb-pst.+157+13738.key michaelwlucas.com @192.0.2.34 axfr

I usually allow zone transfers from the host 127.0.0.1, in addition to key-secured transfers to other hosts. This lets dig do a zone transfer without using a key. Sometimes using dig to view a zone on the local machine helps me figure out what I screwed up, and there's no security risk in transferring a zone on the local machine.

Now that you can secure zone transfers, let's create some DNSSEC keys.

Chapter 7: KSKs and ZSKs

Every zone needs its own Key Signing Key (KSK) and Zone Signing Key (ZSK). These keys create the Chain of Trust, as discussed back in Chapter 2.

All keys must be readable by the user running named. If your permissions are wrong, you'll get an error when trying to use them.

Single Key Zones

It is possible to sign a zone with a single key, rather than two. If both the parent zone and the child zone are managed by a single entity, you can use a common signing key (CSK) for both levels. Examples include the various parent domains under .uk. A CSK shows up as type 256 in a DNSKEY record, just like a ZSK.

The most common environments need two keys. If you run a top level domain like .uk, and are just starting to deploy DNSSEC, you might investigate using a CSK. Lots of documentation exists in the form of conference slides and random mailing list postings. In the absence of a compelling reason to use a CSK, I recommend sticking with the standard dual key system.

Key Algorithms

DNSSEC keys have used several algorithms over the years, and algorithm choice impacts what your DNSSEC installation will support. The three algorithms commonly used for zone keys today are RSA/SHA-1 (algorithm 5), RSA/SHA1-NSEC3-SHA1 (algorithm 7), and RSA/SHA-256 (algorithm 8). Which you use depends on your environment.

RSA/SHA-1 is the only algorithm that DNSSEC implementations must support, according to the DNSSEC specification. It's older, and not as strong as algorithms like RSA/SHA-256.

RSA/SHA1-NSEC3-SHA1 is exactly the same as RSA/SHA-1. The only difference is the algorithm number. Why is that? The different algorithm number serves as a flag that this zone includes NSEC3 records. A resolver that doesn't recognize algorithm 7 will understand that it cannot validate this zone.

RSA/SHA-256 is much stronger than RSA/SHA-1. Interoperability is important, and all clients must be able to use the same encryption algorithms. RSA/SHA-256 is not defined as a required algorithm by the DNSSEC specifications. The root zone is signed with this algorithm, however, so any nameserver performing DNSSEC validation in practice can handle RSA/SHA-256.

Which should you use? RSA/SHA-256, unless you're a government agency. The only algorithm approved for use within the US government is RSA/SHA1. This is widely expected to increase to RSA/SHA-256 when the government gets around to it. If you are forced to work within government regulations, see if you can use RSA/SHA-256 anyway. Otherwise, you're stuck with RSA/SHA-1.

RSA/SHA-1 and RSA/SHA1-NSEC3-SHA1 are mostly used by older installations. If possible, migrate these to RSA/SHA-256. Changing algorithms means performing a key rollover, as covered in Chapter 10.

Algorithm choices change over time. While RSA/SHA-1 was once considered sufficient, RSA/SHA-256 has largely supplanted it. By 2015, NIST expects to start recommending elliptic-curve-cryptography-based algorithms instead. The Internet Engineering Task Force (IETF) constantly develops new ways to use DNSSEC and new key algorithms to support those uses. You can get a complete list of DNSSEC key algorithms at http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml. Each algorithm has a related RFC standard describing the uses, purpose, strengths, and weaknesses of each hash method.

For the most part, though, you only have to worry about what algorithms your installation supports. Algorithms 5 and 7-11 are in real-world use, and BIND 9.9 supports them. The full list of algorithms and standards will be more useful in the future, when you're troubleshooting and discover a new algorithm in the wild. Even then, your probable solution will be "upgrade BIND."

Bit Lengths

Keys can be any bit length from 1 to 4096 bits. The longer your keys, the more computation others must do to validate your signatures. As such, using 4096-bit keys everywhere tells others that you're either something of a jerk or ignorant. The NIST recommends 1024 bits for ZSKs, and 2048 bits for KSKs.

You might have a reason for using longer keys, however. If you're a consultant setting up DNSSEC, and you just know that the client is going to ignore your advice and never rotate their keys, you might use longer keys. A key length of 4096 bits does make the zone bigger, but that increase is just noise next to the RRSIG records.

Key Files

Each keypair created by dnssec-keygen, regardless of algorithm or role, has two files. Key files start with a K, then the zone name, followed by the algorithm, followed by a key ID. One file ends in .private, one in .key. A key for the zone michaelwlucas.com might include these files:

Kmichaelwlucas.com.+008+13957.key

Kmichaelwlucas.com.+008+13957.private

The 008 is the key algorithm. These are RSA/SHA-256 keys. The 13957 is the key ID number. Each key has a five-digit key ID number. These numbers are not universally unique, but the key ID helps differentiate one key from another. Key IDs are unique for a zone at any given time. If you run DNSSEC long enough and frequently rollover your keys you'll eventually get the same key ID again, but the first key with that ID will be long deleted (see Chapter 10).

The .private file contains the private key and related information for this keypair. The .key file contains the public key in DNSKEY format, along with timing information and the key's role.

Each zone needs a pair of key files for the KSK and another pair for the ZSK, for a total of four files. Back up the keys when you create them.

About five minutes after you create the keys, you'll forget which files go with the KSK and which the ZSK. The easiest way to differentiate ZSK from KSK files is to look at the .key files. Lines beginning with a semicolon are comments, and the first comment identifies the key type.

; This is a zone-signing key, keyid 48252, for michaelwlucas.com.

; Created: 20130130031526 (Tue Jan 29 22:15:26 2013)

; Publish: 20130130031526 (Tue Jan 29 22:15:26 2013)

; Activate: 20130130031526 (Tue Jan 29 22:15:26 2013)

michaelwlucas.com. IN DNSKEY 256 3 8 AwEAAdW…

The first line identifies the type of key, the key ID number, and the zone the key belongs to. The next three lines are for timing data, used in key rotation (see Chapter 10). The last line is the actual DNSKEY record for the zone.

Creating Keys

Up until now we've talked about keys, looked at keys, and generally poked at them. Now let's actually generate some KSKs and ZSKs with dnssec-keygen. You must specify an algorithm by either name or number, the number of bits, and the zone name. If you're creating a key signing key, you must add the flag for that.

By default, dnssec-keygen creates RSA/SHA-1 keys with 1024-bit ZSKs and 2048-bit KSKs. For all other algorithms, you must specify the number of bits. Get into the habit of including the algorithm and bits on the command line or in your scripts. That way, changing defaults over the years won't surprise you.

To create a key signing key, use the –f ksk option. Specify the algorithm with –a, and the number of bits with –b. You can use the algorithm name instead of the number, removing all punctuation from the name (i.e., RSASHA1 or RSASHA256). For RSA/SHA1-NSEC3-SHA1 keys, add the -3 flag instead of the algorithm name. I prefer using the number rather than typing the whole name. Give the name of the zone as the final argument.

$ dnssec-keygen –f KSK –a 8 –b 2048 zonename

For example, to create a KSK for the zone michaelwlucas.com, I would run:

$ dnssec-keygen -f KSK -a 8 -b 2048 michaelwlucas.com

Generating key pair.................................+++ ............................+++

Kmichaelwlucas.com.+008+48082

This generates two files in the current directory, Kmichaelwlucas.com.+008+48082.key and Kmichaelwlucas.com.+008+48082.private.

Generate your ZSK similarly, but reduce the number of bits and remove the KSK flag.

# dnssec-keygen –a 8 –b 1024 zonename

This generates a 1024-bit RSA/SHA-256 ZSK.

Remember that the user running named must have read access to these files, so make that user the owner of these files. Do not make the key files world-readable.

DS Record

Validating clients look for a DS record in your parent domain to build the Chain of Trust. Remember, a DS record is a secure cryptographic hash of the actual public key. Run dnssec-dsfromkey(8) on your KSK. You can drop the .public and .private from the key file name.

$ dnssec-dsfromkey Kmichaelwlucas.com.+008+48082

michaelwlucas.com. IN DS 48082 8 1 C1C2450…

michaelwlucas.com. IN DS 48082 8 2 1DB8186…

These two lines are your DS records that need insertion into the parent domain. Keep them handy. Once your zone is signed, you must send these to your registrar, RIR, or the DLV as per Chapter 3.

Dig and Keys

It's hard to pick out the DNSKEY record from the complete zone. The easiest way to get a DNSKEY record is by querying the zone it belongs to. We won't add the key to the zone until the next chapter, but for now just follow along. To look at a zone's DNSKEY records, request them with dig.

$ dig isc.org dnskey

…

;; ANSWER SECTION:

isc.org. 6863 IN DNSKEY 256 3 5 BQEA…

isc.org. 6863 IN DNSKEY 257 3 5 BEAA…

See Chapter 3 to learn how to understand a DNSKEY record. You can see here that ISC is still using algorithm 5, or RSA/SHA-1. You can start out using a newer and stronger algorithm than them.

Now that you have keys, let's sign a zone.

Chapter 8: Signing Zones

Now that you have a Key Signing Key and a Zone Signing Key for your first zone, you can actually sign your zone. I assume that you will let named maintain your signatures. BIND 9.9 lets you have named automatically sign zones for dynamic zones and zones backed by static zone files.

Key files accumulate quickly, and if you store them with your zone files they can easily overwhelm all other files. Some people recommend using a directory for each zone, storing all files for that zone in that directory. I prefer to use a directory for my zone files and a separate directory for my key files. It doesn't matter what you do so long as you're consistent. In my examples I put zone key files in per-domain directories.

Signature Methods

BIND includes zone-signing commands, letting the sysadmin hand-tweak exactly how the zones are signed. While there's nothing wrong with doing so, manually signing zones is too much work for most systems administrators, especially if you have a lot of zones to maintain. BIND 9.9 can automatically sign zones, and refresh the signatures on those zones. Older versions of BIND cannot. The manual commands remain for the convenience of those who implemented DNSSEC in the early days, and while you're welcome to use them for new DNSSEC deployments, there's really no reason to. If this is your first DNSSEC deployment, then I reiterate: install BIND 9.9.

Organizations that use static zone files have a completely different workflow than organizations using dynamic DNS. Nobody wants to change they way they work to accommodate DNSSEC. If an organization maintains static zone files with some kind of provisioning or version control system, they won't blithely switch to dynamic updates just to implement DNSSEC. Plus, those of us who have manually edited zone files by hand for decades have a deep-seated horror at the thought of letting BIND change our zone files. Those people who use dynamic zones don't like to muck with static zone files. We'll consider each case separately. In both cases, though, the easiest way to implement DNSSEC is by letting named maintain the keys and signatures.

auto-dnssec maintain;

BIND's auto-dnssec maintain feature tells named to look for keys for a zone and use those keys to sign the zone. We'll use this option to automatically sign a zone.

We saw in Chapter 3 that DNSSEC signatures – the RRSIG record – have an expiration date. With auto-dnssec maintain, named automatically renews those signatures as they expire and removes expired signatures from the zone. In my experience, lapsed signatures are a common cause of DNSSEC-related DNS failures. (Other people's DNSSEC-related failures, that is; me, I let named do all the work.)

We'll start by using auto-dnssec maintain on dynamic zones. Even if you use static zones, follow the discussion on dynamic zones. The way auto-dnssec handles dynamic zones is highly relevant for static zones.

Signing Dynamic Zones

Dynamic zones can be updated by clients. Most consumer operating systems attempt to update their local zones with their hostname and IP address. With auto-dnssec maintain, named automatically reads the key files and signs the entries in a dynamic zone.

Your zone is dynamic if its named.conf entry looks like this:

zone "blackhelicopters.org" {

type master;

file "dynamic/blackhelicopters.org";

update-policy local;

};

Your zone might use an update-policy statement instead of allow-update.

Create a KSK and ZSK for your zone as per Chapter 7, then configure named.conf to use them like so.

zone "blackhelicopters.org" {

type master;

file "dynamic/blackhelicopters.org";

allow-update { 127.0.0.1; };

key-directory "dynamic/keys/blackhelicopters.org ";

auto-dnssec maintain;

};

The key-directory statement gives a directory under the working directory where named can find the keys for the zone. You will have many keys for your zones, and a separate directory for each will help you manage them. The auto-dnssec maintain statement tells named to automatically sign the zone and renew the signatures on the zone as they expire. Now run rndc reload zonename, and named will automatically sign and update that zone.

With auto-dnssec, named adds the DNSSEC resource records for the zone to the zone journal and increments the serial number. When you freeze or sync the zone for editing, named adds the current DNSSEC records to the zone just like any other dynamic changes. When you thaw the zone again, named updates those DNSSEC records to match your changes. Use dig to verify that the zone has DNSSEC records.

Signing Static Zones

Static zones are maintained via a zone file rather than through dynamic tools. They have a named.conf entry much like this.

zone "blackhelicopters.org" {

type master;

file "master/blackhelicopters.org";

};

One of the major points of a static zone file is that named can't update it. But signing a zone requires inserting DNSSEC signatures into the zone. How can named update a zone if it can't write to the zone file?

With a feature called inline signing, named does a little trickery. The named program copies the contents of the static zone into a dynamic zone, then signs and serves the dynamic zone. It never touches the original static zone file.

One consequence of inline signing is that the serial number served to the world will not be exactly the same as the serial number in your zone file. The inline signing process requires incrementing the serial number when changing signatures. You still must increment the serial number in your zone file for named to recognize changes, however. From the administrator perspective, nothing changes.

To create the files needed for a dynamic zone, the user running named must have write permissions on the directory containing the zone file. The user does not need write permissions on the zone file itself.

To enable DNSSEC on a static zone, create a KSK and a ZSK as I covered in Chapter 7, then edit the zone's named.conf entry.

zone "blackhelicopters.org" {

type master;

file "master/blackhelicopters.org";

inline-signing yes;

key-directory "keys/blackhelicopters.org";

auto-dnssec maintain;

};

This looks much like the configuration for the dynamic zone, except for the inline-signing option. Configure the zone and run rndc reload zonename. You should suddenly see five files for your zone in the zone file directory.

- filename is the original text zone file, unmolested by named

- filename.jnl is the journal for the named-created dynamic zone

- filename.jbk is a temporary file for the dynamic zone

- filename.signed is the signed zone

- filename.signed.jnl is the journal for the signed dynamic zone.

These files are the first indicator that auto-dnssec is working. Again, use dig to verify that DNSSEC signatures appear in your zone.

Publish DS Records

Now that your zone is signed, it's time to publish your DS records. I covered generating DS records from a zone's Key Signing Key in Chapter 7, and Chapter 3 discusses the three places where you can publish them (the domain registrar, the RIR, and the DLV). Go to your account at the appropriate registrar, paste your DS keys into the web form, and submit your work.

Most DS record updates propagate to the higher-level DNS servers in 24 hours or less. Once that change happens, use dig to verify that third-party validating nameservers see and validate your signatures, as discussed in Chapter 5.

Congratulations! You now have DNSSEC running correctly on one zone. Now go sign the rest of them.

NSEC3 Signatures

By default, BIND generates NSEC signatures. If you want NSEC3 on a zone, the zone must use an NSEC3-capable signing algorithm such as RSA/SHA-256 and you must tell named to use NSEC3 for this zone. Upgrading a zone's signatures to NSEC3 is a one-time operation that has a negligible ongoing performance impact.

NSEC3 computes signatures with a salted hash. A salt is a value added to a plaintext value before the hash is computed, to increase the difficulty of finding a collision useful to an attacker. Provide a salt of up to eight hexadecimal digits and the name of the zone. You don't need to remember the salt, as

Use rndc to change signatures to NSEC3. You'll have to include a few values that tell named how to create the hash. The –nsec3param argument tells rndc that the following values are for computing NSEC3 hashes. The next three flags represent the NSEC3 hash algorithm, special flags used for the hash, and how many times the hash should be computed. Always use 1 0 10 for these flags, as fewer aren't secure enough and more aren't any more secure. Then you provide a salt and the name of the zone. Remember, the salt is up to eight hexadecimal digits.

$ rndc signing –nsec3param 1 0 10 salt zonename

For example, to implement NSEC3 records for michaelwlucas.com, using a salt of BADCODE1, I would run:

$ rndc signing -nsec3param 1 0 10 BADC0DE1 michaelwlucas.com.

request queued

Also use rndc to verify that the zone has NSEC3 records.

$ rndc signing -list michaelwlucas.com

Done signing with key 23085/RSASHA256

Done signing with key 48082/RSASHA256

The contents of your zone are now more difficult for intruders to discover. Take a moment. Bask in your success.

The NSEC3 salt is public information – you can get the salt from the NSEC3 record itself. This means that an intruder can eventually compute the contents of your obscured zone. Change your salt every time you rotate your ZSK.

Now let's see what to do when DNSSEC doesn't work.

Chapter 9: Debugging DNSSEC

If you configure everything correctly, clients will be able to validate your DNSSEC. If you do something wrong and your DNSSEC doesn't validate, your domain will disappear from the Internet. This will make you popular. ("Popular" is the word they use when everybody wants to talk to you, isn't it?) Start debugging DNSSEC by determining if it's really a DNSSEC issue.

Check Your Network

First, your network might be broken in such a way that it won't pass DNSSEC packets. This would reveal itself as a broad DNSSEC failure, rather than a failure on a specific site. As mentioned in Chapter 1, this is probably because a naïve packet filter or firewall has decided that DNS transactions must only use UDP, impose a maximum size on a DNS exchange, or impose some other limit that complies with DNS protocol standards set in RFC 1035 in 1987, but no longer applies after the RFC 2671 updates in 1999.

Double-check your network's ability to pass modern DNS traffic. Use the OARC DNS Reply Size Test Server at https://www.dns-oarc.net/oarc/services/replysizetest. You could also run dig against a large zone and ask for lots of information (dig paypal.com any). Force a TCP response by adding the +tcp flag (dig +tcp paypal.com any). Use these tests from various spots on your network until you identify the problem.

If the test indicates that your nameserver suffers from improper packet filtering, stop everything. DNSSEC will not work until your underlying network supports it. Harsh? Yep. But that's life.

I'm going to assume that your validating resolver works, and that you get DNSSEC-secured responses on zones like isc.org and paypal.com. You're troubleshooting a specific DNSSEC issue, not a broad DNSSEC failure. If you can't get valid DNSSEC on any domain from your DNSSEC resolver, go back to Chapter 4 and try again.

DNSSEC States

If your network works, but specific DNSSEC queries fail, then you have a DNSSEC-specific problem. DNSSEC responses have three possible states: secure, insecure, and bogus. Each of these has separate causes and symptoms.

Secure zones have working DNSSEC. A random DNSSEC-aware resolver can validate it.

Insecure zones do not have working DNSSEC. Old-fashioned DNS data is insecure. So is signed data not part of the Chain of Trust. The resolver will return an answer to the client, but won't label it as authentic.

Bogus zones are signed, but the signatures are not valid. The resolver checks the signatures and determines they're invalid, so the resolver reports a SERVFAIL error. Maybe there's DS records in the parent, but the zone isn't signed with a matching key or isn't signed at all. Maybe the signatures have expired. Bogus hosts and zones disappear from the Internet for all clients of validating resolvers.

Is It DNS or DNSSEC?

Always remember that you can only have a DNSSEC issue when trying to resolve a DNSSEC-protected zone with a DNSSEC-aware resolver. If either the target zone or the resolver doesn't do DNSSEC, it's not a DNSSEC problem. It's a good old-fashioned DNS problem.

Many issues can remove DNS entries from the Internet, from typographic errors in zone files to server configuration problems. A DNSSEC error can be easily differentiated from these more familiar DNS errors by checking to see if the problem disappears when you disable DNSSEC validation. For example, one of my test domains has disappeared from the Internet. Running dig against a DNSSEC-validating resolver seems to bear this out.

$ dig absolutebsd.com @dns1.michaelwlucas.com

…

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42730

…

;; QUESTION SECTION:

;absolutebsd.com. IN A

The important thing here is the SERVFAIL error. You've asked your recursive server for an answer, and the recursive server tells you that the authoritative server cannot give one. The dig output includes your question, but there's no data in the answer section.

I could scurry around checking error logs and directly querying the authoritative servers, but let's first verify this is a DNSSEC error. Repeat the same query, against the same recursive server, but add the +cd option to disable DNSSEC checking.

$ dig absolutebsd.com @dns1 +cd

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5938

…

;; QUESTION SECTION:

;absolutebsd.com. IN A

;; ANSWER SECTION:

absolutebsd.com. 3317 IN A 192.150.247.34

We quickly got an answer this time. If the query fails with DNSSEC enabled, but succeeds without DNSSEC, your DNSSEC data is bogus. This is not an error on the protocol's part – if your DNSSEC keys are wrong, or your signatures have expired, or any number of other problems have happened, then the resolver is supposed to reject the data as bad. That's the purpose of DNSSEC.

More insidious is a signed zone where there's no path between the Chain of Trust and the zone KSK. The data is insecure – the ad flag is not set in the response, so there's no security protection. The resolver still returns an answer, however.

If your zone is either insecure or bogus, you need to fix your DNSSEC. Let's look at a few different tools that identify the problem.

Web Tools

My first stop when debugging DNSSEC issues is Sandia National Laboratories' DNSViz, at http://dnsviz.net. This is a fantastic web-based DNSSEC diagnostic tool. Enter your troubled domain name and hit "Analyze." After a couple of minutes, you'll get a diagram of the Chain of Trust, composed of a series of circles and arrows with a paragraph on each one. At the top you'll see circles representing the root KSK and ZSK, with an arrow leading from one to the other. Mouse over either circle and you'll get a pop-up box giving details about the key. The last line in this pop-up is either secure or bogus. The root KSK signs the ZSK, which in turn signs the DS record for the .com zone.

DNSViz walks through all of the zones above yours, with an arrow leading from one key or record to the next. Follow them down. If your zone is secured by a DS record in its parent zone – that is, if you entered your DS record at your registrar – then these arrows should lead down to your domain at the bottom.

If your domain is secured via the DLV, you can expect the Chain of Trust from the root to end in a NSEC3 record in your parent domain that proves that DS records for your domain do not exist. Next to the root zone Chain of Trust, you'll see the trust anchor for the DLV. If your zone is signed by the DLV, you'll see a second Chain of Trust above your domain.

How can you tell where the break is? A red arrow between circles indicates a non-matching signature. Red circles around zone entries or keys indicate that those records are invalid. Look for the red arrow, and look around it for the problem.

In this particular instance, the DLV said that the KSK for this zone was key ID 27600. The KSK on my server was key ID 56976. The DNSSEC validation system caught that mismatch and threw away the data.

The easiest way to learn what you're looking at is to try DNSViz with a known good domain and a known bad domain. Go to the web site and enter a domain that has good DNSSEC, such as isc.org. See how the Chain of Trust works. Mouse over some of the circles, and you'll see each key involved in the chain. The ISC is interesting in that they keep DS records in both their parent zone and in the DLV.

Figure 9-1: DNSVis on isc.org

Now use DNSViz to look at the domain dnssec-failed.org.

Figure 9-2: DNSViz on dnssec-failed.org

This zone is deliberately broken – the DS record in the .org zone does not match the DNSKEY record in the zone. You can see the trailing dotted line for the invalid key, and the KSK actually on the authoritative server sits off to the side, separated from the Chain of Trust. DNSViz gives a clear graphical representation of the problem.

For an alternate view of DNSSEC successes and failures, look at http://dnssec-debugger.verisignlabs.com. This Verisign site presents a text-based report on every step of the DNSSEC validation cycle. Successful steps in DNSSEC validation get green checks, while problems get a red X. Unfortunately, as of this writing the Verisign debugger does not check the DLV, which limits its usefulness for now.

Debugging with dig

Who wants to debug a crypto problem with a friendly web site wizard? Web-based debugging tools are for DNS administrators less awesome than you. Real DNSSEC debugging needs only dig and date(1).

Remember, a successful DNSSEC dig result shows the ad flag.

$ dig www.michaelwlucas.com

…

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

My resolver validates the DNSSEC on this zone.

Digging a hostname or an IP address returns a brief answer, usually only the IP or hostname. To debug DNSSEC, you need to see the RRSIG records related to the response. The only way you can determine if the signature is expired, not in the Chain of Trust, or just plain wrong, is if you find the record and read it yourself. Add +dnssec to your dig command to display those records. If bogus data prevents your resolver from displaying the result, add the +cd flag to show the bogus data.

$ dig www.michaelwlucas.com +dnssec +cd

…

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 7

…

;; ANSWER SECTION:

www.michaelwlucas.com. 6918 IN A 192.150.247.34

www.michaelwlucas.com. 6918 IN RRSIG A 7 3 7200 20130306202645 20130204193721 18764 michaelwlucas.com. b1EidXqS3M7Z2YRTC…

I've greatly trimmed this for brevity. You'll also get the nameservers for this zone, and their RRSIG record, and the IP addresses for those nameservers with their RRSIG record. If any of these signatures are wrong, DNSSEC validation fails.

If you want to follow the chain of DNS records from the root zone down, use the +trace option. I'm not going to demonstrate that here because it would take up several pages for things you've already seen before, but try it on your own. You'll get responses from the root servers, the domain's top-level servers, all the way down to the client, and can peruse it at your leisure.

Now let's look at the two failure modes and their most common causes.

Insecure Zone

If your signed zone does not validate, but the resolver still returns an answer, you almost certainly have a DS record mismatch. The DS record in your parent zone does not match the KSK in the zone. You can verify this with dig or DNSViz.

Key Verification

Get the key ID for the troubled zone from the RRSIG record.

www.michaelwlucas.com. 6918 IN RRSIG A 7 3 7200 20130306202645 20130204193721 18764 michaelwlucas.com. b1EidXqS3M7Z2YRTC…

The bolded value, after the dates, is the key ID. This signature was created with key 18764. Now let's look at the keys actually in the zone.

Request the DNSKEY record for the troubled zone, and add the +multi option so that dig will decode more of the records for you. (The +multi option also breaks the record up into multiple lines, to make presentation easier, so don't be surprised when the output looks different.)

$ dig michaelwlucas.com +cd +multi dnskey

…

michaelwlucas.com. 7200 IN DNSKEY 257 3 7 (

AwEAAaI+UG4TzleOPpoN57cklShnK3SbN5fRYGRUG5j3

…

) ;  KSK; alg = NSEC3RSASHA1;  key id = 31650

michaelwlucas.com. 7200 IN DNSKEY 256 3 7 (

AwEAAdq5cgFrK8lQVmbVXL/d6IF6RZJFeUBVt4YFU1rA

…

) ;  ZSK; alg = NSEC3RSASHA1;  key id = 18764

The second DNSKEY record is the  zone signing key, and has  key ID 18764. That matches the RRSIG on the record. The first DNSKEY record is the  key signing key,  key ID 31650.

Now verify that the KSK matches the next link up in the Chain of Trust. How you do this depends on if your key is registered with the parent zone (either at a RIR or a domain registrar), or if it's published at the DLV.

Parent Zone Verification

The parent domain for the zone should have a DS record for michaelwlucas.com with key ID 31650. Let's verify this. The dig command knows that the DS record for a domain appears in the parent domain, so I can just ask for the record without specifying a nameserver.

$ dig michaelwlucas.com ds

…

michaelwlucas.com. 86400 IN DS 12088 5 2 BF258…

michaelwlucas.com. 86400 IN DS 12088 5 1 CB264…

The DS records in .com for michaelwlucas.com are for a key signing key with ID 12088.

The key ID in the parent zone, 12088, is not equal to 31650, the KSK used on the zone itself. This breaks the Chain of Trust. The zone will not validate. If this is your zone, either put KSK 12088 back in the zone or give your registrar the DS records for key 31650.

Verifying DLV Keys

Checking the DLV is easier than finding the root server. Rather than a DS record, the DLV uses a DLV record. Remember, domains in the DLV are subdomains of dlv.isc.org. Find the current authoritative servers for dlv.isc.org and query them for the current DLV record. (Don't ask a caching server, as they might have older data.)

$ dig michaelwlucas.com.dlv.isc.org dlv @dlv.sfba.sns-pb.isc.org

…

michaelwlucas.com.dlv.isc.org. 2644 IN DLV 12088 7 2 229C4…

michaelwlucas.com.dlv.isc.org. 2644 IN DLV 12088 7 1 E2BB2…

These DLV records are for key ID 12088. Again, this key isn't what's configured in the zone itself, so it won't validate.

Other problems can occasionally cause an insecure zone. Deviating from the DNS standards can cause weirdness, and weirdness can cause DNSSEC failures. Not including NS records for your subdomains causes validation failures. In short, cutting corners causes problems.

Bogus Zone

If a zone is bogus, the Chain of Trust is intact but the signatures on the zone do not validate. The most common culprit is incorrect system time, or the presence of a DS in the parent zone but no signature on the actual zone, but you might have an invalid signature.

One common mistake in initial DNSSEC deployments is having a DS record available in the parent zone before the zone is signed. If your parent domain has a DS record for your zone, but you haven't signed the zone yet, validating resolvers will declare the zone bogus. That's why I had you sign your zone before publishing the DS record.

Other problems are more subtle.

Date and Time Verification

Take another look at our RRSIG entry.

www.michaelwlucas.com. 6918 IN RRSIG A 7 3 7200 20130306202645 20130204193721 18764 michaelwlucas.com. b1EidXqS3M7Z2YRTC…

The first bolded item is the date and time that this signature expires. The second is the date that this signature becomes valid. These dates are in the format:

- four-digit year

- two-digit month

- two-digit hour, in 24-hour notation

- two-digit minutes

- two-digit seconds

All times are in UTC. This signature expires on 6 March 2013, at 08:26:45 PM UTC. It becomes valid on 4 February 2013, at 7:37:21 PM UTC. Now you can see why system time is so important; a resolver's clock that's off by a few hours can make valid signatures appear invalid. The more your clock is off, the more signatures you will falsely reject – or, if you're the authoritative server, the more clients will reject your data. Run network time protocol, and monitor it to be sure it keeps running.

If the failure isn't a timing issue, you might actually have invalid signatures on your zones. This is probably because the signatures on the zone don't match the actual data in the zone. You might have been compromised. Get out your calculator, because we're going to compute the proper signatures for 4096-bit keys.

Logging

Realistically, manually calculating and comparing signatures is a silly stunt. Let BIND tell you why it's declared data bogus with logging. BIND includes its own logging features. Configure a DNSSEC-specific log in named.conf.

…

logging {

channel dnssec_log {

file "working/dnssec_log" size 20m; 

print-time yes;

print-category yes;

print-severity yes;

severity debug 1; 

};

category dnssec { 

dnssec_log;

};

};

The first stanza creates a log called dnssec_log. It includes a  log file and limits its size to 20MB. named must be able to write to this file. When named writes to this log file, it will print the time, the category, and the message severity. BIND defines its own logging  severity levels. When the log reaches the maximum size, named will throw away the oldest data to make space for the new.

The second stanza tells named to send messages from the  dnssec category to the log defined above. BIND logs by categories, or predefined subsystems.

When a problem resists dig-based debugging, look at the error log. You can run tail –f /etc/namedb/working/dnssec_log while performing the query, or grep the log for the domain you tried to previously validate, and you'll see a message stating why validation failed. DNSSEC can fail in too many ways for me to enumerate all the error messages, but a search engine will lead you to any number of discussions about log entries for errors. Generally speaking, they all come down to descriptions of why the signatures don't match the zone keys and/or the data. For example, here's the log entry if I look up dnssec-failed.org.

18-Mar-2013 18:24:47.930 dnssec: info: validating @0x804296800: dnssec-failed.org DNSKEY: no valid signature found (DS)

If you need more detail, increase the severity debug level in named.conf. Debug level 2 gives me everything I could hope for, and level 3 gives me more information than I can cope with, but it's there if necessary.

Compile Your Zone

Sometimes, nothing else will do but to look at the zone file and see just what the heck you're serving the world. BIND's auto-dnssec uses dynamic zones, meaning that the live zone named uses is a binary data file. You cannot view the contents of the zone file. You could use dig to do a zone transfer, but that takes extra configuration. Besides, if you're debugging something truly weird, you'll want to see the zone before it travels through named.

Use named-compilezone(8) to make a text zone file from the binary zone data files. Use the –j command to include the journal file. The –f raw argument tells named-compilezone that it's reading a data file. Specify an output file with –o. Then give the name of the zone, and the signed zone file. With auto-dnssec, the signed zone file ends in .signed. All together, it looks like this.

$ named-compilezone –j –f raw –o outputfile zonename filename.signed

Suppose I want to compile the zone for michaelwlucas.com. My zone file is michaelwlucas.com.signed, and I want to dump it to the file /tmp/mwl.com. I would run:

$ named-compilezone -j –f raw -o /tmp/mwl.com michaelwlucas.com michaelwlucas.com.signed

zone michaelwlucas.com/IN: loaded serial 2013020408 (DNSSEC signed)

dump zone to /tmp/mwl.com...done

OK

The file /tmp/mwl.com contains the entire zone, including all RRSIG and NSEC records. Trawl through it and figure out what's wrong.

Now that you understand how to debug your DNSSEC services, let's see how to really mess them up with key rotation.

Chapter 10: Key Rollover

By now you have one or more zones secured with DNSSEC. You can ignore traditional zones forever, but DNSSEC takes a small amount of maintenance. The longer a key is used, the longer intruders have to break it. As computers become more powerful, key algorithms need updating. And there's always the risk that someone will steal your private keys. All of these problems have the same solution: replace your keys. This is called key rollover. You can rollover both KSKs and ZSKs, using slightly different processes.

Rollover Risks

As we saw in Chapter 9, either breaking the Chain of Trust or incorrect signing causes zone data to become insecure or bogus. Thoughtlessly changing a KSK or ZSK certainly risks breaking the Chain of Trust, rendering your data insecure. Having your zone become insecure isn't the worst thing that can happen – it's no worse than where you were without DNSSEC. But it's really easy to make your zone bogus during a key rollover. Proper planning and following the appropriate process greatly reduces your risks.

The goal in key rollovers maintaining a valid Chain of Trust. An RRset might have several signatures. If a nameserver can verify any one of those signatures through the Chain of Trust, the zone is secure. Extra signatures do not harm DNS or DNSSEC, they're irrelevant. Maintaining the Chain of Trust is complicated by DNS' caching nature. You must time everything so that resolvers don't try to use a key that has been removed or rolled from their cache.

Why not entirely avoid this risk? Just create the strongest keys possible, sign the zone, and never change the keys. That's possible. Some people do that. The longer your keys are in use, the greater the chance that someone can crack them. But most modern secure protocols change their cryptographic keys every so often. Commercial SSL certificates expire every year in part to reduce the risk of someone breaking your certificate's private key. (Yes, the other part is so that the certificate authority can extract more money from you. And Chapter 12 teaches you how to maintain DNSSEC-secured SSL certificates, usable by anyone at no expense.)

Some similar applications never change their keys. An average Secure Shell (SSH) server generates a keypair when it's installed, and you never change that key. That's common practice. But you should consistently update and patch your SSH server to eliminate security flaws. And every so often, one of those updates will add a new algorithm and deprecate an old one. Plus, a SSH server on the naked Internet gets replaced, upgraded, or penetrated and the hard drive reduced to bare metal every few years. (With virtualization, I expect that we'll see more operating system instances surviving longer, and changing SSH keys every few years will become an established part of system maintenance.) I manage zone files that have been in continuous use since 1995. Depending on the cryptographic algorithm, a cellphone in 2013 can break a high-end keypair created in 1995.

Okay, fine, but do people really break key pairs? I mean, in the real world? The answer is: yes.

In 2012, a researcher made the news when he cracked Google's low-quality email security keys and used them to forge email from Google's founders. Keys of equal strength were in use at companies like eBay, Yahoo, Twitter, and Amazon. The keys had been created several years before, deployed, and forgotten.

You're better than that. The DNSSEC key rollover process is intended to avoid exactly this sort of threat.

Rollover Methods

The two standard methods for rolling over keys without interrupting security are double signature and pre-publishing. People have invented more rollover methods. Some of them are very useful for specific circumstances, while others are arguably superior, but these two fit almost everyone, are best understood, and BIND 9.9 supports them transparently.

Double Signature

In the double signature method, the zone is simultaneously signed with both the old and new keys. Recursive clients get both signatures. Both signatures are maintained in the zone until all caches have had enough time to expire the old public key from the zone and get a copy of the new key. Once that time passes, the old key and its signatures are removed.

This method is unquestionably safe. There's no risk of breaking the Chain of Trust. But it almost doubles the size of your zone. If you have a large zone, or you serve a lot of queries, that might cause you problems.

Pre-publish

When using pre-publish, you make the new DNSKEY record available before signing any RRsets. Once the key has had time to propagate to all client caches, named removes the old signatures and creates new ones with the new key.

The pre-publish method is more elegant than double signing. It doesn't double the size of your zone. It replaces signatures as they expire, rather than signing everything twice. But it's more complicated, and requires more intervention and scheduling. BIND 9.9 handles most of the scheduling automatically.

Rollover Method Recommendations

Best practice is to use pre-publish for ZSK rollovers and double-signing for KSK rollovers. The greater the number of bits in your key, the longer you can wait between rollovers.

Changing the KSK requires publishing your new DS records with your registrar, RIR, or the DLV. If you screw up, your corrections might take several days to percolate across the Internet. The safest thing to do is publish both keys, make sure the changes work, and only then remove the old key from the zone. As the KSK is only used to sign the DNSKEY RRset, double signing doesn't double the zone's size, it only adds an extra signature for the DNSKEY RRset.

You can realistically use a 2048-bit KSK for up to two years, although if you run a high-risk site you might want to rollover the key every year or so. I hope that sites that are the targets of persistent attacks, such as financial firms and government institutions, rollover their KSK at least every year.

Changing the ZSK is a purely internal matter, and requires no outside interaction. Best practice recommends using the pre-publish method in this case. BIND 9.9 actually completely automates ZSK rollovers if you pre-create the keys. You can safely use a 1024-bit ZSK for three months or so. If you're under constant attack, I'd suggest rolling the key every couple of months.

The key's lifespan is not the only important timing factor. The times in your zone file also play a part.

Key Lifecycle

Deploying rollovers means that each key has a lifecycle. At some point, the key is created. At another point, it's removed from use. For completeness, a key file notes the date it's created on. This isn't terribly relevant for DNSSEC, but it might be important for you later. ("Just when did I create that key, anyway?") For DNSSEC purposes, a key has four important dates: publish, activate, inactivate, and delete.

The publish date is the date the key can be made available to the world. The day a key's DNSKEY record appears in the zone is the publish date. If you don't specify a publish date, the key is published when you load it into named. In general, the publication date equals the creation date.

The activate date is the date that the key can first be used to sign RRsets. It doesn't mean that the key will be used immediately, mind you. If you're doing pre-publication rollovers, and no signatures are due for renewal, named won't use the key to sign until a signature needs renewal. But it's available for signing on the activate date. This is the first day of your key's lifespan. If you don't specify an activation date, named will use the key when you load it into the zone. The length of time between the publish date and the activation date varies depending on your key rollover method and the times in your zone.

The inactivate date is the date the key will no longer be used to create new signatures. Signatures using that key might still be drifting around in client caches, but that's okay. The key remains in the zone, and those signatures will validate. For a 2048-bit KSK, the inactivate date should be no more than three years after the activate date. For a 1024-bit ZSK, the inactivate date should not exceed three months after the activate date.

On the delete date, the key is removed from the zone. The delete date depends on how quickly your zone expires from the caches of unrelated nameservers, as we'll see in the next section.

If you're using auto-dnssec, named handles all the key changes for you. It sees that a key is due for inactivation and the activation date for another key has arrived, so it shifts how it signs the zones. If you're rolling keys and signing zones manually, you need to add and remove the keys by hand. This manual work is a big reason why I recommend BIND 9.9, as it handles key rollovers for you. You still must create key files yourself. I'll cover automatically creating zone files.

Zone Times

Remember that zone data doesn't immediately change across the Internet. DNS clients cache answers according to the time-to-live (TTL) in the zone. We've all had to change the IP address of an important server and wait while the change propagated. You've probably had to log in late one night or on a weekend to make a DNS change, so that the whole world would have new data before the start of the next business day. Or you've had to explain to the boss that DNS caching means that a small part of the world would lose access to your site during a change.

Key rollovers aren't as bad as that. A validating resolver will validate any signature in the zone, as long as the associated keys are contained in the DNSKEY RRset and the signature on the RRset is valid. A zone can include multiple ZSKs or KSKs, and the resolver will accept a signature from any of them. So long as the resolver can build any Chain of Trust, the data is valid. This gives you more flexibility than changing the A record for your web server. But understanding the times in your zone is absolutely vital to a transparent rollover.

Your Zone's Time-To-Live

Before even considering key rollover, check the time-to-live on your zones. The time-to-live is the number of seconds that recursive DNS servers will cache data from your zone. Once the TTL expires, the nameserver discards the data and contacts an authoritative server to fetch new data. A zone gets time-to-live data from three places: either a leading $TTL, the SOA record, or a per-entry TTL. Consider the following zone file.

$TTL  7200

@ IN SOA ns1.michaelwlucas.com. dns.michaelwlucas.com. (

2013021001 3600 900 2419200  900 )

IN NS ns1.michaelwlucas.com

IN NS ns2.michaelwlucas.com.

www  3600 IN A 192.0.2.88

The  default time-to-live for the zone is optional. You'll see it on newer zone files, say, those less than ten years old or so. If there's no default TTL, the zone uses the  negative caching time from the Start Of Authority record. Individual resource records can have their  own TTL. In this zone, the default TTL is 7200, or 2 hours. The negative caching time is 900 seconds, or 15 minutes. The A record has a TTL of 3600 seconds, or 1 hour.

For key rollover purposes, the important TTL is the longest one in the zone. Our example zone's longest TTL is 2 hours. Whenever you need the TTL in rollover timing calculations, use the longest one.

Slave Expiration

The refresh, retry, and expire times in a zone control how often slaves attempt to update their copy of a zone. I'm certain that you remember exactly how these work, but for the few readers who set these times once, per the manual, and forgot about them, let's look at my SOA record again. I use the +multi dig option to show it in a more easily understood form.

$ dig michaelwlucas.com soa +multi

michaelwlucas.com. 7200 IN SOA blackhelicopters.org. root.blackhelicopters.org. (

2013031605 ; serial

 3600 ; refresh (1 hour)

 900 ; retry (15 minutes)

 2419200 ; expire (4 weeks)

7200 ; minimum (2 hours)

)

The  refresh time is how often a slave will attempt to update its copy of the zone. This SOA instructs the slaves to check for a new version of the zone every 3600 seconds, or one hour. The  retry time tells the slave how often to retry, if the first check fails. 900 seconds is 15 minutes. If the slave cannot reach the master nameserver for the initial check, it retries every fifteen minutes thereafter. Finally, the  expire time tells the slave when to discard its zone data and stop serving authoritative results for the zone. 2419200 seconds is 4 weeks. If my slave nameserver cannot contact the master within four weeks, it stops pretending that everything is okay.

The SOA times don't necessarily rule slaves, however. Modern nameservers use the NOTIFY protocol to tell their slaves that a zone has been updated and they should update their copy. The protocol doesn't know if a NOTIFY fails, though, so the slave always checks the master. The system log will show notify requests received from a master server. Changes theoretically propagate from masters to slaves within seconds. If the NOTIFY fails, then the nameserver falls back on the times in the SOA record.

I recommend that you verify that NOTIFY works, and that slaves quickly copy the changes. If you control both the masters and the slaves that's fairly easy. If you swap DNS service with a third party that might be more difficult, but I recommend only swapping critical backup services with people knowledgeable enough to troubleshoot with you.

Worst case; I can force a zone transfer for my domain by running rndc retransfer michaelwlucas.com. That's not ideal, of course. It means I have to do a bunch of stuff that resembles work, and it's work that the machine should do. But it might buy you time to investigate why your slaves aren't updating properly.

The most common reason I see for a slave server failing to copy a zone in a timely manner isn't a BIND, operating system, or hardware failure. It's that the master server has become non-authoritative for the zone. An error such as having a PRT record instead of PTR, or a AAA record instead of AAAA, will make the master server reject the zone. Always verify that a master server really is authoritative before suspecting your slaves. If your zone is broken, nothing you do to the slaves will help you.

The DNSSEC rollover timing standards tell us to consider the expire time in rollovers. Most of us consider a slave that doesn't update within the refresh time a serious problem, however. I wouldn't wait four weeks to debug slave zone transfers – I have the expire time that long just in case I'm traveling when something breaks.

For DNSSEC purposes, you care about the length of time your slaves need to update. If your slaves consistently and quickly update their zones, and you have the ability to force an update in case of unexpected error, then you can assume that your time to update your slaves is only minutes. Otherwise, you must use the refresh time from the SOA. For my zone, this would be two hours. If you want to be especially cautious, double that.

Parent Zone Propagation Time

If you need to rollover your KSK, then the time your parent zone takes to propagate changes through its network becomes important.

Most domain registrars, RIRs, and the DLV claim that changes will be active within 24 hours. Additionally, you must factor in the time those changes will need to propagate across the root servers. For example, when I want to rollover the KSK for michaelwlucas.com, I must look at the SOA for the parent domain, or .com.

$ dig com soa

…

;; ANSWER SECTION:

com. 705 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1361038877 1800 900 604800 86400

…

The com zone has a refresh time of 1800 seconds (30 minutes), a retry time of 900 seconds (15 minutes), and an expire time of 604800 seconds (1 week).

Personally, I expect that NOTIFY works between these servers, and that zone transfers will complete in far less than one week. I'm a trusting soul, however. More meticulous and cautious people could plan for one week to distribute updates to the .com zone, but if the .com zone didn't update for a week, everyone who registered a new domain in that time would riot. Once your domain is active on one .com nameserver, changes should be visible on all the others within 30 minutes.

Check the time for your parent zone. Don't assume that just because .com has an refresh time of thirty minutes, that all parent zones have the same expire time. Actually, don't even trust that the .com zone will have a thirty minute refresh time when you get around to performing a key rollover. Verify the current refresh time for yourself.

Recommended Zone Times

DNSSEC rollovers don't impose restrictions on the TTL in your zone, but rollovers go more smoothly if your times in your zone fall within certain limits.

The TTL on RRSIGs should be a few times longer than the TTL on resource records. If both the signatures and the resource records expire from caches simultaneously, this can cause additional load on the authoritative servers.

The inactivate date on a key should be at least the zone's maximum TTL before the key's delete date. Zone data can remain in a recursive nameserver's cache up to the maximum TTL. If you destroy the key before the data expires from the recursive nameserver's cache, the nameserver won't be able to validate the signature. The Chain of Trust will break.

RFC 4641 recommends making the zone expiration timer in the SOA record roughly one-third or one-fourth of the RRSIG TTL. Signatures are usually good for one month, so you might set the expire time to one week or 604,800 seconds. (Strangely enough, that's exactly what the .com zone uses.) When a zone is freshly signed, the slave servers need time to fetch the updated zone. If your slaves respond to NOTIFY messages, this should only take a few minutes. If you're stuck with using the refresh/retry/expire cycle, you might get in a state where the slave cannot update the zone, the signatures on the slave's copy of the zone expire, but the zone itself is still valid. DNSSEC-aware resolvers will declare results with expired signatures as bogus.

If the times recommended in RFC 4641 don't work for your environment, change them to suit you. Just remember how time affects signature renewals and key rollovers.

Dating Keys

The life cycle dates are stored in the key file. Let's look again at an existing key file.

; This is a zone-signing key, keyid 18764, for michaelwlucas.com.

; Created: 20130204203556 (Mon Feb 4 15:35:56 2013)

; Publish: 20130204203556 (Mon Feb 4 15:35:56 2013)

; Activate: 20130204203556 (Mon Feb 4 15:35:56 2013)

michaelwlucas.com. IN DNSKEY 256 3 7 AwEAAdq5cgF…

This key was created on February 4, 2013, according to the file. The publish and activate dates are identical to the creation timestamp, so named could use the key immediately upon creation. There are no inactivation or deletion dates, so this key is never automatically removed from the zone. Once you assign key inactivation and deletion dates, the file will contain those dates in the same format.

The dnssec-keygen(8) program has options to assign dates the key enters the lifecycle stages at key creation, while dnssec-settime(8) assigns and changes dates on existing keys. Both programs use identical options to set dates.

Time Formats

BIND's DNSSEC commands accepts dates and times in two different formats, either as a specific calendar day or as an offset from the moment you run the command.

Give dates and times with a four-digit year, two-digit month, and two-digit day. For example, 1 February 2013 would be 20130201. You can also specify a two-digit hour, minute, and second. If you want your key to expire on 14 March 2013, at 1:59:25 AM, use the date 20130314015925. (Which only goes to show that you can't really include pi in your date.)

If you don't care about the exact date a key rolls over, you can use offsets instead of dates. The DNSSEC commands let you specify a time like "3 months from now" or "2 weeks ago." To specify an offset, put a + or – in front of the desired offset. +3000 means "3000 seconds from now," while -5 means "5 seconds ago." To use a unit other than seconds, put an abbreviation for the time unit after the number. Use y for years, mo for months, w for weeks, d for days, h for hours, and mi for minutes. To give a time like "1 week and 1 day from now," use as +1w1d. The offsets use a 30-day month and a 365-day year without any leap years, leap days, leap seconds, or flying leaps.

Remember that DNSSEC uses Coordinated Universal Time (UTC), regardless of your local time zone. If you set the key to change from published to active at 1 April 2013, named will start to use the key at UTC midnight on that day. As I'm in Eastern Time, five hours before UTC, that key goes live for me at 7PM March 31.

Now that you know how to specify a time, let's attach those times to actions.

Setting Key Dates

The four key critical dates in a key's lifecycle are the publish date, the activation date, inactivation date, and deletion date.

Use –P to specify a key's publication date. The key becomes visible in the zone at this date.

Use –A to specify an activation date. After this date, named uses the key to renew signatures.

Use –I to specify an inactivation date. named stops renewing signatures with this key on this date.

Use –D to specify a key's deletion date. The key is removed from the zone on this date.

Combine these options to set all the dates for a zone. If you use -A +1mo –I 4mo –D 5mo, the key will get an activation date 30 days in the future, an inactivation date 120 days from now, and a deletion date 150 days from now. Remember, a "month" is always 30 days. As you don't specify a publication date, named can publish the key in the zone immediately.

Now let's actually change and set some dates in keys.

Changing Dates on Existing Keys

Use dnssec-settime to change the date on an existing key. If you create a key as advised in Chapter 7, the key has no inactivation or deletion date. Before you can rotate a key, you must assign those dates to the key. Suppose I want to stop signing with the key in 60 days, and delete it 30 days later. Here I change the times on the key 18764 for michaelwlucas.com.

$ dnssec-settime -I +2mo -D +3mo Kmichaelwlucas.com.+007+18764

./Kmichaelwlucas.com.+007+18764.key

./Kmichaelwlucas.com.+007+18764.private

dnssec-settime prints the name of the affected key files. If you look at the .key file, you'll see the new inactive and delete dates.

Now that this key has an inactivation date, you'd should learn how to do a rollover before that date arrives.

Rolling Over a ZSK

Rolling over a zone signing key is a purely internal operation and requires no interaction with the outside world. That makes it somewhat simpler than a KSK rollover. Start your ZSK rollover by creating keys for future use.

If your zone file uses the recommendations earlier in this chapter, with the times in your SOA being neither too short nor too long, you can safely rollover your keys every three months. Publish the key one month before you start signing with it, and delete the key one month after you stop signing with it. This gives plenty of time for caches around the world to get up-to-date data. I'll use this timing in the following examples. If you don't follow the recommendations for timing on your SOA, you'll need to verify that you rollover your ZSK slowly enough that cached data won't break the Chain of Trust.

To rollover a ZSK, you must create the new keys and tell named about them.

Creating Rollover ZSKs

Earlier (in "Changing Dates on Existing Keys") I assigned key 18764 for michaelwlucas.com an inactivation and a deletion date. I need to create a successor to key 18764. I could use dnssec-keygen's date functions to assign publication and activation dates, but dnssec-keygen provides -S specifically for creating a successor key. Using the –S argument with an existing key file tells dnssec-keygen to make a key with an activation date equal to the previous key's inactivation date, and a publish date preceding that by 30 days. A successor key uses the same algorithm and bits as the key it replaces.

Let's look at the timing here. In the previous section, I gave key 18764 2 months until inactivation. The new key will be used for 3 months, so it goes inactive 5 months from now. Similarly, key 18764 is deleted in 3 months. The new key needs deletion 3 months later than that, or 6 months from now. Here I explicitly create a successor to 18764 that goes inactive in 5 months and gets deleted in 6 months.

$ dnssec-keygen -S Kmichaelwlucas.com.+007+18764.key -I +5mo -D +6mo

Generating key pair....................+++

Kmichaelwlucas.com.+008+34397

I've created key 34397 for this zone. As it's a successor key, it has the same algorithm and number of bits as 18764. When key 18764 becomes inactive, named automatically starts signing RRsets with 34397. You could stop here, but I recommend creating a couple years of keys at a time.

$ dnssec-keygen -S  Kmichaelwlucas.com.+008+34397 -I  +8mo -D  +9mo

Generating key pair............

Kmichaelwlucas.com.+007+35054

This is almost exactly the same command, but I'm creating a successor to key  34397 rather than 18764. I increment both the  inactive and  deletion dates by three months, and thereby create key 35054.

Repeat this, always incrementing the inactive and delete date by 3 months and creating a successor to the previous key. Eventually, you'll get a couple years ahead.

$ dnssec-keygen -S Kmichaelwlucas.com.+008+09425 -I +26mo -D +27mo

Generating key pair............+++ .+++

Kmichaelwlucas.com.+007+58007

I've created keys to rollover my zone for the next 26 months. Surely that's far enough?

Key creation is ripe for automation. Many people have written scripts to automatically create new ZSKs. Supposedly BIND 9.10 will automatically create keys for you, and it should escape ISC within the next couple of years. If you create keys by hand, I recommend that you create your last key without an inactivation date.

$ dnssec-keygen -S Kmichaelwlucas.com.+008+58007

Generating key pair...................+++ ....................+++

Kmichaelwlucas.com.+007+56228

If rollover is so important, why would you create a final key without an inactivation date? If you're creating keys by hand, you have to prepare for the possibility that things will go wrong. This book is three weeks behind schedule because halfway through writing it, I spent a week in the hospital for an emergency appendectomy, another week at home recovering, and another week undoing what I'd done the previous week when I thought my mind was clear but I was actually fuzzy from lingering anesthesia. Had my keys required updating during this window, my domains would have either vanished or become completely bogus. Have your calendaring software alarm you or your DNS team a few months before you run out of keys, so you can investigate upgrading to newer software that will create keys for you.

Loading Keys Into named

Once you have keys for the future, you need to tell named about them. Use rndc loadkeys and the name of the zone.

$ rndc loadkeys michaelwlucas.com

Check the system log for any error messages. Alternately, you can restart the nameserver. Also, if you're using NSEC3, this is a good time to change your salt.

That's it! Your nameserver now automatically performs key rollovers and updates signatures with the correct key.

Checking Rollovers

Everyone with more than a week's experience in information technology knows that trusting the software is a good way to get woken up at stupid-o-clock. (Stupid-o-clock is not a defined standard. But it should be.) How do you verify that the nameserver has actually performed the rolloved?

The key currently used in our running example is key 18764. The next key slated for use is key 34397. Look at the key file for 34397 to see the dates the key changes from one use to another.

; This is a zone-signing key, keyid 34397, for michaelwlucas.com.

; Created: 20130217164204 (Sun Feb 17 11:42:04 2013)

; Publish: 20130319164055 (Tue Mar 19 12:40:55 2013)

; Activate: 20130418164055 (Thu Apr 18 12:40:55 2013)

; Inactive: 20130717164204 (Wed Jul 17 12:42:04 2013)

; Delete: 20130816164204 (Fri Aug 16 12:42:04 2013)

michaelwlucas.com. IN DNSKEY 256 3 7 AwEAAci2mnVM+K…

We will use these dates to check rollovers.

Checking Publication

On 19 March 2013, a little after noon UTC, my nameserver should publish key 34397 in the zone michaelwlucas.com. It's not supposed to sign anything with that key until 18 April 2013. Between those dates, ask the master nameserver for the keys in the zone.

$ dig michaelwlucas.com @localhost DNSKEY +multi

…

;; ANSWER SECTION:

michaelwlucas.com. 7200 IN DNSKEY 256 3 7 (

AwEAAdq5cgFrK8lQVmbVXL/d6IF6RZ…

…

) ; ZSK; alg = NSEC3RSASHA1; key id = 18764

michaelwlucas.com. 7200 IN DNSKEY 257 3 7 (

AwEAAaI+UG4TzleOPpoN57cklShn…

…

) ; KSK; alg = NSEC3RSASHA1; key id = 31650

michaelwlucas.com. 7200 IN DNSKEY 256 3 7 (

AwEAAci2mnVM+KDMQVXAqrnfGQATP

…

) ; ZSK; alg = NSEC3RSASHA1; key id = 34397

The zone shows has three keys. Key 31650 is the key signing key, but keys 18764 (the old ZSK) and 34397 (the new ZSK) are published zone signing keys. BIND picked up the new key and rolled it into the zone. Is it used to sign anything, though? Let's check.

$ dig michaelwlucas.com @localhost rrsig | less

Review the output. If RRSIG records include the string 34397, named activated this key. If you find key 31650 still being used, the key didn't rotate properly. Check your dates. You can verify that signatures exist with the current key by searching for 18764 instead.

Checking Activation

On 18 April 2013, at 12:40PM UTC, the key should activate. I check the zone shortly after that time. Both DNSKEY records will appear in the zone, but as time passes, I should see more and more RRSIG records signed with key 34397.

$ dig michaelwlucas.com @localhost rrsig | grep 34397

michaelwlucas.com. 7200 IN RRSIG A 7 2 7200 20130518200020 20130418194505 34397 michaelwlucas.com. emCxEi…

This is the first of several records signed with key 34397, so named apparently activated the key correctly. But we should also still have RRSIG records signed with key 18764, as named should only renew signatures with the new key as they expire.

$ dig michaelwlucas.com @localhost rrsig | grep 18764

michaelwlucas.com. 7200 IN RRSIG DNSKEY 7 2 7200 20130419191427 20130320181427 18764 michaelwlucas.com. QVbpunv08rdyDh…

I'm checking this signature on 18 April. This signature expires on 19 April. Everything seems okay.

Checking Inactivation and Deletion

Verifying that a key is not used for signatures is similar to verifying that it's used for signatures. Look for RRSIG records in the zone and see if named signed them with the key in question. Inspect the creation and expiration dates. Any new signatures should include only the new key.

To determine if named deleted a key from the zone, check the DNSKEY records for the zone. It's exactly like checking to see if a key was added.

Testing Rollovers

Your first key rollover can be worrisome. Will BIND actually do the right thing, or will your organization disappear from the Internet? Will there be outages? Annoyed users? Or, worse still… meetings? Test what BIND does by duplicating your nameserver on a virtual machine. Shut off the nameserver, adjust the system clock to a future date when BIND should have done something, and restart named. See what happens.

KSK Rollovers

A key signing key rollover is a little different than a zone signing key rollover. The biggest issue is that for a KSK rollover, you must update your parent zone with the new key. This means interacting with a domain registrar, DLV, or RIR. You cannot control when the parent domain will publish the key, and you have absolutely no control over how the key will propagate across the Internet. Top-level domains like .com and .org usually propagate quickly, but every time I count on that happening, they have a problem. I recommend caution when performing KSK rollovers.

KSKs can use the double signing rollover method. KSKs are only used to sign the RRset. Rather than doubling the size of the zone, as double signing does with ZSKs, double signing the ZSK itself only adds one extra RRSIG record.

To perform a KSK rollover you must generate a new KSK, sign your zone with it, register the new KSK with your parent zone, verify that the new key is available globally, and remove the old key from the parent domain. I'm rolling over the key for my zone absolutebsd.com.

Create the New KSK

Creating a new KSK is exactly like creating any other KSK, as Chapter 7 discusses.

$ dnssec-keygen –a 8 -f KSK -b 2048 absolutebsd.com

Generating key pair.......++ ...++

Kabsolutebsd.com.+008+07833

Key 07833 is the new KSK for my domain. Now load the new key into the zone with rndc loadkeys zonename or restart your nameserver.

$ rndc loadkeys absolutebsd.com

This key should now appear in the zone. Verify the key's presence with dig before proceeding.

Notify Parent Domain

Extract the DS record from your new key.

$ dnssec-dsfromkey Kabsolutebsd.com.+008+07833

michaelwlucas.com. IN DS 7833 9 1 F3616D…

michaelwlucas.com. IN DS 7833 8 2 09CDA6…

Feed the new DS records to your parent domain. Go to your registrar, RIR, or DLV account. Follow the exact same procedure you used to enter your key the first time. Once the parent domain accepts the new DS record, wait for the record to become visible in the parent zone.

Remove Old DS Record From Parent

Once the new key starts appearing in the parent zone or the DLV, go to your parent domain account and remove the old DS record from the zone.

Do not remove the old key from your zone. Remember that DNS data takes time to propagate, and caches need time to expire old data.

When To Remove Old KSK?

Remove your KSK when you are confident that all of the cached records for both your parent zone and your zone are no longer available.

Add the expire time for your parent zone to the parent zone's time-to-live. Do the same for your domain. The longer of the two results is the length of time someone might conceivably try to use the old KSK to validate your zone. I recommend adding a little extra time, just in case. Use dig on unrelated DNSSEC-aware nameservers to verify that others see and use the new KSK.

If you're brave, you might use dig to see if the parent zone has populated early. It generally does. But keep in mind that many parent zone nameservers have multiple physical servers behind their hostnames, and use anycast routing to send users to the nearest available server. The f.gtld-servers.net that you check for your DS records will not be the same server as the f.gtld-servers.net that a user in another part of the country or world will check. If your closest instance of that parent zone server has the correct data, but another elsewhere does not, you'll get intermittent DNSSEC outages of your domain depending on which parent zone server a user happens to use. Patience prevents intermittent outages.

If your parent zone has an expire time of one week and a time-to-live of two days, I would probably inactivate the key in two weeks and delete it in one month.

$ dnssec-settime -I +2w -D +1mo Kmichaelwlucas.com.+007+27600

Again, this is just like setting an expiration on a ZSK, except you don't have to worry about a successor key. You've already created and deployed it.

Emergency Key Rollovers

Key rollovers aren't that hard once you've done a few. Annoying, perhaps, but not hard. But what happens if an intruder compromises the private key of your KSK or ZSK? They can create DNS entries that validate with DNSSEC, but aren't legitimately yours. The intruder can pretend to be you for as long as the validating clients can build a Chain of Trust with the compromised key.

In this event you must make a choice. You can break the Chain of Trust, rendering your zone insecure. Or you can live with the risk while performing a key rollover as quickly as possible. In either case, replace all keys as soon as possible.

If you suffer a compromise on any system (not just your DNS server), notify your organization's computer security team. Your security team can help you secure the system against further intrusions. You don't want to do an emergency key rollover only to find that the intruder has your new keys as soon as you create them!

Once you have a secure working environment, generate new keys for your zones. If you know that an intruder stole one private key from your system, assume the intruder has every private key on that machine. Create new KSKs and ZSKs for every zone. Edit your zones to reduce the TTLs on all your data. You want client nameservers to start flushing your data from their caches as soon as possible and as quickly as possible.

Proceed with a normal ZSK and KSK rollover, but be aggressive in how quickly you expire your compromised keys. If you don't have control of your secondary nameservers, contact their administrators and ask them to run rndc retransfer zonename. Watch your parent domain to see when they distribute your new DS records, and aggressively inactivate your keys.

Key Management

When you have many domains, you might well find yourself overwhelmed by the number of key files drifting around your system. Even the strictest directory hierarchy proves insufficient for organization. In this kind of environment, you might find an electronic key logbook useful. On a wiki, spreadsheet, or whatever format you prefer, record the zone name, the date of creation, the key ID, algorithm, key size, the purpose of the key, the various DNSSEC lifecycle dates, and the creator's name. After a few rollovers, checking the logbook will take less time than examining key files.

You now have everything necessary to secure a basic DNS setup. But the people who can get complicated stuff done are always asked to do more. In the next chapter, we'll cover delegating DNSSEC.

Chapter 11: Delegations and Islands of Trust

If you run a large zone, you probably have subdomains. You might even delegate some of those subdomains to other networks. This is especially common in Internet Service Providers, who receive address space to delegate in turn to their customers. Companies delegate subdomains and internal address space to branch offices. If you're the lucky one managing DNS at the head office or ISP, you must be able to delegate zones to your clients.

Sometimes organizations want completely private zones. Many companies use RFC1918 space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) on their private networks, or use internal top-level domains. You'll want DNSSEC securing your private zones as well as your public zones. You cannot insert these to either the parent domain or DLV trust anchors, so you must create your own trust anchors. Those trust anchors require delegations, so we'll start there.

Subdomains

A subdomain is a child domain of another zone. My domain michaelwlucas.com is a subdomain of .com. I could set up my own subdomains like office.michaelwlucas.com and home.michaelwlucas.com, give them their own nameservers, and have machine names like comfychair.home.michaelwlucas.com. But that would be too much like work for my home.

Subdomains all need NS records pointing to their nameservers. It's okay to have the same nameservers serve the child and parent zones, but the child zone needs nameserver records. If you have a zone like michaelwlucas.com, and you want to have separate records within home.michaelwlucas.com and office.michaelwlucas.com, you must include NS records for those subdomains in the parent domain. You can get away with this when you're not using DNSSEC, because DNS is forgiving. DNSSEC breaks spectacularly without NS records for subdomains, and can become really weird if the NS records in the subdomain don't match those in the parent domain.

Delegating Subdomains

One of the most common uses for subdomains is delegating reverse DNS for address space. A global company might use 10.0.0.0/8 for internal addresses, and assign various /16 or /24 blocks to different divisions or locations. (They might assign blocks of other sizes using RFC2317 techniques, but doing so here would unnecessarily complicate the examples.) Such an organization has an internal authority server responsible for maintaining NS records for each block of addresses. If you were stuck running this root server, how would you perform this delegation?

You need a zone file for 10.in-addr.arpa. This zone file doesn't need to contain any A records, but does need NS records for the various delegations. Here's a zone file with two delegations.

$TTL 7200

@ IN SOA ns1.michaelwlucas.com. dns.michaelwlucas.com. (

2013021805 3600 900 3600000 900 )

IN NS ns1.michaelwlucas.com.

IN NS ns2.michaelwlucas.com.

0.0.10.in-addr.arpa. NS ns10.michaelwlucas.com.

0.0.10.in-addr.arpa. NS ns11.michaelwlucas.com.

0.0.10.in-addr.arpa. NS ns12.michaelwlucas.com.

1.10.in-addr.arpa. NS ns20.michaelwlucas.com.

1.10.in-addr.arpa. NS ns21.michaelwlucas.com.

1.10.in-addr.arpa. NS ns22.michaelwlucas.com.

The zone 0.0.10.in-addr.arpa, or 10.0.0/24, is served by ns10, ns11, and ns12. The zone 10.1/16 is served by ns20, ns21, and ns22. Recursive clients will proceed to the next nameserver in line.

If the master nameserver for 10.0.0.0/8 is also authoritative for some delegations, it must have a similar entry. My machines ns1 and ns2 are authoritative for 10.0.0.0/8, but also for 10.0.1.0/24. My zone for 10.in-addr.arpa needs NS entries like below.

1.0.10.in-addr.arpa. NS ns1.michaelwlucas.com.

1.0.10.in-addr.arpa. NS ns2.michaelwlucas.com.

Your server also needs a zone for 1.0.10.in-addr.arpa, of course.

Once all of your subdomains have proper delegations in the nameserver, you can look at adding DNSSec to your subdomains.

Adding DNSSec to Delegations

Before you try to configure DNSSEC for subdomains, make sure it works on your top level domain. Verify that unrelated resolvers can build the Chain of Trust for records. If I want to secure subdomains of michaelwlucas.com, I must first secure michaelwlucas.com. The Chain of Trust only works if all the parent domains above a domain work.

If you're delegating private address space or a private domain, as in the previous example, don't worry about the Chain of Trust yet. Create a KSK and ZSK for your top-level zone, such as 10.in-addr.arpa, and add them to the zone. We'll create a Chain of Trust for this in "Islands of Trust" later this chapter.

Now create a KSK and ZSK for your subdomain. Here I create keys for my delegation of 10.0.1.0/24.

$ dnssec-keygen –f KSK –a 8 –b 2048 1.0.10.in-addr.arpa.

$ dnssec-keygen –b 1024 –a 8 1.0.10.in-addr.arpa.

Add the keys to your delegated zone, then create a DS record from your subdomain's KSK. Here I create a DS record for my zone from key 57121.

$ dnssec-dsfromkey K0.0.10.in-addr.arpa.+008+57121

Keep the generated DS records handy.

Now the fun bit. Previously, you needed to get your parent domain to include the DS records for your domain. Now, you are the parent domain. You get to experience both sides of the job. Lucky you! Go to the parent zone, and copy the DS records created by dnssec-dsfromkey verbatim into the zone, as well as the nameservers for the zone.

0.0.10.in-addr.arpa. NS ns1.michaelwlucas.com.

0.0.10.in-addr.arpa. NS ns2.michaelwlucas.com.

0.0.10.in-addr.arpa. IN DS 57121 8 1 B72C…

0.0.10.in-addr.arpa. IN DS 57121 8 2 BFD32…

The IN designator marking a record as Internet-class data is the default these days, but dnssec-dsfromkey includes it by default. You can remove it if you like, but the IN won't hurt anything. Once you add these records to the parent zone, reload it.

To verify the DS records are present in 10.in-addr.arpa, either compile the zone or use dig.

$ dig 10.in-addr.arpa. @localhost axfr | less

…

0.0.10.in-addr.arpa. 7200 IN NS ns1.michaelwlucas.com.

0.0.10.in-addr.arpa. 7200 IN NS ns2.michaelwlucas.com.

0.0.10.in-addr.arpa. 7200 IN DS 57121 8 1 B72C89…

0.0.10.in-addr.arpa. 7200 IN DS 57121 8 2 BFD32E…

…

The zone 10.in-addr.arpa includes the nameserver for the delegation of 0.0.10.in-addr.arpa and DS records for key 57121. You'll also see RRSIG records for the NS and DS records. A client who has a trust anchor for 10/8 will trust these records and validate the child zone.

If you have problems, fall back to the troubleshooting in Chapter 9. The most common error I see is a key ID mismatch between the parent zone and the child zone – the exact same error you're most likely to make when dealing with your own parent domain. Whether you admit you screwed up to the child domain's DNS administrator is your decision.

Islands of Trust

Delegating and securing a child domain with a valid Chain of Trust is straightforward. But what if you have a domain that's not part of the global DNS? If you have private address space or an internal domain that isn't part of the global Internet, you must create your own trust anchor to establish DNSSEC.

A trust anchor key is the public key of a KSK. Format the KSK correctly and tell your client nameservers to trust the key, and you'll have your own Chain of Trust disconnected from the outside world. This is often called an island of trust.

Before you start, remember that querying an authoritative server for a zone never returns authenticated data. If you want to get DNSSEC validation on 10.in-addr.arpa, you can't query the authoritative nameserver for this zone. You must configure a nameserver that isn't authoritative. If your nameservers are both authoritative and recursive, you cannot deploy an island of trust. Separate your client-facing nameservers from your authoritative ones, and refer the appropriate queries from the recursive servers to the authoritative servers.

Choosing Private Domains

Some reverse zones are reserved for private use, such as the RFC 1918 private address ranges. But there is no reserved name for forward zones. Some organizations use .local, but that's actually reserved for mDNS. I suspect that organizations using .local must enjoy having problems, but that's their call.

Some organizations make up a private top-level domain. ICANN creates new TLDs all the time, however, and eventually they will use your made-up domain. And if you create a new domain under, say, .com, what will happen when someone registers that domain in the outside world? Worse, what happens if it's a competitor to your company?

If you want a private domain for internal use, register a public one to avoid conflicts. Spare your slightly older self the headache.

Prepare a Trust Anchor

The easiest way to get the public key of a zone's KSK is to ask the nameserver. The following dig command pulls all the keys for a zone, with very little context.

$ dig zonename dnskey @localhost +multi +nocomments +nostats

Here I get all the keys for my private address space and direct them to the file trustedkey.conf.

$ dig 10.in-addr.arpa dnskey @localhost +nocomments +nostats > trustedkey.conf

Remove all blank lines from this file and all lines beginning with a semicolon. Remove the key of type 256, as that's the zone's ZSK. You'll be left with a text string like the below.

10.in-addr.arpa. 7200 IN DNSKEY 257 3 5 AwEAAdKykgOTpkkMl…

Remove TTL (7200), IN, and DNSKEY from the key. What remains is the trust anchor key.

The named program maintains trust anchors for the DLV and the root zone automatically. For an island of trust, you must configure the trusted key manually with a named.conf entry.

trusted-keys {

"zonename" 257 3 5 "key here";

};

To convert your edited DNSKEY record to a trusted keys format, add quotes around the zone name and the public key. My trusted-keys entry for the zone 10.in-addr.arpa looks like this.

trusted-keys {

"10.in-addr.arpa." 257 3 5

"AwEAAdKykgOTpk

…

g17OOCdU7L2otJkV";

};

I now have a trusted key for this zone, formatted appropriately for named.

Add a Trust Anchor to Client-Facing Servers

Copy this key to the client-facing nameservers. You can either add it directly to named.conf, or use an include file. I recommend using an include file. When you must rollover your private KSK (and one day you'll have to), copying a new file to a server is less trouble than editing a configuration file. You also need to tell the recursive nameserver about your private domain, either through forwarders or a stub zone. Which you choose depends on your organization's security policy. Here's a forwarder example.

include "/etc/namedb/trustedkeys.conf";

zone "10.in-addr.arpa." {

type forward;

forward only;

forwarders { 192.0.2.18; 198.0.2.134; };

};

A stub is preferable because it tells named to cache the nameservers for this zone and query them directly, rather than arbitrarily forwarding every single query to the forwarders.

include "/etc/namedb/trustedkeys.conf";

zone "10.in-addr.arpa." {

type stub;

masters { 192.0.2.18; 198.0.2.134; };

};

Reload your nameserver. This recursive nameserver now uses the public key in /etc/namedb/trustedkeys.conf, and uses the listed servers for all queries for 10.0.0.0/8.

Testing the Island of Trust

To verify that the island of trust works, use dig on the recursive nameserver.

$ dig -x 10.0.0.1 @localhost +ad

…

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

…

1.0.0.10.in-addr.arpa. 6245 IN PTR desktop.michaelwlucas.com.

This query returns a PTR record, and the ad flag is set. You've achieved an Island of Trust.

Now that you have a secure distributed database for hosts and IP addresses, let's finish by cramming other stuff into it.

Chapter 12: DNSSEC for Data Distribution

One of the big problems of security infrastructure is the distribution of authentic information. We use Certificate Authorities to assess our identities and provide SSL certificates signed by a trusted authority, rather than having organizations vouch for themselves. Applications such as Secure Shell (SSH) require users to manually verify the public keys associated with a server. When an organization deploys a VPN device, they must somehow securely distribute the server's public key to the users. DNSSEC offers a solution to this entire category of problems. An organization using DNSSEC has a cryptographically verified distribution method for non-confidential information, including cryptographic public keys.

Some application vendors are already requiring the use of DNS records for their devices. More than one VPN client device looks for an IPSECKEY record for the VPN concentrator, and will not connect without it. Without DNSSEC, an intruder can alter that record and redirect those clients any way they like. Vendors of such devices provide instructions for their products, so I'm going to look at two more generally useful cases for DNSSEC-based data distribution: distributing SSH host keys, and verifying self-signed certificates for HTTPS web sites.

SSH Host Key Fingerprints

The Secure Shell (SSH) protocol uses public key cryptography to verify that the server you're connecting to is actually the server you think it is, and to secure the data flowing between client and server. Unfortunately, correct use of SSH requires that when a user logs into a SSH server for the first time, he must examine the offered public key and compare it to an out-of-band copy of the server's public key. This is tedious and annoying, and most SSH users don't bother. Worse, most SSH users quickly learn to ignore SSH's warnings about public key problems. We work hard to teach users about security problems. Teaching them to ignore security issues is not good.

You can distribute SSH host keys via DNS by using SSH Fingerprint (SSHFP) records. As they're security-critical, it's important that the key be immune to tampering. Do not use SSHFP records until you have working DNSSEC.

To distribute host keys over DNSSEC you must create SSHFP records, insert them in the zone, and configure your SSH client. We'll cover the OpenSSH client and server. If you're not familiar with OpenSSH, permit me to direct you to my book SSH Mastery (Tilted Windmill Press, 2012).

Create SSHFP Records

Use the –r argument to ssh-keygen(1) to create SSHFP records. It reads the public key files in /etc/ssh, parses them, and creates DNS records with the hostname you specify. Use the hostname as you want it to appear in the SSHFP record.

$ ssh-keygen –r hostname

Here I create SSHFP records for the web server www.

$ ssh-keygen -r www

www IN SSHFP 1 1 f44d08efc159…

www IN SSHFP 1 2 86c744ce05ba…

www IN SSHFP 2 1 9af675d68969…

www IN SSHFP 2 2 7914036e9053e14db552…

www IN SSHFP 3 1 0f7c928e3954c54f0b32…

www IN SSHFP 3 2 5c5192e78de10…

This displays SSHFP records for all host keys on the local machine. This entry is specific to the machine's domain. I could run the exact same command on the machine www.isc.org and would get a completely different record. Be sure to associate the SSHFP records with the correct host! If a host has multiple name and you might use any of those names to contact the host, then each host name needs a SSHFP record.

Insert the SSHFP record into the zone just like any other resource record.

Configure The Client

The two biggest SSH clients are OpenSSH and PuTTY. PuTTY does not yet support SSHFP records. Enable SSHFP checks on the OpenSSH client by setting the configuration option VerifyHostKeyDNS to yes in ssh_config or $HOME/.ssh/config.

When the client logs into a new SSH server that has a SSHFP record, the user is informed that a SSHFP record exists.

$ ssh www

The authenticity of host 'www [192.0.2.63]' can't be established.

ECDSA key fingerprint is c3:a2:83:22:da:1e:95:23:f9:59:e6:c7:96:98:13:cf.

Matching host key fingerprint found in DNS.

Are you sure you want to continue connecting (yes/no)? yes

The user is told that the key matches the DNS entry, and the user can choose to accept it or not. If the key presented by the host does not match the SSHFP record, the client gets a big scary "host key changed" message. Depending on how your operating system packages OpenSSH, it might log you in without further user intervention. This eliminates the client-side known_hosts file and greatly simplifies managing SSH keys.

Distributing SSHFP records over DNS makes users more likely to verify host keys. Implement it if you can.

SSL Certificate Verification: TLSA

Secure Sockets Layers (SSL) is a popular way to secure data as it crosses the Internet. One of the major goals of SSL protection is verifying the server owner. A SSL certificate supposedly attests to the identity of the server operator, permitting secure communications between the client and the server.

Web browsers have several Certificate Authorities (CAs) hard-coded into them, and automatically recognize certificates signed by those CAs. If you want a SSL certificate for your site you must contact a CA, have them validate your identity, and pay for the privilege. You can create self-signed certificates at no cost, but web browsers don't recognize them. Users get all kinds of scary warnings when they access web sites with self-signed certificates. These warning are only scary because browser developers have no way to make them utterly terrifying.

DNSSEC offers a way to validate certificates: the DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol (TLS). The zone administrator places a hash of the server certificate in DNS as a TLSA record. TLSA is not an acronym, it's just the name of the DNS resource record used for the protocol. (Presumably, the IETF left space for resource records TLSB, TLSC, etc, once the world exposes all the abuses and flaws they didn't think of.) When a web browser contacts the web site, it checks for a DNSSEC-secured TLSA record for the host and port. The browser compares the TLSA record to the certificate, and if everything matches, the browser treats the certificate as approved. The user sees no scary warning, even for self-signed certificates.

This is a slightly different trust model than that based on certificate authority. DANE TLS assumes that the organization that controls the DNS for a zone also controls the server. The CA model assumes that the CA does a good job of verifying certificate applicants. Both have weaknesses, but different ones. Interestingly, DANE TLS can also be used for CA-based certificates, and a TLSA record can specifically prohibit use of a self-signed certificate, so you can combine the two models to achieve both the best and worst of both. (Which is best and which is worst is up to you.)

Client support for TLSA only exists on web browsers, and requires a browser plug-in as of March 2013. DANE TLS was approved mid-2012, and programmers are busily writing client libraries. Browsers will certainly incorporate TLSA support before long, and other software will follow. While I use the word browser to represent a client, it's only because that's the example I have to work with. TLSA support will spread into anything that uses SSL.

Note that for the last few years, many people have implemented methods of stapling SSL certificates to DNSSEC. Perhaps the best known is the ImperialViolet code actually deployed in Google Chrome. With DANE and TLSA, these earlier methods are obsolete. You'll stumble across references to various ways to staple SSL certificates to DNSSEC, but don't use them.

I'll cover creating TLSA records for your sites, and then configuring a browser to support TLSA.

TLSA Records

The key to DANE TLS is the TLSA record, which exports either a hash of the certificate's public key or the actual public key. The TLSA record looks like this.

_port._protocol.hostname TLSA ( usage selector match key)

_443._tcp.dnssec.michaelwlucas.com TLSA ( 3 0 2 891C….C8DB )

The port is the TCP, UDP, or SCTP port this record represents. (SCTP, the Stream Control Transmission Protocol, is a modern transport protocol for streaming data. You've never heard of it? You will.) A host can have different certificates on different ports, so your email team can maintain their certificate without access to your web site certificate.

The protocol is the TCP/IP protocol. TLSA records support TCP, UDP, and SCTP.

The hostname is the host using the certificate, and TLSA is the resource record type.

The usage field gives constraints for the type of certificate that can be used on this host and port. I'll cover those in "CA Use Policies," below.

The selector shows how to compare the information in the TLSA record to the site certificate. For now, this should always be 0.

The match field says what kind of data the record contains. A 0 indicates a full public key, a 1 is a SHA-256 hash, and a 2 is a SHA-512 hash. While I'll refer to this field as containing a hash, you should know that you can put a full public key in if you want.

CA Use Policies

The usage field lets you define how this TLSA record interacts with a Certificate Authority.

A 0 means that the record contains the hash of a CA signing certificate. This means that a specific CA must have signed the certificate used on this service. You could have a TLSA record that says "The certificate on this port must have been signed by Mitigation Limited," and the sysadmin responsible for the service could renew his certificate from the approved vendor without bothering the DNS team.

A 1 means that the record contains the hash of a CA-signed certificate. The service this record represents must have an official CA-approved certificate, and information specific to that certificate is stored in the record. When the sysadmin renews his certificate, even from the same CA, this record must be updated.

A 2 means that the record contains the hash of a private certificate authority. Any certificate offered by the service must be signed by an entity whose public key matches the hash in the record. This is for organizations that have their own Certificate Authority, and want their services to use only certificates signed by that authority.

A 3 means that the record contains the hash of a certificate. Any kind of certificate. The certificate does not to be signed by a CA, so you can use self-signed certificates.

Self-Signed Certificate TLSA

My test site https://dnssec.michaelwlucas.com uses a self-signed certificate, supported by the following TLSA record.

_443._tcp.dnssec TLSA ( 3 0 2 891CD…9C8DB )

You need your own hostname and SHA-512 hash, but if you're using a self-signed certificate your usage, selector, and match fields should be identical to mine. And probably your port number and protocol as well.

Generating a Certificate Hash

TLSA records can either use the full public key on a certificate or a hash of the public key. Most of us want to use a hash. You can use either SHA-256 or SHA-512, but I generally use SHA-512.

Use OpenSSL to get the hash of your certificate. If your certificate is site.crt, run:

$ openssl x509 -noout -fingerprint -sha512 < site.crt

SHA512 Fingerprint=89:1C:DF:6A:96:…:73:49:79:C8:DB

For a SHA-256 hash, use –sha256 rather than –sha512.

Remove all the colons from the hash, and copy it into the last field in your TLSA record. Increment your zone's serial number and reload. You're done! TLSA-aware clients can now verify your site certificate.

Now all you need is a TLSA-aware client.

TLSA Browser Plugins

TLSA support in browsers is evolving rapidly. I recommend that you do a few web searches for better solutions before choosing one for your organization. Always test to see if a plugin works for your environment.

DNSSEC Validator

For a few years now, the best DNSSEC plugin has been DNSSEC Validator from cz.nic. If a web site's DNS is secured via DNSSEC, a green key icon appears in the address bar, regardless of the presence of TLSA or SSL. This is a useful reassurance to end-users. The gray box that appears when a site lacks DNSSEC is not overly scary. But DNSSEC Validator does not yet support TLSA records. The plugin authors assure me that TLSA is on their roadmap and should appear before long. I recommend you check for TLSA support in DNSSEC Validator, and use this plugin if that support exists.

Extended DNSSEC Validator

If DNSSEC Validator doesn't yet support TLSA, you can test TLSA by the Extended DNSSEC Validator in Firefox. The version of the add-on on the home page (http://os3sec.org) is usually out of date, so I recommend building the newest version of the add-on from the source repository at https://github.com/os3sec/Extended-DNSSEC-Validator/. The add-on comes with warnings that it's a proof-of-concept, and you shouldn't rely on it for authentication. I've found it rather clunky, and it slows down my web browser, but I usually use an unspeakable number of tabs, so your experience might differ.

Extended DNSSEC Validator uses the libunbound DNS library, from http://www.unbound.net. Every system that uses this plugin needs to have Unbound installed. Most Unix-like operating systems have a package for libunbound and/or the Unbound DNS server. There's even a port of Unbound available for Microsoft operating systems, although you must reboot your Microsoft system after installing. Before building or installing the Extended DNSSEC Validator add-on, install either libunbound or the whole server.

The standard add-on build process uses the bash shell. If you're building on and for Microsoft systems, the easiest way to get this is installing Cygwin (http://www.cygwin.com). You'll also need the zip package.

Download the Zip file containing the source code from https://github.com/os3sec/Extended-DNSSEC-Validator/. Extract it. Go into the add-on directory and run ./build.sh. This creates the file extval.xpi. This is your add-on.

Start Firefox. Hit CTRL-O to open the "Open" dialog. Browse to extval.xpi in the plugin source directory and tell Firefox to open it. The browser will ask if you want to install the add-on. Say yes. Restart Firefox after installing.

Testing TLSA

Now browse to http://www.internetsociety.org/deploy360/resources/dane-test-sites/ for a list of web sites with various DANE TLS configurations. Or you can use my TLSA web site, https://dnssec.michaelwlucas.com, but as a reward you'll see a bunch of random crap about this book and other stuff I do. Choose one and click the lock icon in the address bar to see exactly how the site is secured.

Now you can choose which services need a CA-signed SSL certificate, and which don't. When you have reliable TLSA support in your organization's web browser, you can use TLSA-backed self-signed certificates for your internal hosts. Public-facing applications will need to use CA-based certificates for some time yet, but when the TLSA support on the Internet hits critical mass you'll be ready for the switch.

Afterword

After decades of abuse, DNS finally has a security infrastructure. People have tested and honed DNS Security Extensions for over a decade, and the software has finally caught up with the real-world capacities of the average DNS administrator. While DNSSEC might initially seem complex, DNS probably seemed complex when you first encountered it. And deploying DNSSEC will enhance your trust in your own network resources even as it improves your trust in other people's DNS. Your users can rest assured that the goofy cat video they're watching is actually the goofy cat video their mother sent.

If you're interested in learning more about DNSSEC, look at resources such as the NIST's Secure Domain Name System (DNS) Deployment Guide, the BIND 9 Administrator Reference Manual, and the web site http://www.dnssec.net.

Previously, DNS seemed like the slightly daft ancestor at your holiday dinner: well-meaning, unquestionably welcome at the party, but a little old-fashioned and fuddy-duddy. DNSSEC transforms DNS into a trustworthy method for distributing public information. By deploying DNSSEC now, you're on the leading edge of the Internet's next revolution. Secure DNS can power and enhance a new generation of Internet services.

Your DNSSEC deployment makes you one of the first people standing in the future. Congratulations!