A DNS Puzzler


By A.P. Lawrence
Expert Author
Article Date: 2007-09-28

Here's an interesting puzzle involving DNS.

It's about Windows, Linux, and OS X, and I don't have a complete answer yet, but I thought I'd share what I've found so far.

The other day I was working on my Mac and wanted to access my.calendars.net. I couldn't, and my browser told me that "Firefox can't find the server at my.calendars.net". I assumed the site was down, but later in the day I happened to be working at my wife's computer for a few minutes, and while I was there I tried again and the site worked. OK, so it happened to be down when I tried it earlier..

Well no. Back at my Mac, Firefox still said it was down. Time to drop to the command line:

$ dig my.calendars.net
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.2.1#53(192.168.2.1) for my.calendars.net failed: connection refused.


Hmmm.. that's the Verizon router, but my wife's machine uses the same thing, so it's not at fault. Or is it? Let's try something different. dig will let you specify a server to use. I gave it something I know is in Boston:

$ dig @192.74.137.5 my.calendars.net
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.4 <<>> @192.74.137.5 my.calendars.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1020
;; flags: qr rd ra; QUERY: 1, ANSWER: 37, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;my.calendars.net. IN A

;; ANSWER SECTION:
my.calendars.net. 5239 IN A 207.202.158.15
my.calendars.net. 5239 IN A 207.202.158.16
.. (and so on)


That tells me that this machine indeed can resolve the address; it just doesn't like something about the Verizon router. Let's try something else:

$ dig +ignore my.calendars.net

; <<>> DiG 9.3.4 <<>> +ignore my.calendars.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25360
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 29, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;my.calendars.net. IN A

;; ANSWER SECTION:
my.calendars.net. 4269 IN A 207.202.158.121
my.calendars.net. 4269 IN A 207.202.158.15
.. (and so on)


That "+ignore" tells dig to (from the man page) "Ignore truncation in UDP responses instead of retrying with TCP". If you look carefully, you'll notice that when I used the server in Boston, I got 37 addresses back, but with "+ignore", I only got 29. Is that the "truncation"? Looking at the "MSG SIZE rcvd" section, the Boston server has ";; MSG SIZE rcvd: 691", while the "+ignore" dig has ";; MSG SIZE rcvd: 498", making me very certain that there's a 512 byte packet involved.

Let's try Linux. I have a Linux server on the network, and several Linux machines inside Parallels. I tried all of them: they fail exactly as the Mac does..

Back to dig on the Mac again. You can tell dig not to use tcp with "dig +tcp". I tried that with a name dig could resolve, and the router refused me. Apparently this router doesn't want to give any tcp DNS replies.. I looked into that, but couldn't find any setting I could change. It did let me download a text config file, which told me that this router is actually an Actiontec model MI424WR, but I don't entirely understand the config file.. looks like it only accepts udp:

(name(DNS ALG))
(old_id(16777235))
(advanced(1))
(description(UDP Domain Name Server))
(alg(dns))
(trigger
(0
(protocol(17))
(dst
(start(53))
(end(53))
)
)
)
)


What do we know so far? The answer from UDP (the default) is larger than will fit in the UDP packet. My Verizon router apparently doesn't want to use TCP for DNS. Windows works.. does Windows use a different size? Let's try to find out..

My wife's machine wasn't available, but I have Windows XP running under Parallels, so I alt-tabbed over to that. Just to be compulsive, I tried it in a browser first - it works.

OK, so let's see what's really going on. In a command prompt, I ran "nslookup" and asked it to resolve my.calendars.net - it could not, though it took a long time trying. I did "set debug" and was able to observe that it tried twice, and got truncated answers both times. That's interesting: apparently "nslookup" doesn't use whatever dlls the rest of Windows uses.

That's as far as I've been able to get so far. It looks like Windows might use a different udp packet size (though not for nslookup). I found "dig" for Windows, but couldn't get it to work.. so I need better Windows tools to find out more..

*Originally published at APLawrence.com

About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com



NetworkNewz
SmallBusinessNewz
ITManagementNews

Send me relevant info on
products and services.