How to check for EDNS0 support and troubleshoot it

Question

_{Monday, July 18, 2011 10:08 AM | 2 votes}

Lately, especially due to the wide adoption of the DNSSEC mechanism, the use of the EDNS0 mechanism became a need rather than an option, the problem is that there are still some DNS servers and some hardware devices (routers, firewalls) which lack support for EDNS0 causing issues like (for example) the ones reported in this Knowledge Base article (further infos/details/troubleshooting-infos related to EDNS and Windows DNS may be found here)

Now, while there are ways to reconfigure the DNS resolvers or the hardware to enable EDNS0 support, it isn't easy to check if they are, in effect, working; worse, sometimes one may either be using external DNS servers (for example as forwarders) which don't support EDNS0 or either the hardware/software config can't be changed (e.g. a router leased from the ISP or an external DNS used as forwarder), in those cases, it's difficult to tell if the DNS servers or devices do support the EDNS mechanism and what is acting as a showstopper, so, this short note just tries to help performing such checks

Let's start from this online check tool, it allows to run some DNS queries and check if the "resolver chain" does in effect support the "oversized UDP packets" needed for EDNS0 to work; basically, to run the tool you'll enter a command like this

nslookup -type=TXT rs.dns-oarc.net.

and the output of the command will tell you if your current "resolver chain" (meaning both the DNS resolvers and the involved network hardware) are supporting the EDNS0 or not and, if they support it, which is the maximum allowed UDP packet size

The above may suffice to start checking for EDNS0 support, but since spotting the "show stoppers" may be tricky, I'll try to sketch a short howto which may hopefully allow you to find out "what" is stopping EDNS0 traffic

To start, let's issue a query toward a public DNS resolver known to support the EDNS0 mechanism, in our case we'll use one of the public Level-3 resolvers, so we'll run

nslookup -type=TXT rs.dns-oarc.net. 4.2.2.6

the above tells nslookup to run the EDNS0 test we already saw, but using the DNS resolver sitting at 4.2.2.6 instead of whatever locally configured DNS resolver; if the test will fail or return "no EDNS0" then, given that the resolver at 4.2.2.6 DOES support EDNS0, it most probably means that some of the hardware along the path is playing tricks with DNS queries, so we'll need to start checking for routers/firewalls and ensure they aren't "truncating" DNS traffic (the same goes in case we have some "transparent DNS proxy" along the path)

Once the above will be ok, we may move on by checking if our DNS resolvers are using forwarders, if so, we'll need ensure the forwarders do, in turn, support EDNS0, to do so we'll repeat the above test but using the IPs of the forwarders we're using in place of that 4.2.2.6; again, in case a given forwarder doesn't support EDNS0 we'll either need to change its config, ask someone else (who manages those DNS servers) about EDNS0 support, stop using that forwarder or even ... totally avoid using forwarders

Anyhow, given the above, once again, is ok, we may then perform the last check; that is, running the above test against our own DNS resolvers and checking if they support EDNS0, if this isn't the case, then we'll need to revise the config of our DNS resolvers until the EDNS0 check will be passed

That's all, given the above, at this point our DNS resolvers should be able to use EDNS0 withouth problems.

I just hope the above short instructions will be helpful to people dealing with DNS issues and EDNS0 in particular.

All replies (1)

_{Monday, July 18, 2011 1:52 PM | 1 vote}

A couple additional notes; a number of "public DNS resolvers" do NOT support EDNS0, namely, amongst others, the OpenDNS resolvers (208.67.222.222 and 208.67.220.220) and the Google DNS resolvers (8.8.8.8 and 8.8.4.4) do NOT support EDNS0 (at least they currently don't), so, if you are using those servers as "forwarders" and are experiencing DNS issues, try removing the forwarders and just switch to regular, recursive resolution using just the root-hints

Also, and since we're at EDNS and DNSSEC; here you'll find further infos about DNSSEC and Windows, and here you'll find a useful tool which allows to check the DNSSEC (and EDNS) configuration of whatever server