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

DNS puzzler

© May 2019 Anthony Lawrence


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 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 @ my.calendars.net
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.4 <<>> @ 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

;my.calendars.net. IN A

my.calendars.net. 5239 IN A
my.calendars.net. 5239 IN A
.. (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

;my.calendars.net. IN A

my.calendars.net. 4269 IN A
my.calendars.net. 4269 IN A
.. (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))
(description(UDP Domain Name Server))

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 https://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..

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> DNS puzzler


Inexpensive and informative Apple related e-books:

Are Your Bits Flipped?

Take Control of Numbers

Take Control of Preview

Take Control of Parallels Desktop 12

Digital Sharing Crash Course

More Articles by © Anthony Lawrence

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.


Fri Sep 28 15:13:52 2007: 3167   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: 3168   TonyLawrence

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

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

Starting Nmap 4.20 ( (link) ) at 2007-09-30 04:41 CDT
Warning: OS detection for will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on
Not shown: 1485 closed ports
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 (link) .
Nmap finished: 1 IP address (1 host up) scanned in 2.517 seconds

04:41:40 drag@sylvester:/home/drag/
$ sudo nmap -O

Starting Nmap 4.20 ( (link) ) at 2007-09-30 04:46 CDT
Interesting ports on
Not shown: 1696 closed ports
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 (link) .
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

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:

Sun Sep 30 22:30:13 2007: 3177   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: 3201   dropsoulcom

The link is wrong according to the the calendars.net instructions, it should be:

From: (link)

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

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

Non-authoritative answer:
Name: my.calendar.net

My guess is that it's been fixed, or it's just the fact that I use OpenDNS ( (link)

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

Nope, still truncated:

MacBook:~ apl$ nslookup my.calendar.net Server: Address:

** server can't find my.calendar.net.home: NXDOMAIN

MacBook:~ apl$ dig my.calendars.net ;; Truncated, retrying in TCP mode. ;; Connection to for my.calendars.net failed: connection refused.

Thu Jan 24 23:14:56 2008: 3526   Dustin


nslookup my.calendar.net

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

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

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

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

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

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

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


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

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 for www.megaupload.com failed: connection refused.

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


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


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


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


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


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


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


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

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


Found it at Apple: (link)

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.


Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

There is no reason anyone would want a computer in their home. (Ken Olson, president, chairman and founder of DEC)

Linux posts

Troubleshooting posts

This post tagged:







Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode