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.
Update: I found a fix. See the comments.
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 @188.8.131.52 my.calendars.net
;; Truncated, retrying in TCP mode.
;; ANSWER SECTION:
my.calendars.net. 4269 IN A 184.108.40.206
my.calendars.net. 4269 IN A 220.127.116.11
.. (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:
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..
If a DNS lookup result is longer than 512 bytes, my Mac OS X and Linux machines can't get the resolved IP because they automatically retry DNS with TCP and (apparently) this router doesn't want to do that.
Windows NSLOOKUP can't resolve these either but Windows in general can - I assume it must be using a larger UDP packet size.
It's a very minor thing (very few sites return that much info), but now and then it is annoying.. I certainly don't see anything in the browser based router config, but I did look at the raw config file and I suspect I could do it there.. but would rather not experiment if someone has already been down that road..
I also found there that I can make this router bridge, so I *could*
put back my old router, but that's yet another vampire tap: I'd rather
fix this in software if I can..