Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a LAN with a Linux server running BIND for addressing of local computers. When a workstation is connected to the local network (where there is no Internet access), I can successfully address devices using hostnames without any problems:

$ host server1.local
$ server1.local has address

$ host
$ domain name pointer server1.local.

When that same workstation enables WiFi (or any secondary interface) and connects to the greater Internet, the machine can no longer address local devices by hostname. Presumably this is because it is using the wrong network interface's DNS server to address my devices.

My BIND configuration is as follows:

$ORIGIN local.
$TTL 604800
@ IN SOA server1 admin (
                2008080101      ;serial
                04800           ;refresh
                86400           ;retry
                2419200         ;expire
                604800          ;negative cache TTL
@       IN      NS      server1
@       IN      A
server1  IN      A
workstation1   IN      A
workstation2   IN      A

and the reverse DNS:

$TTL 604800
@ IN SOA server1.local. admin.local. (
                2008080101      ;serial
                604800          ;refresh
                86400           ;retry
                2419200         ;expire
                604800          ;negative cache TTL

                NS      server1.local.
2       IN      PTR     server1.local.

44      IN      PTR     workstation1.local.
45      IN      PTR     workstation2.local.

How can I force clients to look at the correct network interface to find hosts in the ".local" namespace? Is it possible to do this from the BIND-configuration end, since I may not have complete control over the individual clients?

share|improve this question
This sounds like it will be a matter of configuring the resolver library on the client machines. What OS are they running? /etc/resolv.conf (which quite possibly is different in the working and non-working state) from the clients is probably relevant. – Håkan Lindqvist Jun 24 '14 at 20:33
Clients are a mixture of Windows and OS X, though only the Mac seems to have this issue. Windows resolves appropriately through both interfaces. – Jason Crystal Jun 24 '14 at 20:39

Certain versions of OS X assign preferences to DNS servers. This may cause your internal DNS server to be pushed down the preference order.

Try running this command to find out which server is being used:

scutil --dns | grep nameserver\[[0-9]*\]


share|improve this answer
Good info, but /etc/resolv.conf doesn't include the DNS servers from the LAN-connection (at all) as long as I am connected to Wi-Fi. Disconnecting from Wi-Fi immediately populates /etc/resolve.conf with the LAN DNS servers appropriately. – Jason Crystal Jun 24 '14 at 21:25
Edited. Perhaps the scutil command may help. Good luck! – Belmin Fernandez Jun 24 '14 at 21:28

Check your /etc/resolv.conf (OSX) after connecting to another network and make sure that it contains search .local. You can also try to have entries inside of hosts file (if that helps.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.