Can not resolve .local domains internal to my office LAN
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
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.
debian dns mdns
 |Â
show 3 more comments
up vote
3
down vote
favorite
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.
debian dns mdns
1
could be getaddrinfo (/etc/gai.conf
) or nameserviceswitch (/etc/nsswitch.conf
), but I only know of these, not about.
â Jasen
Jul 19 at 10:08
plz show your (sanitised) dig command and output (be sure @server was used)
â user1133275
Jul 19 at 10:39
Thisdig @SERVER my.sample-domain.local +short
gives the outputdig: couldn't get address for 'SERVER': failure
on both the machines. I've tried also@$SERVER
(although I think that $ was a typo) and I get:dig: couldn't get address for '': not found
â TPPZ
Jul 19 at 10:50
1
You should not use .local on your DNS domains, unless you are talking about ZeroConf. What is your situation?
â Rui F Ribeiro
Jul 19 at 10:53
I don't manage the LAN network. The IT people does not know anything about Linux, their background is Windows stuff. I have no idea what that "local domain" thing is. I am just trying to connect to a Postgres DB that I don't manage but I am supposed to use to develop a backend application.
â TPPZ
Jul 19 at 10:55
 |Â
show 3 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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.
debian dns mdns
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.
debian dns mdns
edited Jul 19 at 12:01
sebasth
5,77221539
5,77221539
asked Jul 19 at 9:26
TPPZ
1184
1184
1
could be getaddrinfo (/etc/gai.conf
) or nameserviceswitch (/etc/nsswitch.conf
), but I only know of these, not about.
â Jasen
Jul 19 at 10:08
plz show your (sanitised) dig command and output (be sure @server was used)
â user1133275
Jul 19 at 10:39
Thisdig @SERVER my.sample-domain.local +short
gives the outputdig: couldn't get address for 'SERVER': failure
on both the machines. I've tried also@$SERVER
(although I think that $ was a typo) and I get:dig: couldn't get address for '': not found
â TPPZ
Jul 19 at 10:50
1
You should not use .local on your DNS domains, unless you are talking about ZeroConf. What is your situation?
â Rui F Ribeiro
Jul 19 at 10:53
I don't manage the LAN network. The IT people does not know anything about Linux, their background is Windows stuff. I have no idea what that "local domain" thing is. I am just trying to connect to a Postgres DB that I don't manage but I am supposed to use to develop a backend application.
â TPPZ
Jul 19 at 10:55
 |Â
show 3 more comments
1
could be getaddrinfo (/etc/gai.conf
) or nameserviceswitch (/etc/nsswitch.conf
), but I only know of these, not about.
â Jasen
Jul 19 at 10:08
plz show your (sanitised) dig command and output (be sure @server was used)
â user1133275
Jul 19 at 10:39
Thisdig @SERVER my.sample-domain.local +short
gives the outputdig: couldn't get address for 'SERVER': failure
on both the machines. I've tried also@$SERVER
(although I think that $ was a typo) and I get:dig: couldn't get address for '': not found
â TPPZ
Jul 19 at 10:50
1
You should not use .local on your DNS domains, unless you are talking about ZeroConf. What is your situation?
â Rui F Ribeiro
Jul 19 at 10:53
I don't manage the LAN network. The IT people does not know anything about Linux, their background is Windows stuff. I have no idea what that "local domain" thing is. I am just trying to connect to a Postgres DB that I don't manage but I am supposed to use to develop a backend application.
â TPPZ
Jul 19 at 10:55
1
1
could be getaddrinfo (
/etc/gai.conf
) or nameserviceswitch (/etc/nsswitch.conf
), but I only know of these, not about.â Jasen
Jul 19 at 10:08
could be getaddrinfo (
/etc/gai.conf
) or nameserviceswitch (/etc/nsswitch.conf
), but I only know of these, not about.â Jasen
Jul 19 at 10:08
plz show your (sanitised) dig command and output (be sure @server was used)
â user1133275
Jul 19 at 10:39
plz show your (sanitised) dig command and output (be sure @server was used)
â user1133275
Jul 19 at 10:39
This
dig @SERVER my.sample-domain.local +short
gives the output dig: couldn't get address for 'SERVER': failure
on both the machines. I've tried also @$SERVER
(although I think that $ was a typo) and I get: dig: couldn't get address for '': not found
â TPPZ
Jul 19 at 10:50
This
dig @SERVER my.sample-domain.local +short
gives the output dig: couldn't get address for 'SERVER': failure
on both the machines. I've tried also @$SERVER
(although I think that $ was a typo) and I get: dig: couldn't get address for '': not found
â TPPZ
Jul 19 at 10:50
1
1
You should not use .local on your DNS domains, unless you are talking about ZeroConf. What is your situation?
â Rui F Ribeiro
Jul 19 at 10:53
You should not use .local on your DNS domains, unless you are talking about ZeroConf. What is your situation?
â Rui F Ribeiro
Jul 19 at 10:53
I don't manage the LAN network. The IT people does not know anything about Linux, their background is Windows stuff. I have no idea what that "local domain" thing is. I am just trying to connect to a Postgres DB that I don't manage but I am supposed to use to develop a backend application.
â TPPZ
Jul 19 at 10:55
I don't manage the LAN network. The IT people does not know anything about Linux, their background is Windows stuff. I have no idea what that "local domain" thing is. I am just trying to connect to a Postgres DB that I don't manage but I am supposed to use to develop a backend application.
â TPPZ
Jul 19 at 10:55
 |Â
