-   Linux - Networking (
-   -   Local network DNS resolution fails, but DNS resolution to internet is OK (

farge 05-26-2008 12:11 PM

Hey there,

I am running a rather unique Linux system, but as far as I've been able it's pretty close to Ubuntu 8.04. Well, it is now at any rate, and that's caused me a problem. Since upgrading this strange machine to 8.04, I'm no longer able to resolve the other computers on my LAN by their DNS hostnames, but only by their IP addresses (and also by their NetBIOS names, but let's leave that aside for a moment). By resolve, I mean that I can't ping the other computers using their DNS hostnames, nor can I mount Samba shares using their DNS hostnames - these are the two functions most important to me.

The general setup is this:
1 unique almost-Ubuntu-compatible Linux computer
2 computers dual-booting Ubuntu and Windows Vista (one wired to router)
2 computers running Windows
All of these computers connected to a Netgear DG834Gv3 router via wireless (except for one Ubuntu/Windows computer), which connects to the internet via ADSL2+

Only this unique system has this problem with local DNS hostname resolution. All of the other computers can resolve every other computer just fine.

I should add that resolving by hostname on the internet works fine - I have perfectly fine internet connectivity.

So here are my relevant important files:






# /etc/nsswitch.conf
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:

passwd:        compat
group:          compat
shadow:        compat

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
# hosts:                dns files
networks:      files

protocols:      db files
services:      db files
ethers:        db files
rpc:            db files

netgroup:      nis

(NB: If I add "wins" to the "hosts:" section, I get hostname resolution through NetBIOS, but that's a bit of a band-aid solution.)



order hosts,bind,nis
multi off

And here are some common outputs:


dsl@phoenix:/etc$ ping glamdring
ping: unknown host glamdring


dsl@phoenix:/etc$ nslookup glamdring

** server can't find glamdring: NXDOMAIN

dsl@phoenix:/etc$ nbtscan
Doing NBT name scan for addresses from

IP address NetBIOS Name Server User MAC address
------------------------------------------------------------------------ PHOENIX <server> PHOENIX 00:00:00:00:00:00 GLAMDRING <server> <unknown> 00:18:4d:ef:0b:bb


dsl@phoenix:/etc$ dig glamdring

; <<>> DiG 9.4.2 <<>> glamdring
;; global options: printcmd
;; Got answer:

;glamdring. IN A

. 1420 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2008052600 1800 900 604800 86400

;; Query time: 43 msec
;; WHEN: Tue May 27 03:03:47 2008
;; MSG SIZE rcvd: 102

Hopefully that's enough for you to diagnose at least some of what's going on here. This seems to be a bit of a common problem, and it seems that something this fundamental to home networking should be fairly ironed out by now. It'd be good to try to fix it. If you need me to show you anything else, just ask me.

As I already mentioned, I can enable hostname resolution using NetBIOS, but this seems to me to be a band-aid solution (for those of you in other cultures, a band-aid is a sticking plaster, and what I mean is that it's like putting a sticking plaster on a broken leg - might stop some bleeding but it doesn't solve the fundamental problem).

Thanks for persisting in reading this!

dkm999 05-26-2008 02:51 PM

From your description, it seems that your resolver needs to be told how to treat unqualified DNS names. The search configuration option will do this. I have not used NSS for this, but with a local named, you would also need to define a local zone, so that the search option had something to search.

It appears from other details in your posting that you are running a Private Network address range on your LAN; this is a fine setup for a local DNS server that is authoritative for whatever local domain you chose for the 192.168.1.x range, and which then would automatically refer requests for other FQDN requests to the root-servers, and cache the answers. It sounds like you may not need more details than this; if you do, please post again with further questions.

farge 05-27-2008 01:06 AM

I'm not sure I would know how to set up the search option as you say... I haven't seen such an option in any configuration files...

lsteacke 05-27-2008 08:16 AM

Have you thought about simply adding entries to etc/hosts file for each of the computers? If it really is only 5 computers total, that might not be a bad idea, but once again this probably is just a work-around. Also are the servers you have in etc/resolv.conf the DNS servers provided by your ISP? Have you thought about using BIND locally and having a local DNS server?

dkm999 05-27-2008 11:20 PM

The way to specify a search is to add a line to /etc/resolv.conf

search mynet.local

This will not work out of the box, since your existing configuration uses public IP nameservers for all DNS resolution, and those servers will know nothing about mynet.local. To take care of this, you need to set up a cacheing nameserver, and then make it authoritative for the one domain mynet.local. There are quite a few tutorials on the web that show you how to set up a cacheing nameserver; if you want to keep using the public nameservers that you currently have configured, you will need to specify forwarders in the named configuration. But there is really no need; once you have your own named running, it can just talk directly to the root servers (which are specified in the hints file (probably called in some directory; I am not sure where Ubuntu puts this stuff. Look in /etc/named.conf for the path.

Then you just need a pair of zone files for mynet.local, listing the name-to-address and address-to-name mappings for your machines on that net. I know it sounds like a lot of stuff, but the payback is that you will get faster response to all DNS resolutions that you would by using the ISP's servers. The expense is that you will have to maintain the zone files.

farge 05-28-2008 08:32 AM

So why exactly should it be necessary to set up a caching nameserver? I've read this many times on the internet, but it seems an incredibly complicated step to enable something that all my other computers - and formerly this one, I might add - can do out of the box... It worked before, without a caching nameserver. This leads me to believe that somewhere, somehow, something broke. I'd really prefer to fix it rather than applying something extra.

Furthermore, my modem/router acts as a DNS server for my local network, which seems to be just fine for all my other computers. Why should this one be any different?

I'd rather not set up my hosts file statically - i really don't think i should have to! With the equipment I have, I shouldn't need to go to that length.

dkm999 05-28-2008 11:49 PM

Well, maybe it is not necessary. The fact that your modem/router is providing DNS service is new data. It almost certainly is behaving like the cacheing DNS server I described in a previous post. Whether your unique machine is paying any attention to it is still in doubt.

Since all your other machines seem able to resolve an unqualified hostname on your local network, something must know about them. I might try the following (I'm not sure what order):
1. Look at one of your other Linux systems to see what its /etc/resolv.conf file says about the nameserver being used, and if there is a search foo.local line in one of them. It seems that if your wireless router is providing DNS, the nameserver address ought to be; in the configuration you reported, you had two public IP addresses for nameservers. Those servers almost certainly will not give you any satisfaction when resolving private-network names.
2. On one of your working machines, use nslookup to reverse-map an IP address on the 192.168.0.x network to the corresponding Fully-Qualified-Domain-Name. This ought to give you the domain being used when you say ping glamdring. That is the suffix that search wants in /etc/resolv.conf.

3. See if this bug report has anything to do with your system. I noticed in re-reading your original post that the Multicast DNS discovery is first in your list of ways to resolve stuff, and since I had not seen that term before, I Googled to find out what it was.

