Some weeks ago, we installed a reply-size tester application at the global instances of K-root. We want to make this test available to more people, in an easy-to-use way. We have therefore written a Java application for this purpose.
Please note that the reply-size tester tool will not be available anymore on RIPE Labs as of 11 October 2010. You can still access the tool on the OARC web site:
https://www.dns-oarc.net/oarc/services/replysizetest
Some weeks ago, we installed a reply-size tester application at the global instances of K-root. Anyone using a unix-like system can use a command-line DNS query tool such as dig to run a special query, which will make use of this reply-size tester to try and determine the maximum size of a DNS response packet a resolver can handle.
This form of testing, however, is limited to those with a technical background and access to a DNS query tool such as dig. We wanted to make this test available to more people, in an easy-to-use way. We have therefore written a Java application for this purpose. Almost all users these days have a Java runtime installed, so running this application is as simple as downloading a single .jar file, and double-clicking on it.
Running the application: (updated on 28-1-2010)
Get the application here:
replysizetest-1.1.jar
(MD5 checksum 420bddc70a60c5c93a0d33185a5a3caf) (Please see updated link above)
When you run the application, 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. You can just click on 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 which isn't in the list, select "Other" and click on OK, and you'll get a text box where you can type in the address of a resolver.
This application essentially performs the query "dig txt test.rs.ripe.net" against a resolver. When the test completes, it displays one of four results in different colours, with green representing no problems, yellow indicating some problems, and red indicating potentially serious problems. However, even if you see a result in red, please do not panic. It doesn't mean that your resolver is broken. It just means that there is a greater chance that this resolver will have difficulties resolving names when the root zone is signed with DNSSEC.
If the application gives you an internal software error message, it generally means that the java virtual machine on your system is restricted from certain operations. Try disabling your firewall. If this still doesn't help, you can run this test manually using the "dig" command-line tool, as described
here
.
If the test completes, and you have some results, please refer to the table below to interpret the result:
| 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. However, you will not benefit from the security that DNSSEC introduces into the root zone. |
|
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, and take longer to respond to a query. |
|
Your resolver announced a buffer size bigger than the largest packet that it can receive |
This scenario can cause problems for a resolver, because it expects to receive large responses, but they never make it through for a number of reasons. The most common causes are firewalls which block DNS packets bigger than 512 bytes, or fragmentation, which causes a large DNS packet to be broken up into smaller fragments which routers and/or firewalls don't know how to handle. We recommend that you configure your network, routers and firewalls to handle larger packets and/or fragments. If this isn't a viable option, you could consider lowering the announced buffer size in your resolver to match the actual size that it can receive. This will at least allow packets to get through, even if it causes truncation. Your resolver can then immediately fall back to TCP. See below on how to configure BIND and Unbound to set specific buffer sizes. |
| Your resolver was only able to get packets SMALLER than 512 bytes | This usually implies that a packet filter or firewall is blocking UDP packets bigger than 512 bytes from reaching your resolver. Your resolver works now, although it is probably not able to resolve some names. However, when the root zone is signed your resolver will not be able to receive most responses, and it is possible that you will lose DNS service. You should reconfigure your firewall or packet filter to allow large UDP packets through. |
If this tool reveals that your resolver is announcing a bigger buffer size than it can handle, first check to see whether the difference between the announced buffer size and measured buffer size is small. Because of the way the algorithm works, there will always be a small difference between announced and measured buffer sizes. You don't need to worry if the difference is small (up to 300 bytes). However, if your announced buffer size is the default of 4096 bytes, and the measured buffer size is much smaller (say 1400 bytes), then it is a cause for concern. You should reconfigure your resolver to announce a buffer size which is equal to the measured buffer size. Let's call this size "n".
Configuring 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
Configuring Unbound to use a specific buffer size:
Add the following line to the "server" section of your unbound.conf file:
edns-buffer-size: n
Comments 6
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Anonymous •
It's "edns-udp-size n;" for bind 9.<br /><br />See: <a href="http://www.zytrax.com/books/dns/ch7/hkpng.html" rel="nofollow">http://www.zytrax.com/books/dns/ch7/hkpng.html</a><br /><br />If you use "edns-udp-size: n" bind will crash.
Anonymous •
Hello.There are lots of strange links here which has no reliance with the subject.I am afraid to visit them if only i am using Kasperky antivirus which is the first in top ten best antiviurses <a href="http://www.best-antivirus.co/" rel="nofollow">http://www.best-antivirus.co/</a><br />good luck<br />
Hide replies
Anonymous •
Thanks for pointing this out. They were clearly not related to the topic and we removed those comments.
Anonymous •
Thank you again, Comcast. While they weren't wholly responsible this time (as they are for internet usage caps), they were again the first to force things onto their customers.<br /><br />IPv6 was necessary. Bandwidth limiting was not. Neither is DNSSEC, which includes privacy-threatening authentication components that compromise one of the internet's best assets: anonymity. Under this protocol, a few bad apples spoil the barrel.<br /><br />DNSSEC is a dream for merchants, institutions and governments. It's yet-another intrusive measure to the little guys.
Hide replies
Tom •
You should use a DNS host that changes the DNSSEC keys hourly your info is not affected look at DynECT
tom novotny •
Why does the link https://labs.ripe.net/Members/anandb/replysizetest-1.1.jar redirects me to profile editation. I want NOTHING change on profile,just download the utill :( :(