DNSSEC Part I: the Concepts

DNSSEC signatures follow a similar chain of trust to PGP keys and CAs. In this case, the root DNS servers act as the trust anchor, and DNSSEC resolvers implicitly trust what the root DNS servers sign, much like browsers trust CAs. When a TLD (Top Level Domain) wants to implement DNSSEC, it submits a special DS record to the root DNS servers to sign. Those DS records contain a signature for the subdomain generated by the private key. The root DNS server hosts that DS record and signs it with its private key. In that way, because you trust root, you can trust that the signature for org has not been modified; therefore, you can trust it as well in the same way you would trust a certificate signed by a CA. Then if you want to enable DNSSEC for a .org domain, for instance, you would submit a DS record for each key through your registrar if it supports DNSSEC. Each DS record contains a key's signature for your domain that the org name servers then would sign and host.

In this model, the chain of trust basically follows the same order that a recursive DNS query like I outlined above would follow. A DNSSEC query adds an extra validation step to each part of the process. For instance, a query for www.isc.org starts at the root, uses the DS record for org to validate com signatures, then uses the DS record for isc.org to validate the isc.org signature attached to www.isc.org. You can add the +dnssec option to dig +trace to see the full transaction:


$ dig +trace +dnssec www.isc.org

; <<>> DiG 9.8.1-P1 <<>> +trace +dnssec www.isc.org
;; global options: +cmd
.                 492727  IN      NS      g.root-servers.net.
.                 492727  IN      NS      m.root-servers.net.
.                 492727  IN      NS      i.root-servers.net.
.                 492727  IN      NS      b.root-servers.net.
.                 492727  IN      NS      f.root-servers.net.
.                 492727  IN      NS      a.root-servers.net.
.                 492727  IN      NS      k.root-servers.net.
.                 492727  IN      NS      h.root-servers.net.
.                 492727  IN      NS      l.root-servers.net.
.                 492727  IN      NS      e.root-servers.net.
.                 492727  IN      NS      c.root-servers.net.
.                 492727  IN      NS      d.root-servers.net.
.                 492727  IN      NS      j.root-servers.net.
.                 518346  IN      RRSIG   NS 8 0 518400 20130517000000
20130509230000 20580 . M8pQTohc9iGqDHWfnACnBGDwPhFs7G/nqqOcZ4OobVxW8l
KIWa1Z3vho56IwomeVgYdj+LNX4Znp1hpb3up9Hif1bCASk+z3pUC4xMt7No179Ied
DsNz5iKfdNLJsMbG2PsKxv/C2fQTC5lRn6QwO4Ml09PAvktQ9F9z7IqS kUs=
;; Received 589 bytes from 127.0.0.1#53(127.0.0.1) in 31 ms

org.              172800  IN      NS      d0.org.afilias-nst.org.
org.              172800  IN      NS      b0.org.afilias-nst.org.
org.              172800  IN      NS      a2.org.afilias-nst.info.
org.              172800  IN      NS      b2.org.afilias-nst.org.
org.              172800  IN      NS      c0.org.afilias-nst.info.
org.              172800  IN      NS      a0.org.afilias-nst.info.
org.              86400   IN      DS      21366 7 1
E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2
org.              86400   IN      DS      21366 7 2
96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA
org.              86400   IN      RRSIG   DS 8 1 86400 20130517000000
20130509230000 20580 . kirNDFgQeTmi0o5mxG4bduPm0y8LNo0YG9NgNgZIbYdz8
gdMK8tvSneJUGtJca5bIJyVGcOKxV3aqg/r5VThvz8its50tiF4l5lt+22n/AGnNRxv
onMl/NA5rt0K2vXtdskMbIRBLVUBoa5MprPDwEzwGg2xRSvJryxQEYcT 80Y=
;; Received 685 bytes from 192.203.230.10#53(192.203.230.10) in 362 ms
isc.org.          86400   IN      NS      ns.isc.afilias-nst.info.
isc.org.          86400   IN      NS      ams.sns-pb.isc.org.
isc.org.          86400   IN      NS      sfba.sns-pb.isc.org.
isc.org.          86400   IN      NS      ord.sns-pb.isc.org.
isc.org.          86400   IN      DS      12892 5 2
F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5
isc.org.          86400   IN      DS      12892 5 1
982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
isc.org.          86400   IN      RRSIG   DS 7 2 86400 20130530155458
20130509145458 42353 org.
Qp7TVCt8qH74RyddE21a+OIBUhd6zyzAgSB1Qykl2NSkkebtJ1QeE5C5
R8eblh8XvmQXjqN7zwcj7sDaaHXBFXGZ2EeVT5nwJ1Iu4EGH2WK3L7To
BDjR+8wNofZqbd7kX/LOSvNu9jdikb4Brw9/qjkLk1XaOPgl/23WkIfp zn8=
;; Received 518 bytes from 199.19.56.1#53(199.19.56.1) in 400 ms

