Wrong DNS causes interesting glitch

I had an interesting call a few days back. Old customer, old SCO box overdue for the graveyard but still in use. Customer needed to renumber his ip scheme and ran into a confusing situation after changing from 192.168.2.x to 10.126.10.x.

Here are the observed conditions:

"ifconfig" shows correct address, broadcast, mask.

"netstat -rn" shows correct routes.

"netstat -in" does show a high number of collisions.

Nothing funky in /etc/hosts.

Ping a local machine or the router, ping hangs.

Delete the default route and ping works.

On the face of it, this is wrong. Local LAN packets have nothing to do with the default route; it shouldn't matter whether it has a route or not - local packets don't need to go through the router..

I should have realized what this was instantly, because there is something that local packets could need the router for.. I'll give you a second to think about it..

Ok.. that's long enough. The reason I didn't hit on this instantly is because I had talked to the admin there and reminded him that he needed to change /etc/resolv.conf as part of this work. Unfortunately, he forgot it - well, he remembered that he *needed* to do it, but never actually did it. So resolv.conf still pointed at a 192.168.2 address for a nameserver.

Why does that matter? Because of reverse lookups. Every packet coming in needs to be resolved to a name if possible. The resolver looks at /etc/resolv.conf to find out how to do that, and of course it found that 192.168.2.x address. Without a default route, there would be nothing it could do with that: it can't ask the name server to resolve any ip's because it has no way to get there. Therefor it instantly gives up, and the ping works.

But with a handy default route, it's going to try to reach the name server. That might have been OK if the router knew nothing about any 192.168.2.x addresses and had said so instantly, but apparently it tried to route that.. I'm not sure where, though they do have hardware VPN's also, so that may be where it sent the packets. Whatever actually happened, the resolver requests would never be answered, so everything had to wait for a timeout.. I don't know how long that is configured for on that router, but whatever it is, it was plenty long enough to hang ping.

Putting the correct DNS server into resolv.conf solved this instantly (there's no need to reboot - the resolver notices changes to resolv.conf immediately).

I don't know where the collisions came from.. but I wasn't asked to do anything more, so I left that to the normal admin. The system worked at this point and the collisions were not increasing.

Comments?

More Articles by Anthony Lawrence - Find me on Google+

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.

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.