The BIG-IP GTM: Configuring DNSSEC

This is the fourth in a series of DNS articles that I'm writing. The first three are:

The Domain Name System (DNS) is a key component of the Internet's critical infrastructure. So, if the foundation of the Internet itself relies on DNS, then let's take a quick look at how stable this foundation really is. After all, DNS was born in the early 1980s...back when REO Speedwagon and Air Supply were cranking out hits on the radio. The question is...does the DNS of the 1980s have any issues we need to worry about today? Well as it turns out, DNS was not initially built with security in mind. When a user types a web address in his browser, he expects to be reliably directed to that website. Unfortunately, that doesn't always happen. One common example is seen when an attacker disrupts the user's request and redirects to a malicious site. Several DNS vulnerabilities like this have led the way to an interest in DNS Security Extensions (DNSSEC) to secure this critical part of our Internet infrastructure.

What is DNSSEC?

DNSSEC is a suite of extensions that add security to the DNS protocol by enabling responses to be validated. With DNSSEC, the DNS protocol is much less susceptible to certain types of attacks (like the DNS spoofing situation described above). DNSSEC uses digital signatures to validate DNS responses so that the end user can be assured he is visiting the correct website. Based on the design features of DNSSEC, it is most effective when deployed at each step in the DNS lookup process...from root zone to the final domain name. If you leave any of the steps unsigned, it creates weakness in the process and you won't be able to trust the entire chain. Keep in mind that DNSSEC doesn't encrypt the data, it just signs it to attest to the validity of the response.

When a user requests a site, DNS kicks into gear by translating the domain name into an IP address. It does this through a series of recursive lookups that form a "chain" of requests. The picture below shows an example of a user requesting f5.com and the DNS system chaining together requests in order to match the domain name to the IP address so that he can access the website.

This is all well and good, but the issue that forms the need for DNSSEC is that each stop in this chain inherently trusts the other parts of the chain...no questions asked. So, what if an attacker could somehow manipulate one of the servers (or even the traffic on the wire) and send the wrong IP address back to the user? The attacker could redirect the user to a website where malware is waiting to scan the unsuspecting user's computer. The picture below shows the same chain of requests, but this time an attacker has manipulated the last response so that the incorrect IP address is returned to the user. Not good.

DNSSEC addresses this problem by validating the response of each part of the chain by using digital signatures. These signatures help build a "chain of trust" that DNS can rely on when answering requests. To form the chain of trust, DNSSEC starts with a "trust anchor" and everything below that trust anchor is trusted. Ideally, the trust anchor is the root zone. Fortunately for all of us, ICANN published the root zone trust anchor, and root operators began serving the signed root zone in July, 2010. With the root zone signed, all other zones below it can also be signed, thus forming a solid and complete chain of trust. In fact, ICANN also lists the Top Level Domains (TLD) that are currently signed and have trust anchors published as DS records in the root zone (most of the TLDs are signed). The following picture (taken from iiw.idcommons.net) shows the process for building the chain of trust from the root zone.

DNSSEC uses two kinds of keys: Key Signing Keys and Zone Signing Keys. The Key Signing Key is used to sign other keys in order to build the chain of trust. This key is sometimes cryptographically stronger and has a longer lifespan than a Zone Signing Key. The Zone Signing Key is used to sign the data that is published in a zone. DNSSEC uses the Key Signing Keys and Zone Signing Keys to sign and verify records within DNS.

BIG-IP Configuration

The BIG-IP Global Traffic Manager (GTM) will not only respond to DNS requests, but it will also sign DNSSEC validated responses. But before you can configure the GTM to handle nameserver responses that are DNSSEC-compliant, you have to create DNSSEC keys and zones.

The first step is to create the Zone Signing Key(s) and the Key Signing Key(s). The Zone Signing Key specifies the keys that the system uses to sign requests to a zone. The BIG-IP responds to DNSSEC requests to a specific zone by returning signed nameserver responses based on the currently available generations of a key. The Key Signing Key works the same as the Zone Signing Key except that it applies to keys instead of zones.

