How to test your resolver for DNS reply-size issues

The DNSSEC protocol will bring improved security to the internet but also larger packet sizes. Before you run into problems, you can check that your resolver is able to cope with these larger packets, as Anand Buddhdev explains.

The internet community worldwide is deploying the DNSSEC — short for Domain Name System Security Extensions — protocol, which will increase internet security by preventing hackers from redirecting traffic from legitimate websites to fraudulent ones.

DNSSEC will attach a digital signature to responses from name servers. This signature acts as an assurance that internet users are not being redirected to a fraudulent website. But some networking equipment does not accept DNS responses that are over 512 bytes or that are split into several packets.

Following the signing of the J-root in May 2010, all root servers are now serving a deliberately unvalidatable root zone — or Durz for short — which in practice means that root servers will return signed DNSSEC answers to queries asking for them.

Durz is important because the DNSSEC upgrade will attach a digital signature to every response from the root servers, whereby the DNS resolver software requests signed responses.

The Durz is a deliberate attempt by the internet community to slowly phase in the larger responses that DNSSEC produces, allowing people to resolve network issues before DNSSEC is enabled for the entire root zone on 15 July.

This move helps diminish the risk that some DNS resolvers will not be able to cope with the larger packet sizes brought on by DNSSEC once it becomes fully operational.

Additionally, the Ripe NCC has installed a reply-size tester application at the global instances of K-root. Anyone with a Unix-like system can use a command-line DNS query tool such as Dig to run a special query that uses this reply-size tester to determine the maximum size of a DNS response packet a resolver can handle.

But this form of testing is limited to those with a technical background and access to a DNS query tool such as Dig. The Ripe NCC wanted to make this test easily available to more people, so the organisation has developed a Java application, which is available for download for free.

Running the application is very easy. It will bring up a dialog box with a list of the IP addresses of the resolvers that it detects on your system, with the first one automatically selected. Just click 'OK' to begin the test. If you want to test another resolver, select its address from the drop-down list. If you want to test a resolver that is not listed, select 'Other', and you will get a text box where you can type in the address of a resolver.

The application essentially performs the query dig txt test.rs.ripe.net against a resolver. When the test is completed, your result will be displayed in a traffic light system, with green representing no problems, yellow indicating some problems and red indicating potentially serious problems. If your result is red it means that the resolver may experience difficulties resolving names when the root zone is signed with DNSSEC.

If the application gives you an internal software error message, it is likely to mean that the Java virtual machine on your system restricts certain operations. As a first step, try disabling your firewall, but if this doesn't help, you can run the test manually using the Dig command-line tool.

Here is a brief summary of the possible results, and what you need to do next.

Your resolver does not have DNSSEC
Your resolver will not be affected when the root zone is signed. It will continue to work as it does now, but you will not benefit from the security that DNSSEC introduces.

Your resolver announced a buffer size smaller than the recommended minimum of 850 bytes
A typical query to the signed root zone will result in either a referral or an NXDOMAIN response. Neither of these responses is likely to exceed 850 bytes in size, and so using a buffer size of at least 850 bytes ensures that most responses come through completely.

However, using a smaller buffer will cause responses to be...

...truncated, and your resolver will have to fall back to TCP queries, which means it will take longer to respond to a query.

Your resolver announced a buffer size bigger than the largest packet that it can receive
This situation can cause problems for a resolver, because these responses never make it through for a number of reasons.

The most common cause is that you have a firewall that blocks DNS packets bigger than 512 bytes, or fragmentation, which means that a large DNS packet is broken up into smaller fragments, which routers or firewalls don't know how to handle.

The Ripe NCC recommends that you configure your network, routers and firewalls to handle larger packets and fragments. If this isn't a viable option, consider lowering the announced buffer size in your resolver to match the actual size that it can receive.

This measure will allow packets to get through, and even if there is some truncation, your resolver can immediately fall back to TCP. I'll explain later how to configure Bind and Unbound to set specific buffer sizes.

Your resolver was only able to receive packets smaller than 512 bytes
This situation usually implies that a packet filter or firewall is blocking UDP packets bigger than 512 bytes from reaching your resolver. Your resolver works but it is probably not able to resolve some names.

However, importantly, when the root zone is signed, your resolver will not be able to receive most responses, and you may lose DNS service. You should reconfigure your firewall or packet filter to allow large UDP packets through.

If the tool reveals that your resolver is announcing a bigger buffer size than it can handle, check first the difference between the announced buffer size and measured buffer size. Because of the way the algorithm works, there will always be a small difference between announced and measured buffer sizes, so you don't need to worry if the difference is small, or up to 300 bytes.

However, if your announced buffer size is the default of 4,096 bytes, and the measured buffer size is much smaller — say, 1,400 bytes — then it is a cause for concern, and you should reconfigure your resolver to announce a buffer size that is equal to the measured buffer size.

Let's call this size 'n'. To configure Bind to use a specific buffer size — only for Bind 9.3.2 and newer — add the following line to the Options section of your named.conf file: 'edns-udp-size: n'.

To configure Unbound to use a specific buffer size, add the following line to the Server section of your unbound.conf file: 'edns-buffer-size: n'.

It is crucial that all ISPs ensure that their servers are able to cope with the global roll-out of DNSSEC on 15 July. This is the final stretch of a considerable collaborative project by the internet community, which will provide an added layer of security against cache-poisoning attacks and, ultimately, help increase internet security for all.

Anand Buddhdev is DNS services manager at the Ripe NCC, the not-for-profit organisation that supports the infrastructure of the internet and operates the K-root name server.