Tech Insight: The Basics Of Implementing DNSSEC

Implementing DNSSEC
As DNSSEC deployments grow, organizations will scramble to understand how to enable it, whether their current solutions support it, and what to do when DNS queries don't provide signed records. If your organization is running Bind or Microsoft's DNS server, then DNSSEC support is there. Each has its own configuration options and tips, so check the documentation and deployment guides before jumping in. You don't want to break your DNS lookup or publishing while trying to make it more secure.

Outsourced services should be reviewed closely. If you have given control of a zone to an outsourced provider, then you need to know when and how they will implement DNS. You can enable DNSSEC for the zones you host separately, but the parent must have DNSSEC enabled before subdomains will validate.

Don't forget about domains not owned by your organization but provide critical Web components, such as services like Akamai (which supports DNSSEC as of Aug.) or outsourced payment gateway services where users enter their credit card information.

There is little chancenon-signed records will be rejected in the near future, so if your organization does not sign your public records, the resolvers requesting the record will simply return the normal DNS response. The same goes for your internal systems. If a system requests a record and the domain is not DNSSEC-enabled, the normal DNS process will prevail.

Local clients that are DNSSEC-enabled will request DNSSEC records. If properly validated records are not returned, they should not provide the response to the application requesting the lookup. Some clients, such as Windows 7, do not perform validation, but rely on the results provided by their local DNS server. They assume the connection between the local DNS server and the end client is secure.

In these environments, without proper protections, an MITM attack is still possible at the local level. Microsoft recommends enabling IPSEC between clients and local DNS servers to secure the connection.

What Does DNSSEC NOT Do?
While DNSSEC provides validation that DNS queries are accurate, it doesn't solve all DNS-related problems -- and can introduce some new ones.

DNSSEC doesn't solve all problems of data transport security. DNSSEC does not provide confidentiality of data, protect against DDoS attacks, verify user identities, or stop IP spoofing. These issues are not unique to DNS, and must be addressed through other methods at the network or application layers.

Implementing DNSSEC can also introduce some new problems. The first is getting it working. Be sure that your firewall, IPS, or other packet filtering allows EDNS to function properly. With DNSSEC enabled, DNS responses larger than 512 bytes are required. This is problematic because some network equipment and filtering devices block UDP packets larger than 512 bytes by default. Work with your vendors to update or reconfigure your systems beforerolling out DNSSEC capabilities.

On the other end of the spectrum, EDNS allows responses more than 4096 bytes -- which could exceed the maximum default MTU size allowed by your systems. This could cause responses to be split into multiple fragments. Some security devices block fragments, thus preventing your new, shiny DNSSEC installation from functioning properly.

Learn from the mistakes of others. The .gov and .org top-layer domains both made implementation mistakes resulting in higher-than-average response times and higher bandwidth usage.

The .gov TLD used a 2048-bit key -- rather than the recommended 1024-bit key -- for signing, which caused each signature to be large. The .org TLD mistakenly set the time to live (TTL) for all .org records to zero, which told all downstream DNS servers not to cache the record and always request a new lookup each time the domain was requested. This caused a large spike in .org queries -- and in the bandwidth used to serve these requests.

How strong should your signing keys be? To answer this question, take into account other weaknesses in the process, the relative value of the DNS resource, and the overhead required for strong keys. The IETF's Section 3.4.2 of DNS Operational Practices, Version 2 discusses this topic.

Encryption keys used for signing will need to be rotated on occasion, and your decision on how to organization handles this will be important. Develop a method for rotating keys and test this process prior to signing production records.