DNS and DNSSEC

It's a well-known system administration aphorism that everything is a DNS problem. It should come as no surprise that many people came to Tuesday morning's tutorial on DNS and DNSSEC presented by Shumon Huque. Shumon began with an introduction to the basic components and architecture of DNS, including the hierarchical structure of domain names and the differences between authoritative servers, resolvers, and clients.

We then moved on to exploring the various types of DNS records. Of course, there are the well-known types: NS, A, AAAA, CNAME, PTR, and MX. There are also additional record types that some system administrators may not be familiar with. SRV records designate hosts providing a service for a particular application. TXT records are free-form descriptive strings. NAPTR records are very complex records that involve regular expressions are also defined in the DNS specifications, much to the dismay of DNS admins.

When multiple name servers are used, the zone records have to be transferred. This can be done via out-of-band mechanisms, or in-band with DNS's AXFR or IXFR features. Of course, it is desirable to ensure that the data being received is the same as the data being sent, so public key authentication is used. This is the foundation of DNSSEC.

DNSSEC is implemented on a per-zone basis, and each zone has its own key pair. A chain of trust is established from the root name servers down through the delegation path to the destination zone. Often, administrators use a two-level key hierarchy: a strong key signing key is used to sign the relatively weaker zone signing key which signs the record sets.

Prior to the root name servers supporting DNSSEC, a workaround mechanism was available to create "off path" trust anchors. If a resolver can't find a DS record for example.com, it looks for a DNSSEC Lookaside Validation (DLV) record for example.com.dlv.isc.org.

The popular BIND name server has good support for DNSSEC, but because the field is still rapidly evolving, it is recommending to use the latest possible version. While the conventional wisdom suggests rolling keys over at regular intervals, but Shumon does not agree with this. Keys should be rolled over for specific events (for example admin departure or compromised name servers), but not because the calendar says so.