Não é possível resolver domínios .local internos para o LAN do meu escritório

Question

No Linux Debian 9, eu consigo resolver um domínio local específico, por exemplo. my.sample-domain.local usando alguns comandos como nslookup ou host , mas não com alguns outros comandos como ping ou o cliente Postgres psql .

Acho que coisas como o Network Manager configuraram meu resolvedor de DNS corretamente (o conteúdo de /etc/resolv.conf ), então não sei por que isso está acontecendo?

Eu verifiquei com um colega usando o Windows 10 e eles não têm nenhuma entrada personalizada em seu arquivo host, embora no caso deles a versão do Windows de ping e sua UI do banco de dados para Postgres funcionem como esperado resolvendo o domínio em um arquivo. Endereço IP.

Por favor, veja abaixo:

$ 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>

EDITAR:

Enquanto isso, percebi que há uma máquina virtual Ubuntu 16 na mesma LAN do escritório, então eu entrei nela e tentei o comando ping que está funcionando lá.

Além disso, o Ubuntu VM não possui nenhuma configuração personalizada em /etc/hosts (o mesmo que meu laptop Debian 9 com /etc/hosts não personalizado).

O /etc/resolv.conf é semelhante (alguns domínios / IPs compartilhados, alguns outros IPs para o mesmo domínio).

No entanto, o arquivo /etc/nsswitch.conf é diferente, então acho que há algo acontecendo com esse mdsn4_minimal e a ordem da resolução dos hosts, como mdsn4_minimal vindo antes de dns :

hosts:      files mdns4_minimal [NOTFOUND=return] dns

e no Ubuntu:

hosts:      files dns

EDIT 2:

Tanto o Ubuntu 16 VM quanto o meu laptop Debian 9 podem resolver esse domínio .local usando o comando dig .

    

Answer 1

host e nslookup realizam pesquisas de DNS, mas a maioria dos aplicativos usa o Name Service Swtich da glibc para decidir como os nomes dos hosts são pesquisados.

Seu /etc/nsswitch.conf pode ativar o mDNS, o que pode causar problemas ao resolver os nomes .local . Você pode alterar a ordem em que as pesquisas são feitas ou apenas remover o serviço mDNS se achar que não será necessário.

Seu nsswitch.conf tem mdns4_minimal , que faz a pesquisa mDNS (para .local nomes). O [NOTFOUND=return] depois faz com que a pesquisa pare e, portanto, o DNS nunca é usado e seu aplicativo não pode resolver o nome do host. Você pode remover todo o mdns4_minimal [NOTFOUND=return] , portanto as pesquisas do mDNS não são usadas ou apenas remover a ação NOTFOUND para que a pesquisa de DNS seja feita caso a pesquisa do mDNS falhe.

Para mais detalhes, recomendo conferir a troca de serviços de nome documentação .

    

Answer 2

O problema maior aqui é que os nomes de domínio DNS terminados em .local não devem ser usados ao configurar infra-estruturas de DNS.

.local use é reservado para o uso de zeroconf / avahi aka bonjour, que são serviços paralelos para resolver nomes / serviços locais além do DNS.

Então o que acontece é que o seu serviço interno de nomes DNS está certamente tendo conflitos com o zeroconf em alguns cenários. Assim, a solução na pergunta que você aceitou.

A longo prazo, o nome DNS da sua rede interna não deve terminar em .local .

PS Como um aparte, além do DNS, os DCs / ADs locais da Microsoft também não devem receber o nome .local . Você terá problemas estranhos acontecendo se você fizer isso.

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.

De 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.

Eu não sou uma fonte oficial, eu também achei isso, que tem um parágrafo que explica bem o problema: Pare de usar .local como o domínio de nível superior para sua 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

Talvez você tenha um NBNS em conflito com um DNS , corrija isso ou edite seus hosts arquivo ou envolva seus comandos;

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

O DNS deve ser inspecionado com dig ;

dig @$SERVER $NAME +short

Eu estou supondo que o host procure primeiro o NBNS (ou o contrário)