DNSSEC Readiness

DNSSEC is coming. Is your organization ready?

The DNS community is buzzing with activity around the implementation of the DNS Security Extension, DNSSEC. In simple terms, DNSSEC provides a “chain of trust” within the DNS hierarchy and the authentication of DNS responses. Once deployed across the DNS, DNSSEC will render the infamous man-in-the-middle attack a thing of the past.

But DNSSEC adds many new twists to running a DNS service, both for authoritative and recursive customer-facing servers. At ISC, we are frequently asked what “being ready for DNSSEC” really means. Here are some things that you can expect when deploying DNSSEC.

DNSSEC Changes, In General

Regardless of the type of server (authoritative or recursive), many changes to the operational environment will come about with the adoption of DNSSEC.

Larger UDP packets

DNSSEC adds additional data to each answer that a server returns. These larger answers can sometimes exceed the packet sizes expected by some software and hardware. These larger packets may be returned even when the client is not using DNSSEC.

Increased TCP Usage

Larger UDP packets may trigger a more frequent fall-back to TCP. TCP is less efficient than UDP for DNS because it causes more network packets to be transferred for a single query and places additional memory requirements on both client and server.

Increased Memory Requirements

A DNSSEC signed zone is anywhere from 4 to 14 times the size of the original zone, when using RSA keys and signatures. This increase is dependent on the key size. Memory requirements will also increase when a new key is being “rolled.” This has a particular heavy impact on the DNS infrastructure of larger TLD Registries and others who service a very large zone.

Firewalls, Load Balancing, and DNS

Firewalls can cause no end of problems for the larger responses DNSSEC generates. Load balancer hardware may block larger packets or packets containing new DNSSEC record types. Both of these network components may decide an incoming packet is not acceptable and block it or change it in ways which break the DNSSEC protocol.

Authoritative Servers

This list is for people who run servers that serve DNS zones and who wish to sign them.

Additional Procedures When Changing Records

DNS used to be simpler. Zones only changed when new records were added or removed. This is no longer the case with DNSSEC. A signed zone is quite simple in concept: keys are added to the zone and used to generate signatures on the records in the zone. The complexities are in the details.

A DNSSEC zone has an imposed record order. This order is a necessary component of the means by which DNSSEC signals that a name does not exist. This ordering is handled automatically by the signing tools. However, if a new record is added to a signed zone, and the zone was not re-signed to add the signatures and this ordering, that new record would not be accepted by a validating client or resolver.

Signature Expiration

Typically, signatures are valid for a short time, such as one month. These signatures need to be refreshed by re-signing the records (or the entire zone) periodically. If a signature is allowed to expire, clients and resolvers cannot validate that data and will treat it as a failure. It is critical that zone signatures be maintained.

Key Management

Just like maintaining keys to an office building or your house, keys are critical to the security of DNSSEC. Without sufficiently strong keys and policies to prevent them from being compromised, DNSSEC adds no security.

The length of a key is one measure of its strength. Choosing a too-long key will cause more work on each resolver and slow the signing process. It will also generate larger signatures, increasing load in other areas. Using a too-short key will decrease security. Because DNSSEC uses two keys (one which can change much more rapidly and signs the majority of the zone data) a smaller, 1024-bit key may be sufficient for the “zone signing key.” A larger value may be desirable for the “key signing key,” perhaps 2048-bit. Please choose key lengths with caution and understand the implications carefully.

Key compromise might occur when an employee leaves a company and they choose to take a copy of the private parts of the DNSSEC keys with them, or through an attacker gaining access to a server, or because you generated weak keys and attackers were able to guess them.

Careful Selection of TTL

Each record in DNS has a “time to live” (TTL) value associated with it. This value tells a cache how long it may retain its copy of the given record. In general cases, the TTL on one record has no effect on other records in the zone. DNSSEC still uses a TTL, but there are subtle changes in how the TTLs of various types of records interact. In some cases, the TTL on the DNSKEY record may decrease the effective TTL on other records in the cache, for instance.

Keys and their signatures are one of the largest query types a server will generate. It is desirable to keep a large TTL value on keys, and indeed on many types of records. A larger TTL can cause problems when performing certain DNSSEC procedures such as rolling a new key. It may also increase recovery time when something bad happens, such as letting signatures expire.

Because each zone is different and its usage patterns vary, we do not suggest a single one-size-fits-all TTL value. However, we do not suggest longer than a week nor shorter than an hour for most TTL values which are not expected to change rapidly. A shorter TTL assists with agility for key rollover but puts more strain on the servers and network.

Emergency Procedures

To effectively deal with any unforeseen disasters, emergency procedures must be developed to re-generate keys and re-sign the zone in a worst-case scenario. For large zone files, this can further impact the requirements for memory, bandwidth, and performance.

Recursive Servers

This list is for people that run servers which serve customers, or other recursive clients.

New Failure Types

Queries that used to succeed may suddenly fail in new and creative ways. Previously the most common reason for a query not working was a simple network reachability problem; DNSSEC increases the variteies of networking failure that can occur. Queries can also fail for other reasons such as signature failures caused by poorly maintained DNSSEC signed zones.

NXDOMAIN Rewriting

Some organizations attempt to monetize failed DNS lookups, or attempt to be helpful in some way by providing an automatic search for possible terms when a user types an invalid address in a browser. This will break DNSSEC for the clients of this resolver if these clients are also performing DNSSEC validation. Allowing customers to opt-in or opt-out of any redirection service is required for end-to-end DNSSEC validation.

What to ask your vendors

Firewall, load balancers, and other middleware boxes

• The first and most important question to ask them is: Will this software or hardware interfere with DNSSEC? If they hedge or do not know, there may be danger ahead.
• Are UDP packets larger than 512 bytes handled correctly?
• Will the new record types (DNSKEY, RRSIG, NSEC, NSEC3, etc) be handled properly?
• What changes will be made to a packet by this software or hardware? If the records are changed or filtered in any way, chances are things will break.

DNS service providers

If you outsource any part of your DNS infrastructure, you may want to ask some questions about their DNSSEC plans.

• How are keys protected?
• How well do they understand DNSSEC?
• Who can you call when things are broken, and is it likely to be handled immediately or will it require waiting for "the DNSSEC expert" to wake up?

Geo-DNS and other global methods

Many companies use some form of load balancing based on the perceived location of the client. This generally involves rewriting the IP addresses or names returned. These services can still be used with DNSSEC by splitting the records out into their own zone and delegating that zone to the load balancing system.

Each record variant could also be signed, but this may be much harder to do in practice due to lack of production and experimental knowledge in this area. For now, using DNSSEC with any form of a server which generates answers on the fly or based on client location should be avoided.

Closing

DNSSEC adds many new complications to DNS. However, with careful planning, its usefulness will outweigh them.

If you need help

• ISC offers expert support and consulting services to help migrate into DNSSEC.
• ISC has training for all things DNS, and a class specifically for DNSSEC.
• If outsourcing service of zones is desired, ISC's SNS is a commercial-grade DNSSEC DNS service.
• ISC is the author of BIND 9, which as of 9.7 will perform automatic zone maintenance and resigning.
• BIND 9.7 also supports automatic maintenance of trust anchors for early adopters wishing to gain experience with a validating resolver.
• If maintaining a pile of trust anchors is undesirable, ISC's DLV service can assist.