Category: DNSSEC

An Internet Service Provider needs to offer high value while containing costs. One way to increase your services’ value is to ensure your customers get to the intended websites, protecting them from going to phishing sites or sites that distribute malware.

One way to offer such protection at relatively little cost is through DNS Security Extensions, an Internet standard commonly known as “DNSSEC“. By deploying “DNSSEC-validating” DNS resolvers within your network, you will provide a higher level of security and trust to your customers and help prevent certain types of attacks and redirection. You also will enable customers to use innovative services that are now becoming available to add more trust and integrity protection to Web certificates (SSL/TLS).

DNSSEC ensures that the information your users retrieve from the DNS is the same information that the domain’s operator entered into the DNS. It verifies that this information was not modified so that your users are directed to their intended destinations.

DNSSEC has two components: the signing of DNS records for a domain and the validation of those cryptographic signatures by caching recursive nameservers. For an ISP, the deployment of DNSSEC-validating DNS resolvers is the most critical element of DNSSEC adoption and this document explains what is necessary to roll out DNSSEC validation support to your customers.

Initial deployment of DNSSEC validation is usually quite inexpensive, requiring a relatively small investment in new hardware and software and only a modest time investment; typical deployment may be completed with as little as a week of total effort by experienced system administrators, depending on how many recursive nameservers and end users are involved.

Hardware and Software

Caching recursive nameservers are the most important part of a DNSSEC validation deployment since they cache and validate answers to DNS queries submitted by end users. Modern, off-the-shelf server hardware is sufficiently powerful to operate a DNSSEC-validating caching recursive nameserver. In addition, it is perfectly feasible to operate such a nameserver on a virtual machine.

Your choice of nameserver and its vintage are important to your success with DNSSEC. DNS infrastructures based on the BIND DNS server should run at least version 9.7, whose features simplify DNSSEC management. All versions of Unbound natively support DNSSEC validation, although version 1.4 and later have features that simplify DNSSEC management.

Microsoft Windows Server 2012 now includes full DNSSEC support, allowing administrators to retrieve the necessary root trust anchors via command-line instructions. A whitepaper by Netherlands DNSSEC authority Surfnet explains this process; you can download the PDF of their guide to DNSSEC installation here.

Effects on Network

In your planning, you should be aware that DNSSEC traffic has several effects on network traffic:

• DNSSEC adds digital signatures to DNS response packets, which often exceed 1,500 bytes. While large DNS responses are also possible without DNSSEC, you must consider the additional bandwidth demands that DNSSEC places on the network, and ensure that only legitimate hosts are allowed to query your recursive nameservers.
• Traditionally, the DNS relies on the UDP protocol to transmit queries and responses, but if a DNS response exceeds the maximum allowed packet size, TCP may be used and even required for DNSSEC validation. Check with your firewall vendor and system administrators to ensure your network allows DNS over TCP.
• Your network equipment must be able to handle large UDP packets (>512 bytes, ≤4,000 bytes).

Pre-Deployment Checklist

This checklist can help you to plan your deployment:

• Software supports DNSSEC: BIND version 9.7+, Unbound version 1.4+, Microsoft Windows Server 2012, Knot DNS 1.4.0, PowerDNS 3.0+
• Server systems are sufficiently modern
• Network infrastructure can handle DNSSEC requirements
• DNS over TCP is allowed
• Large UDP DNS packets are allowed through firewall
• UDP fragments are not blocked by firewall

Beginning Your Deployment

After your install your recursive caching nameservers (or have existing nameservers where you want to start validating), they must be configured with a “trust anchor” in order to validate DNSSEC signatures. You can obtain the trust anchor for the root of the DNS from sources such as https://www.iana.org/dnssec. You can check the trust anchor’s validity by obtaining it from multiple independent sources (i.e. multiple root servers) and comparing the files.

When you enable DNSSEC validation on your recursive caching nameserver you may see validation failures in the log files. While these errors could be signs of a cache-poisoning attack, they may also result from operational errors (particularly in these early days of DNSSEC deployment). This could be something as simple as a zone owner’s failure to re-sign their zone information.

Validation failures for a zone will mean that your users will not be able to connect to that domain. When errors of this type appear it is far better to inform users about the source of the problem and how they were protected from using potentially insecure information, rather than disabling validation in order to provide continued access to the “broken” domain. Standards concerning how to perform this notification continue to evolve, though some organizations have used a dedicated website or social-media channel to post notifications of current validation failures. Regardless of what system you create, it is important that your customers and customer-support team can easily find the information.

Certain ISPs may also install a temporary “negative trust anchor” for broken sites while notifying the zone’s operators of problems or errors that will probably severely degrade their users’ Internet experience. An Internet Draft document is available that explains this process.

While feedback from people currently operating validating caching recursive nameservers show that enabling DNSSEC validation does not necessarily increase user help-desk calls, it is still sensible to train help-desk staff concerning DNSSEC and potentially provide them with tools (i.e. a non-validating resolver) to help with debugging.

Conclusions

DNSSEC rollout is progressing steadily on the Internet, and deployment of validating caching recursive nameservers is an important part of this trend. By deploying DNSSEC within your network you will increase your customers’ Internet security. Doing so provides significant benefits at a minimal cost, and we urge you to begin this process today.