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...