So you’re encountering some strange DNS issues. Have you thought to check out EDNS?
Today, I’m blogging about an issue I’ve seen occurring more and more lately with the EDNS protocol. As a member of Fpweb.net’s Support team, when I stumble across something that seems to be tripping others up, I do my best to solve it and then blog about it here to help push everyone in the right direction. So, first things first…
What is EDNS?
It stands for Extended DNS, (yes I know I just explained an acronym with an acronym, but hopefully you know what DNS is… if not, it’s Domain Name System). Without going too in-depth, EDNS exists because the original DNS protocol uses UDP and stores information in a way that fills the entire UDP packet – meaning you can’t add additional info to the packet. EDNS “tacks on” an extra packet for additional information so you can utilize more services in DNS; the most popular being DNSSEC. The irony here is that it also opens you up to an attack using packets called DNS amplification.
How does EDNS work?
Ideally, since this extra information is “tacked on”, servers that do not support EDNS simply ignore the query for more information and provide the regular DNS information, while servers that do support EDNS provide this extra information, making this a compatible protocol.
So what’s the problem?
The problem comes into play during certain implementations. Most servers are now EDNS compatible, so typically you won’t have an issue with this protocol. However, when you do encounter an environment that has an issue using EDNS, (reasons for this will be explained later), it can be very hard to diagnose. If you’re having very strange DNS responses and testing reveals no obvious culprit, this is usually the problem.
The main symptoms include DNS requests timing out for only particular domain names, (yet using NSLookup to specify a public DNS server returns results just fine for the domain in question), and having no issues requesting this domain’s DNS from other servers in other networks. Therefore, at first it will appear that this makes no sense, as DNS is typically pretty easy to troubleshoot due to the nature of being able to narrow down the culprits quickly.
The issue’s other symptom is the fact that occasionally, it will work. You will run NSLookup from the problematic server, and one out of approximately ten times it will suddenly work. Essentially, if you are running into very strange DNS problems and normal testing returns odd results, it is worth investigating EDNS as the issue since the test only takes seconds to implement.
How do I test/fix DNS issues?
The long and short is to disable EDNS from your server (which is on by default for Windows environments). Once done, if you immediately receive consistent DNS results to the problematic domain, you have found your solution. If it does not, the process is just as quickly reversible. To disable EDNS from the DNS server that cannot return DNS results from the primary DNS server, open a command prompt and type the following:
dnscmd /config /enableednsprobes 0
Then simply press Enter.
It should look like this:
Now test your DNS query once again. If it works, you have found your culprit. (I told you this was quick).
Why does this happen?
It’s possible for a few different reasons, but mainly just two. One is that these packets can suffer from defragmentation and be disregarded, and the other is that they can be blocked by network security, (due to the large packet return size). By running the above command, we’ve told our DNS server to not SEND EDNS packets or initiate them.
The server will still theoretically respond to other servers request for EDNS when queried. Other solutions could possibly involve limiting the size of the requests, which is possible, in order to satisfy the conditions causing these packets to be shunned. However, this is much more in depth than simply disabling it.
I hope this helps somebody out there. I know I’ve had some very long days trying to figure out DNS issues that didn’t make any sense until I stumbled upon this solution. And while it was not a frequent issue, it was frequent enough to where I felt others needed to know about it. Of all DNS issues I had encountered, most could be figured out by simply following the configurations down far enough, or had errors correlating to the DNS service itself encountering an error and was easily diagnosed and fixed accordingly. This issue is the exception, because at the core of this issue lies a network configuration stopping a service addition to DNS that you probably didn’t even realize you were using.