Subscribe by RSSDNS puzzler
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..
I did find a fair amount of posts about this router at http://www.dslreports.com/forum/vzfiber so posted this there:
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..
Technorati tags: Mac+OS+X Linux Unix TCP/IP+Networking Verizon
Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)
| Views for this page | ||||
|---|---|---|---|---|
| Today | This Week | This Month | This Year | Overall |
| 4 | 43 | 126 | 1,310 | 3,441 |
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
http://www.cleverminds.net Need expert advice? Want a second opinion? CleverMinds is a one-stop-shop for a wide range of technology solutions. We support Unix, Linux, SCO as well as CMS, ecom, blogs, podcasts, search engines consulting and more. Contact us at web2.0@cleverminds.net 0r (617) 894-1282
http://www.schewanick.com SCO Unix, Solaris, Linx (various), PHP, MySQL, Apache, uniBasic, dL4, Perl, System Administration and more....
- May 15 14:34
Busy week, tired, which means I won't do well at poker tonite. Kind of a Catch-22: have a slow week, win at poker. Big, busy week, nope. - May 13 17:19
Too nice out - bailing..
Related Posts
Fri Sep 28 14:59:40 2007: Subject: rbailin
What model is your Verizon router? If it's the crappy wireless one (Westell?) that they were giving out last year to new DSL customers (supports only WEP, no firmware updates) I wouldn't be surprised if this was yet another flaw. The 2Wire routers being distributed by AT&T had similar problems, but were fixed with a firmware update. Have you tried swapping the Verizon router for a known good one?
Running nslookup my.calendars.net from XP Pro worked just fine. Running it from Openserver 5.0.7 also worked, but it complained about "MAXADDRS exceeded: skipping address" (2x). Using a Linksys WRT54G.
--Bob
Fri Sep 28 15:13:52 2007: Subject: TonyLawrence
It's an Actiontec model MI424WR - I don't think it's broken, looks to me like it is deliberately configed that way - this isn't DSL, it's FIOS, and I can't swap it without breaking my TV :-)
Apparently it is a Verizon specific model - I'm going to look on their site for updates..
Fri Sep 28 15:35:53 2007: Subject: TonyLawrence
I found the manual: http://www.fiberfaq.com/admin/attachments/actiontec_mi424wr_manual.pdf
It looks pretty good.. I'll keep digging..
Fri Sep 28 18:02:57 2007: Subject: TonyLawrence
I posted to comp.sys.mac.misc and comp.os.linux.misc - I was very surprised that a responder said:
"I tried the site on my Actiontec MI424-WR.
Same problem. I called the problem into Verzion. They called
Actiontec helpdesk, and now have an open ticket. "
I'm really surprised that Verizon accepted it as a problem. I didn't bother to
call them because I figured that once they heard "it works on Windows"
they'd do nothing more..
Sun Sep 30 10:13:10 2007: Subject: drag
Wow that is interesting. I notice DNS issues time to time while on my laptop at work. I dismissed it to the dirt cheap router and the fact that it's a NAT router behind a real router and firewall. So it didn't bother me any.
But I tried the my.calendars.net name also and it didn't work. When using dig it complained that the results were truncated and tcp connection was refused. At home it works fine.
Now both work and me use the same ISP. A difference is that they have a 'business' connection using fiber, while I have cable connection. Also I use Debian + Shorewall as my home router rather then some cheap commercial router. When I use my workstation at work, rather then my laptop then that also works.. which is due to them being on different portions of the network.
Now interestingly my Linux router at home does not truncate the UDP packet.. at least as far as I can tell. Dig does not complain about a truncated packet and uses tcp, but both work connections do use tcp connection. The dns stuff for my home router is done using dnsmasq, which relays and caches any dns requests to whatever dns configuration it receives from dhcp.
Now I can't go around using nmap on my internal network at work, but the portion of the network I connect to using my own personal laptop is a different story since it's protected and is expected that people are going to do naughty things. (it's specficly setup as a open wifi for visitors with Windows laptops so that they don't try to connect to our internal network using their nasty virus and spyware infected machines in order to get on the internet)
Here are the results for it:
04:41:08 drag@sylvester:/home/drag/
$ sudo nmap -O -sU 192.168.0.1
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-30 04:41 CDT
Warning: OS detection for 192.168.0.1 will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on 192.168.0.1:
Not shown: 1485 closed ports
PORT STATE SERVICE
53/udp open|filtered domain
69/udp open|filtered tftp
1900/udp open|filtered UPnP
MAC Address: 00:13:46:D4:84:CE (D-Link)
Device type: broadband router|WAP
Running: D-Link embedded
OS details: D-Link DI-524, DI-604, or DI-624 WAP, D-Link DWL-900AP+ WAP
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 2.517 seconds
04:41:40 drag@sylvester:/home/drag/
$ sudo nmap -O 192.168.0.1
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-30 04:46 CDT
Interesting ports on 192.168.0.1:
Not shown: 1696 closed ports
PORT STATE SERVICE
80/tcp open http
MAC Address: 00:13:46:D4:84:CE (D-Link)
Device type: broadband router
Running: D-Link embedded
OS details: D-Link DI-524, DI-604, or DI-624 WAP
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 2.748 seconds
So, at least in my case, it's obvious what the problem is. There is no domain service running on TCP. Can't connect to something that doesn't exist.
Now, unfortunately, I have no Windows machine handy to test the router.
But it does have UPnp support. UPnP is Microsoft's equivelent of Linux/Apple's zeroconfig stuff. But instead of just service announcement protocol it also is used for automatic network configuration stuff. Microsoft uses it in their media extenders for the Media Center, for example.
I noticed it once while playing games over at my parents house. They have 2 Windows machines and I had given my brother my old Linux box. So since we don't get together much anymore I had setup a game server on the more powerfull Windows box and we were playing deathmatches against each other on all three machines. (playing Nexuiz, btw).
Strangely enough we started having people on the internet joining us on my server! This was suprising since I was behind a NAT firewall with no forward ports, so I thought.
But what was happening was that the game server was requesting to the router, using UPnP, to forward the ports nessicary to allow it to connect to the central game anouncement server which all the clients connected to in order to discover multiplayer gaming servers to connect to on the internet.
So my wild guess is that Windows, when it retrieves a bad udp packet, is using UPnP to request a tcp dns connection to the router, which is granted, and thus Windows can find the server. Since Linux and Apple machines do not support UPnP (generally, Linux can for some things, but it rare) then they can't request a tcp connection.
Sun Sep 30 10:20:34 2007: Subject: drag
"""
But what was happening was that the game server was requesting to the router, using UPnP, to forward the ports nessicary to allow it to connect to the central game anouncement server which all the clients connected to in order to discover multiplayer gaming servers to connect to on the internet."""
Err.. stated that wrongly. I meant that it forwarded ports nessicary to allow people on the internet to connect to it, while broadcasting to the central game service that announced my server's aviability to the world.
It was a bit unsettling to say the least. There goes all those theories that NAT routers at home protecting those infected Windows boxes from becoming warez and spam machines.
So I'd crack open the old WireShark (aka ethereal) and see if that windows boxen is doing any upnp stuff.
Sun Sep 30 11:29:57 2007: Subject: TonyLawrence
I find it a bit scary and disturbing to think that a router would set up inward forwarding because of a UPnP request! That's bad.. does that really happen???
Computer books from Amazon
Sun Sep 30 14:00:02 2007: Subject: drag
You'd think I'd mislead you?
Well.. I don't know for a 100% fact that is what was happenning with Nexuiz, but I do know for a fact there was no ports open on that router since I set it up for my parents not long before that.
And I do know for a 100% fact that applications can use Upnp to open ports on routers that have Upnp aviable and enabled (usually the default configuration). Applications with UPnP can open up ports without any user intervention or notiification.
So I assumed that is what happenned. I just never bothered to do a packet capture on the network to prove it to myself or anything. Searching through Nexuiz I found a couple people referencing how wonderfull UPnP was (in the context that people were having router/firewall issues)
Now I don't know if UPnP can request a tcp connection for DNS, but I think it's a possibility. UPnP has been around since 1999, but the specifications for individual device types are not that old. I don't know were to look for the specifications for UPnP support for routers and I am kinda busy right now. :)
Iron Geek has a tutorial on the subject:
http://www.irongeek.com/i.php?page=videos/universal-plug-and-play-upnp-1
Sun Sep 30 22:30:13 2007: Subject: TonyLawrence
Well, that article seems pretty plain: no authentication, no "by your leave" .. it just opens the ports.
Good thing to disable immediately, I guess..
I just checked my router - it's not enabled by default.. so this isn't UPnP sneaking answers to Windows - I think we're back to Windows using a larger UDP packet.
Fri Oct 26 13:29:54 2007: Subject: http://www.dropsoul.com dropsoulcom
The link is wrong according to the the calendars.net instructions, it should be:
From: http://www.calendars.net/otherurls.htm
If you are using a Mac computer or the browser Opera, use "www.my.calendars.net" instead of "my.calendars.net" to begin the web address.
Fri Oct 26 13:34:25 2007: Subject: TonyLawrence
I think you missed the point.
It's not about how you can get there - the interesting point is the difference in
how Windows and Unix handle the overflow.
Thu Jan 24 07:27:30 2008: Subject: Dustin
http://www.dustin-williams.com
From my OS X machine (OS X v10.5.1), nslookup takes a few seconds, and returns with:
$ nslookup my.calendar.net
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
Name: my.calendar.net
Address: 67.215.66.132
$
My guess is that it's been fixed, or it's just the fact that I use OpenDNS ( http://www.opendns.com/).
I use the Verizon MI424WR router, giving DMZ to a Linksys WRT54G (running the DD-WRT firmware (v23 SP2)) connected to it.
Thu Jan 24 11:30:40 2008: Subject: TonyLawrence
Nope, still truncated:
MacBook:~ apl$ nslookup my.calendar.net Server: 192.168.1.1 Address: 192.168.1.1#53
** server can't find my.calendar.net.home: NXDOMAIN
MacBook:~ apl$ dig my.calendars.net ;; Truncated, retrying in TCP mode. ;; Connection to 192.168.1.1#53(192.168.1.1) for my.calendars.net failed: connection refused.
Thu Jan 24 23:14:56 2008: Subject: Dustin
http://www.dustin-williams.com
Try:
nslookup my.calendar.net 208.67.222.222
See if it's still truncating...
Add your comments