www.isc.org.      600     IN      A       149.20.64.42
www.isc.org.      600     IN      RRSIG   A 5 3 600 20130609211557
20130510211557 50012 isc.org.
tNE0KPAh/PUDWYumJ353BV6KmHl1nDdTEEDS7KuW8MVVMxJ6ZB+UTnUn
bzWC+kNZ/IbhYSD1mDhPeWvy5OGC5TNGpiaaKZ0/+OhFCSABmA3+Od3S
fTLSGt3p7HpdUZaC9qlwkTlKckDZ7OQPw5s0G7nFInfT0S+nKFUkZyuB OYA=
isc.org.          7200    IN      NS      ord.sns-pb.isc.org.
isc.org.          7200    IN      NS      sfba.sns-pb.isc.org.
isc.org.          7200    IN      NS      ns.isc.afilias-nst.info.
isc.org.          7200    IN      NS      ams.sns-pb.isc.org.
isc.org.          7200    IN      RRSIG   NS 5 2 7200 20130609211557
20130510211557 50012 isc.org.
SdMCLPfLXiyl8zrfbFpFDz22OiYQSPNXK18gsGRzTT2JgZkLZYZW9gyB
vPTzm8L+aunkMDInQwFmRPqvHcbO+5yS98IlW6FbQXZF0/D3Y9J2i0Hp
ylHzm306QNtquxM9vop1GOWvgLcc239Y2G5SaH6ojvx5ajKmr7QYHLrA 8l8=
;; Received 1623 bytes from 199.6.0.30#53(199.6.0.30) in 60 ms
]]>

You'll see a number of new record types in this response, but don't worry, I go over all of the new DNSSEC record types next.

DNSSEC Terminology

A lot of different acronyms and new terminology comes up when you read DNSSEC documentation, so here are a few common terms you'll want to be acquainted with as you use DNSSEC:

  • RR (Resource Record): this is the smallest unit of data in a zone, such as a single A record, NS record or MX record.

  • RRSET: a complete set of Resource Records. For instance, an RRSET might be all NS records or A records for a particular name.

  • KSK (Key-Signing Key): signs DNSKEY records in a zone.

  • ZSK (Zone-Signing Key): signs all of the other records in a zone.

  • SEP (Secure Entry Point): a flag set in a key to denote it as a KSK.

While best practice dictates a separate KSK and ZSK, it isn't an actual requirement. In my next article on DNSSEC implementation, I will discuss the main differences between the two key types and why separate keys is considered a best practice.

New DNSSEC Record Types

DNSSEC also has introduced a number of new DNS record types into the mix. These records are published with the zone along with the rest of your DNS records and are pulled down as needed by any DNSSEC-enabled query:

  • DNSKEY: this is a public key for the zone and can either be a KSK or ZSK.

  • RRSIG (Resource Record Signature): this record contains a signature for an RRSET created with a particular ZSK.

  • NSEC (Next Secure record): these records are used in "negative answers" to prove whether a name exists.

  • NSEC3 (Next Secure version 3): these records are like NSEC, but protect against "zone walking" where an outside user could use NSEC records to walk down the zone and discover all of the records in the zone (much like being able to perform a zone transfer).

  • DS (Delegation Signer): this record contains a KSK signature and is submitted to the zone's parent where it is signed and is used as part of a chain of trust.

  • DLV (DNSSEC Look-aside Validation): much like DS records, but are used when DS records are not supported by a zone, or as an alternate trust anchor if your registrar doesn't support DNSSEC.

DNSSEC Look-Aside Validation

DNSSEC has a sort of chicken-and-egg problem. If your TLD does not support DNSSEC, any outside resolvers won't have a complete chain of trust from root, through the TLD, to your zone. There also may be a case where your TLD does support DNSSEC, but your registrar doesn't provide a mechanism to upload a DS record to the TLD (most registrars sadly don't). In either case, DNSSEC Look-aside Validation (DLV) has been created to provide an alternate trust anchor.

You can find more details on DLV at http://dlv.isc.org (one of the main DLV providers), but essentially, instead of generating a DS record to submit to a TLD, you generate a special DLV record and submit it to a DLV server. As long as a DNS resolver is configured to trust, for instance, dlv.isc.org, it can use that to anchor the chain of trust and then trust your signed records.

It turns out DNSSEC has a lot of new concepts to understand before you even get to implementing it; however, the implementation isn't all that bad once you see the steps laid out, so be sure to follow up with my article next month when I talk about how to implement DNSSEC for a zone using BIND. I'll even cover how to set up DLV for the zone.

Resources

A Collection of Links to DNSSEC Information: http://dnssec.net

ISC's DLV Documentation: https://dlv.isc.org

DNSSEC Chain of Trust Visualizer: http://dnsviz.net

______________________

Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix