Novell SUSE Linux Enterprise Desktop 10
Novell SUSE Linux Enterprise Server 10
Novell SUSE Linux Enterprise Server 9
Novell Linux Desktop 9
Applications or system programs like ping have problems with the resolution of names in a DNS domain ending with .local.
For example, when you try to test the connection to a machine called runner in your organisation's acme.local domain with the command ping runner or ping runner.acme.local, you get an error:
ERROR: unknown host runner.acme.local
even though you can look up that host name with dig runner.acme.local, or it takes longer than expected for the pinging to start.
On SLES 11 or later:
modify the following line:
hosts: files mdns4_minimal [NOTFOUND=return] dns
and remove "mdns4_minimal [NOTFOUND=return]" so it reads:
hosts: files dns
On Pre SLES 11 machines:
in the resolver configuration file
This solution addresses this specific problem. To prevent similar problems in the future, we recommend using official DNS names for your network, as top-level domains that are currently unassigned may be assigned for special purposes in the future, as has happened with .local.
With regular unicast DNS, systems that are connected to the network need to be told the IP address(es) of the nameserver(s) they can use (on Linux systems, this information is stored in the /etc/resolv.conf file). When multicast DNS is used, this is not necessary: DNS queries are made through multicast packets and answered by a multicast-aware DNS server, without the DNS client needing to know the server's address beforehand. Thus, using name servers that support multicast DNS makes it easier to hook up new systems to the network; this is a part of what is known as Zeroconf, Zero Configuration Networking.
However, many existing networks do
not have multicast-aware DNS servers. In such networks, a DNS query
for a name in .local
will fall on deaf ears and such a name will not get resolved, or
will only be resolved when name resolution falls back to unicast