Weird Name Resolution Problem

I had this issue with Fedora Core 13, so I switched my laptop back to OpenSuse, and continued to have the problem. Here it is in a nutshell. I can do a host lookup for and I get a correct response …

linux-edxs:/etc # host has address

linux-edxs:/etc # host has address

Firefox works. Thunderbird finds my mail servers just fine. SSH works. But then when I try to do anything involving software updates or installation, I get …

linux-edxs:/etc # zypper update
Retrieving repository 'Updates for openSUSE 11.3 11.3-1.82' metadata \]
Download (curl) error for '':
Error code: Connection failed
Error message: Couldn't resolve host ''

I’ve seen others here post queries about this, and I’ll tell you what it was in my case: our DSL modem’s DHCP server returns its own IPV4 address as the DNS server. When I looked at /etc/resolve.conf, I saw “nameserver:” on the last line – the IPV4 address of our DSL modem. I manually inserted “nameserver” lines for our ISP’s two actual DNS servers, and everything magically started working.

Why this should confuse some software under Linux, but not other software, is a mystery. It also seems to be Gnome-specific (I didn’t have this problem with OpenSuse 11.3 and KDE 4). But consider this a heads-up, if anyone else here posts with a similar problem. Ask if they’re using Gnome, and ask them to check resolve.conf. A lot of DSL modems and home/small office routers return their own IP address (i.e., the same as the gateway address) for the DNS server on a DHCP query. The solution is to manually edit resolve.conf and put in your ISP’s DNS server addresses manually.

Incidentally, just my opinion, but Network Manager needs to make this an option. Under Windows, for example, you can select “automatically assign DNS” or you can enter them manually, even if you’re using DHCP. It’d be nice if Network Manager permitted that.

That’s a new one for me, if actual DNS servers aren’t listed I usually see DHCP configuring clients with the client’s own address (I suspect to mask the location of the DNS server for whatever reason). The SOHO router’s own IP address can be valid if a DNS forwarding service is running. From what you’re describing I’d suspect a hardware issue that’s not critical since you found your alternate config.

Next time you might want to take a look at the nslookup utility, that’s what you should be using for name resolution queries.


Some Linux distros use a /etc/resolv.conf.tail for that purpose. Under openSUSE, you can define static DNS in the option NETCONFIG_DNS_STATIC_SERVERS in the file /etc/sysconfig/network/config.

The reason SOHO routers return their own address in the DNS resolver field of the DHCP lease is because they run a DNS proxy. Unfortunately there are some routers with broken DNS proxies that don’t respond well to IPv6 queries, returning junk when they should either return the correct answer or none. The fix is not to use the broken proxy in the router. The router may allow you to specify a different resolver in its setup, and that’s where you put in your own resolver, your ISP’s or some public one like Google’s. If not, do as you did.

I understand that, and I inserted the ISP’s DNS servers on a hunch. But it still makes no sense. I have IPV6 disabled. The DSL modem is an older Netopia that has never even heard of IPV6 (I checked). I wonder if parts of the operating system ignore the IPV6 kill?

Now that I think about it, I can’t say that it’s Gnome-specific, either. I don’t believe yum (Fedora) or zypper (Suse) care which desktop environment I’m running, do they? But look at my first example above: the “host” query at the command prompt works fine, but as soon as I do the “zypper update,” I get the “unable to resolve” error. The same thing was happening with “yum install” and “yum update” under Fedora 13.

I wish I had time to dig into the source code to see what they’re doing. This is just weird … but I’m glad I fixed it.

Even without IPv6 networking, there are AAAA records in IPv4 DNS.

zypper uses libcurl and maybe yum uses that too. So you may want to try with command line curl to see what is wrong. For a start try:

curl -I