O.K., here's a stumper that authors and tech gurus Mark Minasi and Brett Hill hit me with when we were all speakers at the recent MCP TechMentor conference. Say your company's DNS queries are working just fine through the company firewall. Then, all of a sudden, some queries stop working. You trace the problem down to Yahoo.com queries, and narrow it down even further to just queries made by the company's DNS server, seeking a list of authoritative Yahoo.com DNS servers. That's a common enough operation when a DNS server is configured to use root hints, rather than a forwarder, to resolve DNS names.

Now the stumper: The end reason for the problem is that Yahoo added a DNS server to their farm, and it's your fault -- not Yahoo's -- that the DNS queries quit working.

Take a minute and think about it. Mark and Brett had a big smirk on their faces when they explained all of this, and had a great time completely stumping me. Here's a hint that I didn't get: Wade through the official DNS RFC (http://www.faqs.org/rfcs/rfc1035.html) for the answer. C'mon, it's only 43 pages long!

O.K., I'll let you off the hook. Here's what happened: The company set up their firewall to allow DNS queries to go out on UDP port 53. That's pretty standard, and it'll usually work. After all, DNS queries tend to be pretty small, and there's little sense in setting up the whole handshake-response channel required for TCP connections. Yes, with UDP there's a chance that the DNS query will get lost, but in that case the DNS client can just resend the query after a second or two. No problem. In fact, RFC 1035 specifically says that UDP will be used for DNS queries, and that lost packets will be handled by simply retransmitting the query.

DNS does, of course, use the connection-oriented TCP protocol for zone transfers, which involve a lot more data than simple queries. Using TCP is actually more efficient and reliable in this case, since the zone transfer data will have to be broken into multiple packets. TCP can ensure that all of the packets arrive at the destination, and are reassembled back into the original data stream. However, most companies don't do zone transfers through their firewalls to or from outside DNS servers, so it's rare to see TCP port 53 opened in the firewall. In fact, in today's security-conscious IT shops, you're a lot more likely to see TCP 53 blocked, since it isn't used for legitimate traffic.

When a client gets back a DNS reply from a DNS server, the response comes over UDP, and includes an "answer section" that contains the records the client asked for. For example, Figure 1 shows a Network Monitor capture of a DNS response, with the answer section highlighted. As you can see, this answer to the query for my.yahoo.com returned two resource records, giving the client computer two possible IP addresses to choose from.

Figure 1. DNS response in Network Monitor. (Click image to view larger version.)

Of course, you and I both know that my.yahoo.com consists of more than two servers. In fact, the two IP addresses provided in this response are virtual IPs, meaning that each one points to a different Web farm, and each farm may consist of dozens of load-balanced servers. Using virtual IPs is a common trick on the Internet, and it gives Yahoo the ability to easily control their load balancing situation. It's pretty unusual to see large DNS responses, since most companies simply provide a virtual IP address or two to represent potentially hundreds of Web servers.

Figure 2 shows another important attribute of the DNS response: It's only 192 bytes long. Network Monitor shows that in the UDP header (highlighted). Why is that important? Well, if you've got RFC 1035 open, scroll down to section 4.2, entitled Transport.

Figure 2. Checking the packet size in Network Monitor. (Click image to view larger version.)

Section 4.2.1 specifically covers the use of UDP to transport DNS queries and responses. It says, and I quote, "Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header." This implies that UDP can be used for longer queries. However, the RFC goes on to say, "UDP is not acceptable for zone transfers, but is the recommended method for standard queries in the Internet. Queries sent using UDP may be lost, and hence a retransmission strategy is required. Queries or their responses may be reordered by the network, or by processing in name servers, so resolvers should not depend on them being returned in order."

What's all that mean? It means just what I said: UDP is fine for smaller queries that can be transmitted in a single packet, but isn't so hot for longer queries. And that brings us back to what happened when Yahoo added another server.

In this particular instance, Yahoo had added a 14th DNS server to their farm. Not many folks use virtual IPs for DNS servers; if one DNS server asks for a list of authoritative DNS servers for a domain, the response will contain the real IP addresses of every valid DNS server that the target domain has to offer. To provide fault tolerance and load balancing, most major Internet presences like Yahoo might have a dozen servers or more. In this case, they apparently had 14, to be exact.

Fourteen servers apparently pushed the response's packet size over the critical 512 byte limit. Thus, when clients (or other DNS servers) attempted to query a list of Yahoo DNS servers, Yahoo tried to set up a TCP connection for the response. Since the company had allowed UDP port 53 in the firewall, the DNS query went out -- but because TCP port 53 hadn't been opened, the reply never made it back through. The problem seemed intermittent, too, because most DNS replies still fit into 512 bytes and came back through via UDP.

So what's the moral of this story?

First, of course, is to not let Mark and Brett pin you down with protocol questions over a friendly glass of wine after a day-long conference session. I learned that one!

Second, hop on your firewall and make sure TCP and UDP 53 are both available for queries and responses. Finally, make sure you thoroughly understand the networking protocols that you work with. While you may have known this bit of DNS trivia, there are dozens more for every major protocol we work with every day. Coming Next Month: Don tackles a different type of remote Exchange access.

Questions? Comments? Stupid DNS tricks of your own to share? Post 'em below!