DNSSEC 101

DNSSEC is something you’ve no doubt heard of, especially this past summer with the discovery of the Kaminsky DNS bug which led to a small panic and widespread patching from vendors. DNSSEC (sometimes called DNSSECbis) has existed as a proposal for about 10 years, but has undergone significant changes as recently as March 2008, and has only lately seen a major push to implementation. This post discusses both the need for DNSSEC and tackles the complex topic of how it works, as simply as possible. Though this really only scratches the surface, it should serve as a good intro for those who want to know more. A fundamental understanding of DNS is assumed.

WHAT DNSSEC DOES (AND DOESN’T) DO

DNSSEC provides three basic things:

  • Data Origin Authentication – assures that data was received from the authorized DNS server; can protect from impersonation attacks like the Kaminsky bug.
  • Data Integrity – assures that data received matches data on the origin DNS server, and was not modified during transit; protects from MITM type pollution attacks.
  • Authenticated Denial of Existence – assures that a “Non-existent” response is valid.

DNSSEC provides these services by securely signing DNS records. This requires the addition of four new zonefile record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). Signing is done via the use of public key / private key pairs. If you are familiar with the concept of PKI, this is similar. However, DNSSEC is not PKI. There are no certificates or certificate authorities. The records in a zone are signed with the private portion of a zone signing key (ZSK), and this signature is returned along with the standard response to a DNS query.

The public key can then be used to validate the data. DNSSEC also provides a method to verify the signature’s authenticity, by signing the ZSK with a key signing key (KSK). DNSSEC does not provide any form of encryption services, so data can still be sniffed, but this typically isn’t considered a threat for DNS traffic. DNSSEC also does not provide any additional protection of zone transfers. DNSSEC is fully described in RFC’s 4033, 4034, and 4035. To allow for the additional record types, support for DNS Extension Mechanisms (EDNS0) is required, as described in RFC 2671.

At this time DNSSEC is supported on only a few DNS servers, ISC’s BIND being the most popular. Signing a DNSSEC zone with BIND requires v9.3 or later. Microsoft products do not support DNSSEC at this time, but it will be integrated with Windows 7 and Server 2008 R2. Updates to provide support in older OS’s may be released around that time as well. Microsoft’s DNS server is, however, able to load DNSSEC signed zones, meaning it does have the capability to act as a secondary for a signed zone on a BIND primary. That fact highlights an important point, that DNSSEC signing applies to a DNS zone, not a DNS server.

WHY DNSSEC IS NEEDED

DNS security is vital because nearly everything relies on it for name resolution at one stage or another. DNS has done very well scaling to support the growth of the Internet, but security was unfortunately not a factor in the protocol’s design. Numerous vulnerabilities have been identified in DNS going as far back as 1990. These problems are typically addressed as they arise. However, despite workarounds, there is still no way for a resolver to be certain that DNS data was returned uncorrupted, or that it even originated from the queried DNS server. DNSSEC helps to address these issues.

HOW IT WORKS

To secure a zone with DNSSEC, a DNS administrator will generate ZSK & KSK keys, add the public portion of each of the keys to the zonefile as a new record type (DNSKEY), and then sign the zone which will create additional record types (RRSIG & NSEC) for each authoritative record in the zone. The RRSIG record is the signature of a corresponding record. The NSEC record type provides the next secure record in the zonefile, which is how authenticated denial of existence is done. (If you already see a potential security problem with the NSEC record, you’re right, keep reading.) Another RRSIG record is created for the purpose of signing the NSEC record. In addition to adding these new records, the process of signing a zone also organizes it in canonical order. This entire process can significantly increase the size of the zonefile, often 8 to 10 x the original size.

The final step in the signing process is to provide the parent zone with the DS (Delegation Signer) record to create a chain of trust, assuming the parent is DNSSEC aware and the zone is signed. A DS record in the parent zone is signed by the parent’s ZSK, and points to the child’s KSK. The KSK is also referred to as a zone’s Secure Entry Point (SEP) because it is the first key used to form a chain of trust for that zone. In cases where the parent zone is not DNSSEC aware, the signed zone is referred to as an Island of Security. Look for an in-depth post in the future which will go over the steps of enabling DNSSEC on BIND.

