APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds RSS Feeds











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
->
-> DNS puzzler


DNS puzzler




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 @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..




If this page was useful to you, please help others find it:  





31 comments




More Articles by - Find me on Google+



Click here to add your comments
- no registration needed!




Fri Sep 28 14:59:40 2007: 3166   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: 3167   TonyLawrence

gravatar
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: 3168   TonyLawrence

gravatar
I found the manual: www.fiberfaq.com/admin/attachments/actiontec_mi424wr_manual.pdf (link dead, sorry)

It looks pretty good.. I'll keep digging..



Fri Sep 28 18:02:57 2007: 3169   TonyLawrence

gravatar
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: 3173   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: 3174   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: 3175   TonyLawrence

gravatar
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???



Sun Sep 30 14:00:02 2007: 3176   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: 3177   TonyLawrence

gravatar
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: 3201   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: 3202   TonyLawrence

gravatar
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:29 2008: 3515   Dustin


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: 3516   TonyLawrence

gravatar
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: 3526   Dustin


Try:

nslookup my.calendar.net 208.67.222.222

See if it's still truncating...



Fri Jan 9 12:12:52 2009: 5116   anonymous


1 year later, and unfortunately no one seems to have a solution for this problem. Is there a way to configure libresolv with the equivalent of dig's +ignore option? It seems like this is what we need. I don't understand why we need to retry the query with TCP at all.



Fri Jan 9 19:14:15 2009: 5124   TonyLawrence

gravatar
I don't think the problem really is libresolve - it's a matter of how the browser code reacts to the truncation.



Wed Apr 8 10:52:02 2009: 6049   cbx33

gravatar
Can you confirm using wireshark that both DNS requests are going to the same DNS server. I had an issue where nslookup uses always the primary and the apparently Windows shifts every 900 seconds between the primary and the secondary. Not saying this is your issue, but a packet dump of each request could be helpful.



Wed Apr 8 11:04:58 2009: 6050   TonyLawrence

gravatar
In this case, only one dns server at the machine - that's the router. That has primary/secondary but I can't trace that easily.



Wed Apr 8 13:11:30 2009: 6054   cbx33

gravatar
Can you install wireshark on an XP machine and on a linux/mac machine and get a single DNS request?



Wed Apr 8 13:18:14 2009: 6055   TonyLawrence

gravatar
I suppose so, but as explained above, this is likely just udp packet size. It's just a curiosity thing; not important, so not worth any effort..



Wed Apr 15 14:02:25 2009: 6176   JeffPitman

gravatar
I just ran into this same problem with www.johntreed.com which is using Akamai name server since it's really a front to a Yahoo store. This is a Mac Pro going to a D-Link DIR-635 model and the exact same truncation is happening. Akamai responds with a large amount of servers for load balancing.

This is the first time I have run into this and I've been running the DIR-635 for over a year. To solve it, I turned off DNS Relay and let the router pass the ISP name servers through. These can fallback to TCP if needed.

I'll pass the info along to D-Link...



Wed Apr 15 18:54:52 2009: 6179   TonyLawrence

gravatar
Thanks



Sun Jul 5 16:24:39 2009: 6612   Bob

gravatar
FYI, this is still happening. I have a brand new Actiontec router (same model) with the most current firmware as of today's date, and I have the same problem.

;; Truncated, retrying in TCP mode.
;; Connection to 192.168.1.1#53(192.168.1.1) for www.megaupload.com failed: connection refused.







Sat Sep 11 14:42:50 2010: 8968   anonymous

gravatar


I've recently run into a similar problem (different site though); My Mac (OSX 1.6 Snow Leopard) fails to connect to the site in questions whereas my PC (I actually have two of them, running WinXP and Win7) connect without a problem.

OK, I got interested, roled up my sleeves and installed Wireshark on both platforms...

My finding are as follows;

Both OS get a truncated message back from my wireless router (Jungo OpenRG) and both of them try to open a TCP connection and fail. The only difference seems to be that the Windows platform then decide to ignore the truncated bit in the DNS response and continue with whatever information it got over UDP whereas the Mac simply give up on it...