To create these keys, navigate to Global Traffic >> DNSSEC Key List and create a new key. Note: this menu looks slightly different starting in version 11.5 (it's listed under "DNS" instead of "Global Traffic") but the Key Creation is still the same.

On this page, you can create a Zone Signing Key and a Key Signing Key, and you can also specify several other settings like HSM use, algorithm selection, and key management action. Note that you can let the BIG-IP automatically manage your key actions or you can choose to do it manually.

Configuration Settings

The Bit Width for the key can be either 1024, 2048, or 4096 bits. The default is 1024.

The TTL value specifies the length of time the BIG-IP stores the key in cache. A key can be cached between 0 and 4294967295 seconds (by the way, 4294967295 seconds is a little more than 136 years!). The default value is 86400 seconds (one day). This value must be less than the difference between the values of the rollover period and expiration period (referred to as the "overlap period"). Setting this value to 0 seconds indicates that client resolvers do not cache the key.

The Rollover Period specifies the interval after which the BIG-IP creates a new generation of an existing key. The valid range for values for the Rollover Period is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not roll over. This value of the rollover period must be greater than or equal to one third of the value of the expiration period and less than the value of the expiration period.

The Expiration Period specifies the interval after which the BIG-IP deletes an existing key. The valid range for values is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not expire. The value of the expiration period must be more than the value of the rollover period. Also, the overlap period must be more than the value of the TTL. FYI...the National Institute of Standards and Technology (NIST) recommends that a Zone Signing Key expire between 30-90 days, and that a Key Signing Key expire once a year.

The Signature Validity Period specifies the interval after which the BIG-IP no longer uses the expired signature. The valid range for values is from 0 to 4294967295 seconds. The default is 7 days. This value must be greater than the value of the signature publication period. If you set this value to 0, the server verifying the signature never succeeds because the signature is always expired, so don't set it to 0!

The Signature Publication Period specifies the interval after which the BIG-IP creates a new signature. The valid range for these values is from 0 to 4294967295 seconds. The default value is 4 days, 16 hours (two-thirds of a week). This value must be less than the value of the signature validity period. If you set this value to 0, the system does not cache the signature.

TTL Values, Key Values, and Overlaps

The following diagram shows an example of key generation timelines with rollover periods and overlaps. This diagram is useful when reviewing the configuration settings and values discussed in the section above. Notice that the expiration period must be greater than the rollover period, and the TTL must be less than the overlap period. You wouldn't want a key to expire before it rolls over; likewise, you wouldn't want a TTL period to outlast the overlap period...if it did, the key could still be valid after the expiration period.

After you create and configure the Zone Signing Key(s) and Key Signing Key(s), the next step is to create a DNSSEC zone. A DNSSEC zone maps a domain name to a set of DNSSEC keys. In the BIG-IP, you create DNSSEC zones by navigating to Global Traffic >> DNSSEC Zone List and create a new zone. On this page, you can name the zone, configure state settings, assign algorithms, and activate zone keys. The hash algorithm options are SHA-1 (default) or SHA-256. The Zone Signing Key box specifies the zone keys that the BIG-IP uses to sign requests to a zone. The Key Signing Key works similar to the Zone Signing Key, except it is used to sign keys instead of requests. The following screenshot shows the options available for creating DNSSEC zones.

To fully secure a zone, the parent zone needs to have copies of the child's public key. The parent zone then signs the child's public key with their own key and sends it up to their parent...this pattern is followed all the way to the root zone. Once you have created the DNSSEC keys and zones, you can submit the Delegation Signer (DS) record to the administrators of your parent zone. They will sign the DS record with their own key and upload it to their zone.

You can find the DS record for your zone here: /config/gtm/dsset-dnssec.zone.name

There's a lot to DNSSEC, and this article wasn't written to capture it all, but I hope it sheds a little light on what DNSSEC is and how you can create zones and keys on your BIG-IP. Stay tuned for more BIG-IP GTM articles in the coming days, weeks, and months. Until then, keep those DNS requests flowing, and make sure they are valid with DNSSEC!

One last thing...did you know that F5 has an awesome Reference Architecture dedicated to Intelligent DNS Scale? The F5 Intelligent DNS Scale solution ensures that you can access your critical web, application, and database services whenever you need them...check it out!

Published May 21, 2014

Version 1.0