Ready for DNSSEC?

David Avery
November 29, 2012

Today’s news about a hacker redirecting Romanian web surfers looking for Yahoo, Microsoft or Google to a page showing a TV test card demonstrates how a small group (or one person) can easily disrupt millions of users.

The hack was accomplished by apparently poisoning Google's public DNS system, causing, and visitors receive a relatively innocuous message from a known Algerian cyber “artist” named MCA-CRB. Web browsers were redirected to an animated GIF background that looked like a test card.

While debate is still ongoing as to the location and extent of the hack, it does highlight the need for enterprises to protect their domain name system (DNS) from malicious intrusion.

Domain Name System Security Extensions (DNSSEC) is a system designed to guarantee the authenticity of data obtained from the DNS. It is described by many Requests for Comments (RFCs), including but not limited to RFC 4033 (DNS Security Introduction and Requirements), RFC 4034 (Resource Records for the DNS Security Extensions) and RFC 4035 (Protocol Modifications for the DNS Security Extensions). DNSSEC uses resource records, flags within the DNS header and protocol extensions to make this authentication possible.

DNSSEC deployment is growing, although not as fast as some would like. Many top-level domains (.com, .org, .net, .gov) are now signing their domains. While the top-level .edu domain is also signed, higher education has been slow to adopt the DNSSEC. As of January 2012, ICANN now requires that all new generic top-level domains support DNSSEC.

On January 10, 2012, Comcast became the first ISP in North America to fully deploy DNSSEC (and subsequently block access to This is a big step forward for DNSSEC, and with the FCC urging ISPs to follow suit as soon as possible, one can hope that continued deployment translates into a safer experience for their customers.

As DNSSEC is deployed globally, there are many concerns for both carriers and enterprises, such as the performance of security devices, bandwidth issues and more. But if you are testing properly using DNSSEC, you can avoid any issues.

How DNSSEC Works

First, for those who are not versed in DNS, here is a quick and high-level example of how a response is authenticated (if you already know this, skip to the testing). A resolver submits a DNS query for the A record of a host, explaining in its request that it accepts DNSSEC resource records. The DNS server constructs the response data (which includes the A record) and creates a digest of that data. The DNS server then encrypts the digest with its private key and places the resulting signature in a RRSIG resource record. This RRSIG record is included in the response. The resolver will use the corresponding public key (obtained from the DNS server in a DNSKEY resource record and also authenticated) to decrypt the data in the RRSIG record. The resolver will then compare the decrypted data to its own digest. If the digests are identical, then the data is authentic.

Considerations When Deploying DNSSEC in Your Network

While testing DNSSEC deployments certainly involves the chain-of-trust system for validating signatures and testing DNS server conformance, there are other considerations of which network and system administrators should be aware. This is particularly true for networks containing DNS servers that perform recursive lookups.

One concern is the additional bandwidth required to support not only the increase in DNS transactions but also the digital signatures that result in larger message sizes. If DNS exists in a Quality of Service class with other protocols, the additional bandwidth could negatively affect the other protocols in that class. Similarly, if DNS traffic is prioritized based on its pre-DNSSEC utilization, then the service may be negatively affected as DNS traffic increases.

On the topic of larger DNS response sizes, firewalls must be tested to ensure that large DNS messages are not automatically discarded. Older firewalls may not support the EDNS0 (RFC 2671) mechanism, which enables DNS clients and servers to communicate the ability to support messages over 512 bytes in size. Firewalls without EDNS0 support are at a disadvantage, as they have less specific criteria by which to determine the legitimacy of DNS traffic.

The EDNS0 mechanism allows a UDP DNS response to be larger than the MTU, in which cases UDP fragmentation would occur. Firewalls that do not allow UDP fragmentation will prevent DNSSEC traffic from reaching its destination. If UDP fragmentation is allowed and the device is performing reassembly before applying its rules, then administrators must ensure that the additional resources allocated to that task are available and the ability to inspect non-DNS traffic is not jeopardized.

Testing DNSSEC Deployments Using Ixia BreakingPoint Solutions

All our products now have support for DNSSEC, making the following test scenarios possible:

  • Test network performance by simulating millions of concurrent DNSSEC transactions at high data rates. Using the Ixia BreakingPoint FireStorm, our new built-in DNSSEC Super Flow is capable of achieving more than nine million concurrent sessions!
  • Test the resiliency of network devices by sending malformed DNS requests and responses across the network.
  • Test resource utilization of DNSSEC-enabled DNS servers.
  • Manipulate DNS query data and header flags to ensure DNS server resiliency against unexpected input.
  • Run Application Simulator or Client Simulator simultaneously with the Ixia BreakingPoint Security component to test your firewall’s ability to discern malicious DNS traffic from valid traffic.

It’s simple. Test now and you’ll avoid problems later. This is why Ixia BreakingPoint solutions allow you to simulate millions of DNS resolvers and/or servers across a vast array of network topologies. Using these, you can test the effects of deploying DNSSEC on your network without deploying a single DNS server.

Related Content:

3 Things You Need to Know About Carrier-Grade NAT

Carrier-Grade NAT Testing Solutions

blog comments powered by Disqus