Can not resolve .local domains internal to my office LAN

Question

On Linux Debian 9 I am able to resolve a specific local domain e.g. my.sample-domain.local using some commands like nslookup or host, but not with some other commands like ping or the Postgres client psql.

I think stuff like Network Manager has setup my DNS resolver correctly (the content of /etc/resolv.conf), so I am not sure why is this happening?

I checked with a colleague using Windows 10 and they don't have any custom entry in their host file, although in their case the Windows version of ping and their database UI for Postgres works as expected resolving the domain into an IP address.

Please see below:

$ ping my.sample-domain.local
ping: my.sample-domain.local: Name or service not known

$ host my.sample-domain.local
my.sample-domain.local has address <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>

$ ping -c 5 <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>
PING <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> (<THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>) 56(84) bytes of data.
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=1 ttl=128 time=1.16 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=2 ttl=128 time=0.644 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=3 ttl=128 time=0.758 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=4 ttl=128 time=0.684 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=5 ttl=128 time=0.794 ms

--- <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4056ms
rtt min/avg/max/mdev = 0.644/0.808/1.160/0.183 ms

$ nslookup my.sample-domain.local
Server:        <THE_IP_REPRESENTING_THE_NAMESERVER>
Address:    <THE_IP_REPRESENTING_THE_NAMESERVER>#53

Non-authoritative answer:
Name:    my.sample-domain.local
Address: <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>


$ cat /etc/resolv.conf
domain <AN_INTERNAL_DOMAIN>
search <AN_INTERNAL_DOMAIN>
nameserver <THE_IP_REPRESENTING_THE_NAMESERVER>
nameserver <ANOTHER_IP_REPRESENTING_THE_NAMESERVER>

EDIT:

Meanwhile I realized there is an Ubuntu 16 Virtual Machine in the same office LAN, so I logged into it and tried the ping command which is working there.

Also that Ubuntu VM does not have any particular custom setting in /etc/hosts (the same as my Debian 9 laptop with not customized /etc/hosts).

Both the /etc/resolv.conf look similar (some shared domains/IPs, some other IPs for the same domain).

However the file /etc/nsswitch.conf is different, so I think there is something going on with this mdsn4_minimal and the order of hosts resolution in there like mdsn4_minimal coming before dns:

hosts:      files mdns4_minimal [NOTFOUND=return] dns

and on Ubuntu:

hosts:      files dns

EDIT 2:

Both the Ubuntu 16 VM and my Debian 9 laptop are able to resolve that .local domain using the dig command.

Answer 1

host and nslookup perform DNS lookups, however most applications use glibc's Name Service Switch to decide how host names are looked up.

Your /etc/nsswitch.conf might enable mDNS, which might cause the issues when resolving .local names. You could change the order in which lookups are made or just remove mDNS service if you think you won't need it.

Your nsswitch.conf's has mdns4_minimal, which does mDNS lookup (for .local names). The [NOTFOUND=return] after it causes the lookup to stop and therefore DNS is never used and your application can't resolve the host name. You could either remove the whole mdns4_minimal [NOTFOUND=return], so mDNS lookups are not used, or just remove the NOTFOUND action so DNS lookup would be made should mDNS lookup fail.

For further details, I recommend checking out the Name Service Switch documentation .

Answer 2

The bigger problem here is: it is known DNS domain names ending in .local should not be used when setting up DNS infra-structures.

.local use is reserved for zeroconf/avahi aka bonjour usage, which are parallel services for resolving local names/services besides DNS.

Your internal DNS name service is most certainly having conflicts with zeroconf in some scenarios. Thus the solution in the question you accepted.

In the longer term, your internal network DNS name should not end in .local.

PS As an aside, besides DNS, local Microsoft DCs/ADs should not be named .local too. You will have strange problems going on if you do that.

Multicast DNS (mDNS) standard.
The Internet Engineering Task Force (IETF) standards-track RFC 6762 (February 20, 2013) reserves the use of the domain name label local as a pseudo-top-level domain for hostnames in local area networks that can be resolved via the Multicast DNS name resolution protocol.

From MS Technet (wikipedia)

If you have Macintosh client computers that are running the Macintosh OS X version 10.3 operating system or later, … it is recommended that you do not use the .local label for the full DNS name of your internal domain. If you must use the .local label, then you must also configure settings on the Macintosh computers so they can discover other computers on the network

RFC 6762

Any DNS query for a name ending with ".local." MUST be sent to the
mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
equivalent FF02::FB).

......

4. Reverse Address Mapping

   Like ".local.", the IPv4 and IPv6 reverse mapping domains are also defined to be link-local:

   Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 multicast address FF02::FB. Since names under this domain correspond to IPv4 link-local addresses, it is logical that the local link is the best place to find information pertaining to those names.

......

No special control is needed for enabling and disabling Multicast DNS for names explicitly ending with ".local." as entered by the user.
The user doesn't need a way to disable Multicast DNS for names ending with ".local.", because if the user doesn't want to use Multicast DNS, they can achieve this by simply not using those names.
If a user does enter a name ending in ".local.", then we can safely assume the user's intention was probably that it should work.

While not from an official source, I also found this, which has a paragraph that explains the issue nicely: Stop using .local as the top level domain for your LAN

The .local domain is what is called a pseudo-top-level domain. What does that mean? It means that it’s not an official top level domain usable (routable) on the internet, but it has a semi-official standing because it is used in some applications.
In the case of .local it is used by the Multicast Domain Name Service (mDNS). Hosts that implement this service use .local as their domain names and have their own way of resolving names. Normally, this wouldn’t be a problem; however, if you also implement DNS on your network with .local as the top-level domain it will cause serious name resolution issues.
I’ve seen this happen a lot on Linux systems, and I imagine Apple’s OS X will probably have these issues as well. Usually, on these types of networks you find that DNS name resolution doesn’t work at all or works only some of the time. In the end, you end up having to use ip addresses all the time because you don’t know whether a name might resolve or not (which negates the whole point of having a DNS server in the first place).

Answer 3

Maybe you have a NBNS conflicting with a DNS, so correct that, or edit your hosts file, or wrap your commands;

NAME=my.sample-domain.local
ping $(host $NAME | perl -pe 's/.* //g')

DNS should be inspected with dig;

dig @$SERVER $NAME +short

I'm guessing host searches NBNS first (or the other way around).