DNS specifications are documented in the RFC 882, which I think was created in 1983. Time has passed and our requirements for DNS changed. We may want to add additional information in the small UDP packets that DNS uses, but – guess what – there is no space left. Unfortunately DNS uses a small number of 1-bit flags that indicate what and how a query should work. The RFC dictates that there is space for 7 flags, and we cannot add more, because there is no space in the packet.
DNS prefers to use UDP packets because they are small and can be transferred fast (there is a lot of DNS traffic in the internet). The maximum packet size is 512 bytes, based on the 80s conditions (slow connections, unreliable lines, etc). Have you ever noticed that most domain names on the internet use less than 13 DNS Servers? Even the root servers are only 13 (but there are more, don’t worry, there is a big cluster of 236 DNS Servers that makes them appear fewer). Restrictions that nowadays could be eliminated and expand DNS but… what about the transition process and compatibility? We should find a different and clever way to expand DNS to use bigger packets and still maintain compatibility with older DNS Servers.
The answer is EDNS, which is described in RFC2671. EDNS is a clever mechanism that allows a DNS Server to understand if it talks to another DNS Server that supports EDNS also. If they both support EDNS, they can exchange the “magic” bigger packets and they are not limited to 512 bytes.
When a EDNS-aware DNS Server queries another DNS Server, it simply adds an extra record to this request. This is a new type of a DNS record, specifically created for EDNS, called an OPT record. This is not a record like the others you already know (A, CNAME, MX). In fact you’ll never see an OPT record in a zone file, it’s more like a secret talk that DNS Servers use in order to realize if they can use EDNS or not.
Let’s assume that my DNS Server, which supports EDNS, wants to get the A record of a machine called PC32 in the contoso.com domain. A DNS Server that does not support EDNS would simply ask for the record and that’s all. My DNS Server that supports EDNS will ask additional information. The first query would be: “I want you to tell me the IP address of a machine called PC32 in the contoso.com zone”, but there is a second query that would say: “Here is an OPT query for you with the value of 4000”. Practically my DNS Server is saying: “I can handle large EDNS packets, so you can send me a UDP packet up to 4000 bytes”. Here is the clever part: if the other DNS Server cannot use EDNS, will simply ignore the OPT query and respond as usual. But if the other DNS Server understands the OPT query, will reply with his own OPT value, saying something like this: “Ok I can handle large UDP packets but only up to 1024 bytes.”. So now both DNS Servers know that they can use EDNS, but the largest UDP packet can be 1024 bytes.
The only problem here is that these larger packets may become fragmented (keep in mind that 512-bytes packets almost never become fragmented) and some cheap NAT routers may discard them. Some firewalls may do the same: “if a packet is DNS and UDP and larger than 512 bytes it’s something very bad so discard it.” . In both cases we have a failed name resolution process.
It’s very easy to disable and enable EDNS on Windows Server 2008 R2, simply type
dnscmd /config /enableednsprobes 0
without a reboot. However keep in mind that this command simply prevents Server 2008 R2 from starting an EDNS conversation. If an external DNS Server starts the conversation and asks our DNS Server for a large UDP packet, our server will respond using EDNS again, so maybe it’s time to take a look at your routers and firewalls and make sure they do not block large UDP packets.
Statistics say that 85% of DNS servers use EDNS already, so don’t disable EDNS on your DNS Server, it seems to be a really good feature.
Speaking of DNS features, in a future article we’ll talk about DNSSEC. It’s a big story, so I’m thinking of making a Server Nights presentation on this, probably in May or June so stay tuned.