« Typographical history of the T... | Home | New KDE, still broken »

Fixing "unexpected RCODE (SERVFAIL)" and "unexpected RCODE (REFUSED)"

Wed 26 Jan 2011 by mskala Tags used:

This is another one where I searched the net, the answers I found were very unhelpful, and so I'm posting what worked for me for the benefit of anyone making similar searches.

The problem: new ADSL connection from MTS Allstream, which is the deregulated ghost of the Manitoba telecom monopoly. Works pretty well, except they do that damn misguided "helpful" redirection of failed DNS requests to a search engine, thereby screwing up all non-Web activities that depend on the DNS actually working according to the protocol. They offer opt-out but that doesn't work. So I set up my own caching DNS server and everything seemed fine... except just a few Web sites wouldn't work. Always the same sites; little or no rhyme or reason to which ones they were. Penny Arcade, Weather Underground, the Canada Revenue Agency, and the CBC, were the most annoying examples. The browser would hang, trying to connect, forever.

Digging through the system logs revealed lines like these:

Jan 25 11:34:38 tetsu named[1613]: unexpected RCODE (SERVFAIL) resolving 'art.penny-arcade.com/A/IN': 72.52.2.1#53
Jan 25 11:37:55 tetsu named[1613]: unexpected RCODE (REFUSED) resolving 'cbc.radio-canada.ca/A/IN': 207.164.234.37#53

Searching on the Web produced many people complaining about error messages like these, and the following answers on how to resolve it:

  • "You must be the authoritative server for these domains, and you haven't given BIND the correct path to the zone files." No, I am not the authoritative server for these domains.
  • "You must be the authoritative server for these domains, and someone on the Net is trying to break into your nameserver." No, I really am not the authoritative server for these domains, the failing requests are coming from an authorized user on localhost (namely me), and incoming unauthorized DNS requests would be stopped at the firewall anyway.
  • "The remote authoritative servers for these domains are misconfigured and you must contact the admins and tell them to fix the problem." Yes, I REALLY HAVE THE TIME AND ABILITY TO CONVINCE EVERY ADMINISTRATOR OF A MISCONFIGURED NAMESERVER ON THE ENTIRE INTERNET TO FIX THEIR CONFIGURATIONS BECAUSE THEY WILL ALL LISTEN TO ME! Also, of course, I can contact these administrators by pure mental telepathy, since my computer cannot connect to theirs to send them email.

Clearly, none of these answers was helpful. Here's the actual answer: The MTU on my Ethernet connection was set to the default of 1500. Packets that size cannot pass through the ADSL connection; and to make matters worse, MTS apparently drops ICMP traffic (this could be my fault because it may be happening at the firewall box, which is theirs but was reconfigured by me), so that Path MTU Discovery (which would automatically adjust the setting) doesn't work. It wasn't really anything specific to DNS, but would cause subtle effects in a lot of places; DNS was just the most visible thing failing. Solved by changing my MTU to 1400; there may be some slightly larger number that will work (I'll experiment), but 1500 evidently is too big. It appeared only, but consistently, on a few domains, because those were the ones where the DNS query or its answer (which would generally be consistent per domain) happened to both exceed the ADSL connection's real MTU and not be fragmented anywhere else in the network.

8 comments

Steve C
I know you are building up to your solution, but I suggest you put the solution right up at the top of the page in bold where search engines and people skimming the page can see it better.
Steve C - 2011-01-26 21:14
owen
To be fair, if the prime minister came to me and said "we need someone to talk to all the nerds out there with mis-configured internet servers. Who will they listen to?", your name would be bound to come up...
owen - 2011-01-26 21:54
Matt
I think it's probably more important to put the error messages themselves at the top, as I have; the solution is quite specific to DSL connections, and I'm okay with forcing readers to go through the set-up. Many others who receive these error messages might actually be authoritative for the failing domains, and be helped by the answers I mention that didn't help me.
Matt - 2011-01-27 10:18
owen
Also, the narrative aids in the user's understanding of the solution with which the entry concludes. A blog shouldn't aim to be a technical reference, and yet I see the TA in you coming through well in this piece. It's a good thing.
owen - 2011-01-28 19:38
ben
That's interesting. I got some same error msg in my mesage log

unexpected RCODE (SERVFAIL) resolving 'news.bbc.co/A/IN': 67.15.253.220#53

I now login to my ADSL router and change the max MTU to 1500. Hope the problem is fixed.
ben - 2011-05-08 11:09
Dave
Thanks for posting this. Your suggestion seems to have helped a similar problem I was having.
Dave - 2012-02-18 16:28
Ceyx
This has to be the first time ever where I found the solution ( yours ) on the first try ! Thanks !
Ceyx - 2012-02-29 11:22
Tim
The correct MTU is 1492. 1500 will work on sites that allow MTU discovery, but sites that don't silently fail. ie PayPal. Since 1492 is the largest that can be sent over ADSL; the modem should remain at 1492 and your gateway machine should be set to 1492. This way your gateway will repackage packets and you can leave your internal machines at 1500. Yes, I realize this is an old posting.
Tim - 2015-08-21 12:10


(optional field)
(optional field)
Answer "bonobo" here to fight spam. ここに「bonobo」を答えてください。SPAMを退治しましょう!
I reserve the right to delete or edit comments in any way and for any reason.