Name resolution via router (and Fedora et al.)
 

Hello, all,

I am having a problem with Red Hat-based machines (Fedora, CentOS) performing DNS duties when connected to my router.

I can connect virtually any other network-able device (Windows PC, Ubuntu/Debian PC, PS3, Panasonic TV, Western Digital Live, etc.) to my network and they have no difficulty resolving hostnames via my home router. However, any Red Hat based machine (Fedora, CentOS, etc) cannot perform name resolution via DHCP with the following exceptions:

1) nslookup always works
2) manually editing /etc/resolv.conf to point to my ISPs DNS works

My DHCP-enabled Debian-based systems always work out-of-the-box with the same home network.

What am I missing here?

Many thanks.

From this, I presume that the DHCP client on Redhat fails to properly configure resolv.conf. Is that correct? If so, it would indicate some problem with a dhclient-script. On my CentOS 5 host, the relevent bits are in /sbin/dhclient-script. In there, there is a function 'make_resolv_conf()', which seems to be the place that puts the respective info in place. In contrast, Debian 6 uses a script '/etc/dhcp3/dhclient-enter-hooks.d/resolvconf'. If you have both of these host types at your disposal, you should be able to suss out the differences, and modify the recalcitrant script appropriately. FWIW, I find virtual machines ideal for this kind of work.

--- rod.

Hello theNbomr,

Not exactly. resolv.conf is being correctly populated with the IP address of my router which acts as a DNS cache/relay. nslookup and dig will work without issue but other network applications fail with "cannot resolve hostname" errors on the CentOS box. My Ubuntu box (as well as every other device on my network) is also configured to use the router's DNS relay and works perfectly.

When I have found this question asked elsewhere on the Internet, the generally accepted response is to hack the network scripts to bypass the router's DNS relay and simply use the IP address of the ISP's DNS. There must be a proper way to solve this problem. This problem is not unique to my home network as I've experienced it when connecting my Fedora laptops to other networks (like those in hotels while traveling).

Thank you for your response.

Interesting, and hard to understand how some things would work and other things not. Is the router a Linux box, or a shrink-wrapped, dedicated appliance? If it is Linux, there would seem to be a fighting chance of seeing what DNS-related traffic propagates to it and through it from the various types of hosts.
So, the resolv.conf created on other kinds of hosts is the same or equivalent to that created on the Redhat hosts? But the name lookup behavior is different?

--- rod.

The latter, unfortunately.

Correct. Also, I've examined DNS traffic with Wireshark and compared that of querying the router vs. querying the ISP's DNS directly. The only difference I can detect is that, in the response packets, the "don't fragment" bit is set when querying the ISP but not the router. This was performed with the Ubuntu box, though.

This is driving me crazy. I'll perform more packet inspection tomorrow with a Fedora VM as per your suggestion in your first response. Thanks for sticking with this!

Do the hosts files on Redhat & other/working host have any obvious differences?
--- rod.

Okay, I figured it out. This is related to behavior introduced in Fedora 10 regarding how applications resolve addresses via glibc. Debian's glibc implementation differs in this respect and tools like nslookup, dig, host, etc. provide their own name resolution routines.

In a nutshell: my router (as well as that of many a hotel I've stayed at) stinks and its behavior is considered "non-compliant" when an IPv6 DNS request is made of it. (Even if IPv6 is completely disabled, Fedora will query for both IPv4 and IPv6 addresses). The behavior of my ISP's DNS, on the other hand, is compliant, hence the successes when resolv.conf is configured for it.

There are two other quick workarounds: configure dnsmasq (which provides its own name resolution routines) or use an undocumented option in resolve.conf. The latter didn't work at all for me and, well, I was eventually going to install dnsmasq on this box so I went with that option.

Mystery solved. Thanks once again for your responses!