Once the steps above have been completed, the zone being served is now protected with DNSSEC. However, in order to utilize the capabilities of DNSSEC, a resolver needs to be DNSSEC aware and know how to ask for the new record types in order to validate the data. To ultimately validate data, a resolver needs to be able to climb the chain of trust until it reaches a known good, trusted, authority (again similar to PKI). This is done by configuring validating resolvers with a “trust anchor” to the highest zone below which validation is desired. For example, if you have a trust anchor configured to .com, and DNSSEC is configured properly on all zones, you can validate example.com, child.example.com, etc. The best case scenario would be configuring resolvers with a trust anchor to the root zone, however, the root zone is not signed at this time, nor are most of the TLDs. Until that time, multiple trust anchors are required.

When a resolver attempts to validate DNSSEC signed zone data, 1 of 4 potential states will be determined:

  • Secure – resolver has trust anchor and is able to validate all signatures.
  • Insecure – resolver is able to validate to a point in the chain of trust, but at some point a delegating DS record is non-existent, meaning data below that point cannot be validated.
  • Bogus – resolver has a valid chain of trust but data fails to validate (missing signatures or data, unsupported algorithms, expired signatures, etc.).
  • Indeterminate – no trust anchor available to validate data; this is default mode.

Currently there are very few true client resolvers that are capable of validating DNSSEC. Until the time when that client support is more widespread, most DNSSEC validation takes place between supporting recursive servers (acting as resolvers) and authoritative name servers.

Several organizations operate open recursive servers on the Internet for testing DNSSEC, Comcast is one of them. Below are examples of queries against one of these Comcast resolvers using the Linux dig utility. The first one is a standard query/response. The second is the same query but this time asking for DNSSEC validation. Note that some extraneous info has been removed for brevity.

#> dig @68.87.68.170 http://www.ripe.net
; <<>> DiG 9.4.1-P1 <<>> @68.87.68.170 http://www.ripe.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5769
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2

;; QUESTION SECTION:
;www.ripe.net.                  IN      A

;; ANSWER SECTION:
http://www.ripe.net.    446     IN      A       193.0.19.25

;; AUTHORITY SECTION:
ripe.net.               172625  IN      NS      ns-pri.ripe.net.

;; ADDITIONAL SECTION:
ns-pri.ripe.net.        172625  IN      A       193.0.0.195

#> dig @68.87.68.170 +dnssec http://www.ripe.net
; <<>> DiG 9.4.1-P1 <<>> @68.87.68.170 +dnssec http://www.ripe.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14945
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.ripe.net.                  IN      A

;; ANSWER SECTION:
http://www.ripe.net.    227     IN      A       193.0.19.25
http://www.ripe.net.    227     IN      RRSIG   A 5 3 600 20090112060009 20081213060009 58440 ripe.net. Yo8OYqzmR3eDzM6OV0+3dVS7RWFpGR6xhH6GTwe+k8w/PPya+KAm8oaM dArOto4E2DVDJp4XV7wyeWmZujl3tDG4FLCnDSpLgMgAULtxRhtZCPY/ injY/JX1K+fibea3ChE/jSZnaX7oSjNHCYoYzYoSux92K2EkeYC4hy4I lljADsvFhilCaJE7UF4n6XkrWBS8u6OF

;; AUTHORITY SECTION:
ripe.net.               172406  IN      NS      ns-pri.ripe.net.
ripe.net.               120093  IN      RRSIG   NS 5 2 172800 20090112060009 20081213060009 58440 ripe.net. O7O3A9AUOqOMU5/BCG+7rNjqT/7V4qsDtW0GYu+WJuULdGQ1/g+HY4W0 rooQoNTws3BIhs9ZlvD+i6+gtexidx9ePSwigGPrf4lL3Ls6hXm6orAu HK9vrSfuRCd2aoh42naLpiSn4kl3iPyQv8EznSctROr2O+/H6nmbmdTk n+BTJz8T7rD9tXG11n+vbvkBNtc/0TD+

;; ADDITIONAL SECTION:
ns-pri.ripe.net.        172406  IN      A       193.0.0.195
ns-pri.ripe.net.        172406  IN      RRSIG   A 5 3 172800 20090112060009 20081213060009 58440 ripe.net. n7/rTrlOG7yPXW+Fi9lw2fphb9TsSK8TwYCjrcUdnhJvpQ3NcqHaqhec SIse2GuSJ/cpNN6WGIwpGEiC/dHX+4zwnzkWhVTn7XpAnQSUj7289/TE ++v6/6QrfUjRVWqb+VU8RWhrCWhj69zhhRohyjg3e2mideyXmqU0B+rh KhGDHojavw0uukHjCrBHFISXRgW383fX