show 3 more comments
3 Answers
3
active
oldest
votes
up vote
6
down vote
accepted
host
and nslookup
perform DNS lookups, however most applications use glibc's Name Service Swtich 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 .
I managed to solve the problem changing my local/etc/nsswitch.conf
movingdns
before[NOTFOUND=return]
so the DNS is used before returning. This makesping
andpsql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with thedns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of/etc/hosts
. Thanks!
â TPPZ
Jul 19 at 11:12
Do you have a real name resolver or a Zeroconf network?.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer.loc
instead.
â rexkogitans
Jul 19 at 15:16
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
1
Your IT guys are incompetent if the really set up a domain called.local
. Names ending in.local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard.local
as a non-DNS domain..local
is not isolated to some "alien" technology not related to Cisco and Windows.
â Johan Myréen
Jul 19 at 17:47
add a comment |Â
up vote
2
down vote
The bigger problem here: 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, that are parallel services for resolving local names/services besides DNS.
So what happens is 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).
......
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.
I not 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).
Is there a reference somewhere like RFC etc where it is stated that.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with.local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that.local
, so changing my Debian configuration really solved my problem.
â TPPZ
Jul 23 at 10:28
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
add a comment |Â
up vote
0
down vote
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).
1
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
Thanks,dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours:nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this/etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution likemdns4_minimal
coming beforedns
with a return[NOTFOUND=return]
in the middle
â TPPZ
Jul 19 at 10:33
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
host
and nslookup
perform DNS lookups, however most applications use glibc's Name Service Swtich 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 .
I managed to solve the problem changing my local/etc/nsswitch.conf
movingdns
before[NOTFOUND=return]
so the DNS is used before returning. This makesping
andpsql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with thedns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of/etc/hosts
. Thanks!
â TPPZ
Jul 19 at 11:12
Do you have a real name resolver or a Zeroconf network?.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer.loc
instead.
â rexkogitans
Jul 19 at 15:16
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
1
Your IT guys are incompetent if the really set up a domain called.local
. Names ending in.local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard.local
as a non-DNS domain..local
is not isolated to some "alien" technology not related to Cisco and Windows.
â Johan Myréen
Jul 19 at 17:47
add a comment |Â
up vote
6
down vote
accepted
host
and nslookup
perform DNS lookups, however most applications use glibc's Name Service Swtich 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 .
I managed to solve the problem changing my local/etc/nsswitch.conf
movingdns
before[NOTFOUND=return]
so the DNS is used before returning. This makesping
andpsql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with thedns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of/etc/hosts
. Thanks!
â TPPZ
Jul 19 at 11:12
Do you have a real name resolver or a Zeroconf network?.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer.loc
instead.
â rexkogitans
Jul 19 at 15:16
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
1
Your IT guys are incompetent if the really set up a domain called.local
. Names ending in.local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard.local
as a non-DNS domain..local
is not isolated to some "alien" technology not related to Cisco and Windows.
â Johan Myréen
Jul 19 at 17:47
add a comment |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
host
and nslookup
perform DNS lookups, however most applications use glibc's Name Service Swtich 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 .
host
and nslookup
perform DNS lookups, however most applications use glibc's Name Service Swtich 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 .
edited Jul 19 at 10:44
answered Jul 19 at 10:09
sebasth
5,77221539
5,77221539
I managed to solve the problem changing my local/etc/nsswitch.conf
movingdns
before[NOTFOUND=return]
so the DNS is used before returning. This makesping
andpsql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with thedns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of/etc/hosts
. Thanks!
â TPPZ
Jul 19 at 11:12
Do you have a real name resolver or a Zeroconf network?.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer.loc
instead.
â rexkogitans
Jul 19 at 15:16
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
1
Your IT guys are incompetent if the really set up a domain called.local
. Names ending in.local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard.local
as a non-DNS domain..local
is not isolated to some "alien" technology not related to Cisco and Windows.
â Johan Myréen
Jul 19 at 17:47
add a comment |Â
I managed to solve the problem changing my local/etc/nsswitch.conf
movingdns
before[NOTFOUND=return]
so the DNS is used before returning. This makesping
andpsql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with thedns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of/etc/hosts
. Thanks!
â TPPZ
Jul 19 at 11:12
Do you have a real name resolver or a Zeroconf network?.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer.loc
instead.
â rexkogitans
Jul 19 at 15:16
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
1
Your IT guys are incompetent if the really set up a domain called.local
. Names ending in.local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard.local
as a non-DNS domain..local
is not isolated to some "alien" technology not related to Cisco and Windows.
â Johan Myréen
Jul 19 at 17:47
I managed to solve the problem changing my local
/etc/nsswitch.conf
moving dns
before [NOTFOUND=return]
so the DNS is used before returning. This makes ping
and psql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with the dns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of /etc/hosts
. Thanks!â TPPZ
Jul 19 at 11:12
I managed to solve the problem changing my local
/etc/nsswitch.conf
moving dns
before [NOTFOUND=return]
so the DNS is used before returning. This makes ping
and psql
(the Postgres command client) working. However according to the "Multicast DNS" Wikipedia page you suggested this "mDNS LAN .local" setting combined with the dns
resolution is supposed to violate some sort of "zero-configuration goal" which I am not familiar with. But the workaround at least looks cleaner than some piping bash magic or manual change of /etc/hosts
. Thanks!â TPPZ
Jul 19 at 11:12
Do you have a real name resolver or a Zeroconf network?
.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer .loc
instead.â rexkogitans
Jul 19 at 15:16
Do you have a real name resolver or a Zeroconf network?
.local
is proposed to be Zeroconf, and all the Debian components are configured to use that by default. If this is not a Zeroconf network, you should prefer .loc
instead.â rexkogitans
Jul 19 at 15:16
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
How do I check those things with some commands? I don't manage the IT infrastructure. The IT guys are not very responsive and do not look very much informed about anything outside Windows and Cisco, so usually we don't understand each other and my lack of networking knowledge does not help in asking the right questions to them.
â TPPZ
Jul 19 at 16:13
1
1
Your IT guys are incompetent if the really set up a domain called
.local
. Names ending in .local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard .local
as a non-DNS domain. .local
is not isolated to some "alien" technology not related to Cisco and Windows.â Johan Myréen
Jul 19 at 17:47
Your IT guys are incompetent if the really set up a domain called
.local
. Names ending in .local
are reserved for mDns. LLMNR (Link-local Multicast Name Resolution), which is Microsoft's competing version of multicast DNS, has also adopted this convention: Windows clients will regard .local
as a non-DNS domain. .local
is not isolated to some "alien" technology not related to Cisco and Windows.â Johan Myréen
Jul 19 at 17:47
add a comment |Â
up vote
2
down vote
The bigger problem here: 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, that are parallel services for resolving local names/services besides DNS.
So what happens is 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).
......
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.
I not 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).
Is there a reference somewhere like RFC etc where it is stated that.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with.local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that.local
, so changing my Debian configuration really solved my problem.
â TPPZ
Jul 23 at 10:28
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
add a comment |Â
up vote
2
down vote
The bigger problem here: 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, that are parallel services for resolving local names/services besides DNS.
So what happens is 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).
......
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.
I not 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).
Is there a reference somewhere like RFC etc where it is stated that.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with.local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that.local
, so changing my Debian configuration really solved my problem.
â TPPZ
Jul 23 at 10:28
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
add a comment |Â
up vote
2
down vote
up vote
2
down vote
The bigger problem here: 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, that are parallel services for resolving local names/services besides DNS.
So what happens is 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).
......
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.
I not 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).
The bigger problem here: 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, that are parallel services for resolving local names/services besides DNS.
So what happens is 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).
......
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.
I not 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).
edited Jul 23 at 11:23
answered Jul 20 at 19:17
Rui F Ribeiro
33.7k1168113
33.7k1168113
Is there a reference somewhere like RFC etc where it is stated that.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with.local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that.local
, so changing my Debian configuration really solved my problem.
â TPPZ
Jul 23 at 10:28
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
add a comment |Â
Is there a reference somewhere like RFC etc where it is stated that.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with.local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that.local
, so changing my Debian configuration really solved my problem.
â TPPZ
Jul 23 at 10:28
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
Is there a reference somewhere like RFC etc where it is stated that
.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with .local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that .local
, so changing my Debian configuration really solved my problem.â TPPZ
Jul 23 at 10:28
Is there a reference somewhere like RFC etc where it is stated that
.local
domains are not for DNS? According to the Wikipedia page I can see mDNS deals only with .local
domains, but I can not find the other way around is not allowed. In my specific case I figured out that domain has been setup more than 10 years ago by Windows people no longer in the company. The current company managing the infrastructure are mostly useless. Many data scientist work completely unaware of this DNS issue and their code depend on that .local
, so changing my Debian configuration really solved my problem.â TPPZ
Jul 23 at 10:28
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
@TPPZ added some references. It is far from being either a recent or unknown issue.
â Rui F Ribeiro
Jul 23 at 11:25
add a comment |Â
up vote
0
down vote
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).
1
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
Thanks,dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours:nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this/etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution likemdns4_minimal
coming beforedns
with a return[NOTFOUND=return]
in the middle
â TPPZ
Jul 19 at 10:33
add a comment |Â
up vote
0
down vote
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).
1
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
Thanks,dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours:nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this/etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution likemdns4_minimal
coming beforedns
with a return[NOTFOUND=return]
in the middle
â TPPZ
Jul 19 at 10:33
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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).
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).
edited Jul 19 at 10:20
answered Jul 19 at 10:02
user1133275
2,075412
2,075412
1
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
Thanks,dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours:nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this/etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution likemdns4_minimal
coming beforedns
with a return[NOTFOUND=return]
in the middle
â TPPZ
Jul 19 at 10:33
add a comment |Â
1
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
Thanks,dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours:nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this/etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution likemdns4_minimal
coming beforedns
with a return[NOTFOUND=return]
in the middle
â TPPZ
Jul 19 at 10:33
1
1
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
host is a dns lookup tool (it ships with bind)
â Jasen
Jul 19 at 10:11
Thanks,
dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours: nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this /etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution like mdns4_minimal
coming before dns
with a return [NOTFOUND=return]
in the middleâ TPPZ
Jul 19 at 10:33
Thanks,
dig
works and resolves that "local domain". I am currently performing a similar "hack" like yours: nslookup my.sample-domain.local | grep -A1 my.sample-domain.local | tail -n 1 | awk 'print $2'
which looks very ugly to me. I need to figure out what is this /etc/nsswitch.conf
that has been mentioned and what's that DNS ordered resolution like mdns4_minimal
coming before dns
with a return [NOTFOUND=return]
in the middleâ TPPZ
Jul 19 at 10:33
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f457166%2fcan-not-resolve-local-domains-internal-to-my-office-lan%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
could be getaddrinfo (
/etc/gai.conf
) or nameserviceswitch (/etc/nsswitch.conf
), but I only know of these, not about.â Jasen
Jul 19 at 10:08
plz show your (sanitised) dig command and output (be sure @server was used)
â user1133275
Jul 19 at 10:39
This
dig @SERVER my.sample-domain.local +short
gives the outputdig: couldn't get address for 'SERVER': failure
on both the machines. I've tried also@$SERVER
(although I think that $ was a typo) and I get:dig: couldn't get address for '': not found
â TPPZ
Jul 19 at 10:50
1
You should not use .local on your DNS domains, unless you are talking about ZeroConf. What is your situation?
â Rui F Ribeiro
Jul 19 at 10:53
I don't manage the LAN network. The IT people does not know anything about Linux, their background is Windows stuff. I have no idea what that "local domain" thing is. I am just trying to connect to a Postgres DB that I don't manage but I am supposed to use to develop a backend application.
â TPPZ
Jul 19 at 10:55