With all that said, I should add that I was able to access this site previously from my Mac and it just stopped working. Around the same time that it stopped working, I installed the latest OSX patches. I can't say if it ever worked after installing the patches or not.

Anyone out there have any clue?

(in the meanwhile I just added a record to the /etc/hosts file, blahhh)






Sat Sep 11 14:59:45 2010: 8969   TonyLawrence

gravatar


Yes, any return of truncated data causes this. I am really surprised they have not fixed it yet.



Thu Nov 11 18:09:29 2010: 9113   Baxil
http://www.tomorrowlands.org
gravatar


Been seeing the exact same problem here among a fraction of our customers (I work at a small rural ISP). Apparently Youtube.com lookups have started returning results over the 512-byte mark in the last week or so. I was puzzled because I couldn't reproduce the problems using the same name servers. Your post helped a lot.

Since the problem is related to the *router* only accepting UDP queries, the most reliable workaround is to manually specify some name server IPs in your computer's network setup. (Your ISP should be able to tell you what these are, or you can switch to something like Google Public DNS. Instructions for the latter are at code.google.com/speed/public-dns/docs/using.html (link dead, sorry) .) That way, rather than sending DNS queries to the router which resends them to your ISP's DNS servers, you skip the middle step.



Mon Apr 11 17:21:20 2011: 9449   anonymous

gravatar


This is one of these weird bizarro universe things where MS not following standards actually makes things work. I can only comment on what's been relevant to my investigation of this exact same issue on my network with different equipment but it appears to be the same.

The problem that everyone has noticed is that the DNS response is larger than 512 bytes. Per the RFC, if the response packet is larger than 512, the server then sets up a TCP connection to deliver the full result. In our network, we have a firewall that denies that TCP traffic as to the firewall, it's an outside machine trying to connect to an internal resource (so there is no stateful connection to relate the inbound DNS connection attempt to, so it gets denied). Since most routers have stateful firewall logic built in to them, this is probably the same problem you are seeing with your routers.

Now, where it's kinda funny is how the OS deals with this. For both Mac and Linux, they're just following the RFC (which fails) so there's no real nice workaround. Windows, otoh, has built into their DNS resolving DLLs the ability to basically send the +ignore option as a last ditch resolve attempt. I don't know what prompted MS to "failback" to that option but I'm guessing one of their programmers saw something like this happening and thought it would be a good idea to add it to the library. This is not RFC compliant behavior but in this case, it works.

So I'm with the rest of you trying to figure out how to send a +ignore option to Mac OSX libresolv as a default query. One workaround that I've been working on is modifying dnsmasq's source to add that pesky +ignore flag to it and redirecting all DNS queries to that locally running forwarding service. I'm not a C programmer so if someone is, I can point you to what I believe is the correct function (forward.c: line 237) but I haven't been successful in spitting out a packet that matches the dig +ignore option yet.

Anyway, I just thought I'd add my experience to the thread as it seems it's the most relevant hit on google...



Mon Apr 11 17:27:52 2011: 9450   TonyLawrence

gravatar


Thanks - very interesting! I tend to fault Microsoft for ignoring standards, but I guess this one time they were right :)



Sun Feb 5 02:58:24 2012: 10581   anonymous

gravatar


The DNS server needs to allow DNS queries over TCP as well as UDP this issue can occur if the firewall on your DNS server/router is not configured to allow port 53 traffic over TCP as well as UDP.



Sun Feb 5 13:16:53 2012: 10582   TonyLawrence

gravatar


Yeah, we know that. Did you read this at all or just the first paragraph?



Mon Jun 17 08:47:50 2013: 12132   TonyLawrence

gravatar


Found it at Apple: https://discussions.apple.com/message/15043721#15043721

I edited /etc/named.conf and uncommented as shown here.

options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
query-source address * port 53;
};

Rebooted and it works properly.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar

Kerio Samepage


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.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

pavatar.jpg

This post tagged:

       - DNS
       - Linux
       - MacOSX
       - Networking
       - Unix
       - Verizon



















My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide



Buy Kerio from a dealer
who knows tech:
I sell and support

Kerio Connect Mail server, Control, Workspace and Operator licenses and subscription renewals



Click and enter your name and phone number to call me about Kerio® products right now (Flash required)