Notice the only difference in the query was the addition of the +dnssec option. The key thing to note in the 2nd query response is the inclusion of the “ad” flag. This indicates that Authenticated Data was returned – DNSSEC validation worked. The other obvious difference is the inclusion of the RRSIG records, these are the signatures. This example worked because the Comcast recursive server has a trust anchor configured for the ripe.net. domain, which is a DNSSEC signed zone.

DNSSEC ADOPTION ISSUES

DNSSEC does not come without problems. As mentioned, the root and many TLD zones have yet to be signed. This is a primary reason that DNSSEC has not taken off yet; it needs to start at the top to be feasible and manageable. In an effort to kick start deployment, the U.S. government’s Office of Management & Budget released a memo in August 2008 requiring the top level .gov domain to be signed by January 2009, and sub-domains by December of ’09. The Defense Information Systems Agency has said they will meet the same requirements on the .mil domain.

Directly related to the above problem is the issue of trust anchor configuration not currently being scalable enough to support mass DNSSEC usage. You can sign your company.com zone, but until .com and the root are signed, and a full chain of trust to your domain implemented, resolvers will need a trust anchor configured specifically for your domain. As a temporary workaround, the concept of a Domain Lookaside Validation (DLV) registry has been put in place. With DLV, if a resolver cannot find a DS record in a parent zone, it will attempt to look in a pre-configured DLV registry. The ISC runs a DLV registry; following the above example, the DLV registry would be company.com.dlv.isc.org. For this to work you must register with the DLV registry, the resolver must be DLV enabled, and it must have a trust anchor for the DLV registry.

Mentioned previously, the NSEC record is associated with a zone record and lists the next record in the zone, based on canonical ordering. This enables one of DNSSEC’s goals, authenticated denial of existence, but was quickly identified as being a security threat, as it allows for zone enumeration. This ultimately amounts to a zone transfer, something admins typically work to lock down. To address this issue, RFC 5155 was drafted in March 2008 to describe the NSEC3 resource record, in which a hash of the next record’s name is returned rather than the actual name. This still allows a resolver to authoritatively determine that a record does not exist, while not allowing it to enumerate zone records. NSEC3 is supported in BIND v9.6 or higher.

There are a number of other issues related to DNSSEC that need to be taken into account. I won’t delve much further into them here, but additional research is advised for those considering a DNSSEC deployment. Some of the issues include:

* Dynamic updates: A dynamic update enabled zone will require re-signing when new records are added, which takes time and, if automated, will require the ZSK private key to be accessible – a potential security risk.
* Limited client support: Until DNSSEC support is more wide-spread and at the application layer, signing zones arguably does little to increase security. However, it is advantageous for traffic between recursive and authoritative servers, especially in the case of a trusted internal recursive server. Deploying DNSSEC doesn’t negatively affect current DNS deployment (except for possibly the below point).
* DNSSEC overhead: DNSSEC increases the size of response packets and the workload on resolvers. This is worthy of consideration for both performance and availability reasons. The potential to mount a denial of service attack against either resolver or server is greatly increased.
* Loose time synchronization: A requirement between a validating resolver and DNS signing authority. This is due to the fact that DNSSEC signatures have a validity period, similar to a TTL on DNS records, but rather than relying on elapsed time, these are absolute and expire at a certain time & date.
* Local policies: Configured policies can affect the ultimate security of DNSSEC in an environment; as an example, how should applications handle a DNSSEC lookup failure? Should it prompt the user for acceptance, similar to what Internet browsers do with SSL certificates, or fail outright? This introduces a number of usability issues.

SUMMARY

At this stage if DNSSEC still feels a bit kludgy and pieced together, it’s because it is, but most technology progresses this way. While DNSSEC doesn’t address every DNS security issue, it is a decent start and with the backing of government and other DNS power players, the industry will soon begin making the move to adoption. There is a good deal of confusion regarding the capabilities and implementation of DNSSEC, anyone who may wind up in a supporting role should begin getting familiar with it and consider a trial deployment.

DNSSEC won’t take off en masse until client support is more wide-spread (and the root gets signed). At the risk of sounding like a Microsoft zealot, it really won’t take off until their systems start to support it. Once its usage does increase though, DNSSEC combined with other security technologies will help to increase the overall security posture of the Internet. For more info on DNSSEC, take a look at the links below and check back soon for a post on enabling DNSSEC on BIND.

LINKS

Enabling DNSSEC on BIND
DNSSEC Information Site
RIPE DNSSEC Training Course – good info but old (2005)
Comcast DNSSEC Trial Site
DNS-OARC Resolver Info
Port 53 – Windows DNS Blog, some DNSSEC info
Subscribe to TechScrawl.com

Advertisements

One Response

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: