Início / unix / Perguntas / 457166
Accepted
TPPZ
Asked: 2018-07-20 01:26:26 +0800 CST

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

  • 772

No Linux Debian 9 eu sou capaz de resolver um domínio local específico, por exemplo, my.sample-domain.localusando alguns comandos como nslookupou host, mas não com outros comandos como pingou o cliente Postgres psql.

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

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 pinge a interface do usuário do banco de dados para Postgres funcionem conforme o esperado, resolvendo o domínio em um 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 entrei nela e tentei o pingcomando que está funcionando lá.

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

Ambos /etc/resolv.confparecem semelhantes (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 isso mdsn4_minimale a ordem da resolução dos hosts lá, como mdsn4_minimalantes dns:

hosts:      files mdns4_minimal [NOTFOUND=return] dns

e no Ubuntu:

hosts:      files dns

EDIÇÃO 2:

Tanto a VM Ubuntu 16 quanto meu laptop Debian 9 são capazes de resolver esse .localdomínio usando o digcomando.

debian dns

3 respostas

  1. Best Answer

    hoste nslookuprealizar pesquisas de DNS, no entanto, a maioria dos aplicativos usa o Name Service Switch da glibc para decidir como os nomes de host são pesquisados.

    Você /etc/nsswitch.confpode habilitar o mDNS, o que pode causar problemas ao resolver .localnomes. Você pode alterar a ordem em que as pesquisas são feitas ou apenas remover o serviço mDNS se achar que não precisará dele.

    Seu nsswitch.conftem mdns4_minimal, que faz pesquisa de mDNS (para .localnomes). 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], para que as pesquisas de mDNS não sejam usadas, ou apenas remover a ação NOTFOUND para que a pesquisa de DNS seja feita caso a pesquisa de mDNS falhe.

    Para obter mais detalhes, recomendo verificar a documentação do Name Service Switch .

    • 31

  2. O maior problema aqui é: sabe-se que nomes de domínio DNS que terminam em .localnão devem ser usados ​​ao configurar infra-estruturas de DNS.

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

    Seu serviço de nomes DNS interno certamente está tendo conflitos com zeroconf em alguns cenários. Assim, a solução na questão 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 ser nomeados .local. Você terá problemas estranhos acontecendo se fizer isso.

    Padrão de multicast DNS (mDNS).
    A RFC 6762 de rastreamento de padrões da Internet Engineering Task Force (IETF) (20 de fevereiro de 2013) reserva o uso do rótulo de nome de domínio local como um domínio de pseudo-nível superior para nomes de host em redes locais que podem ser resolvidos por meio do DNS Multicast protocolo de resolução de nomes.

    De MS Technet (wikipedia)

    Se você tiver computadores cliente Macintosh que executam o sistema operacional Macintosh OS X versão 10.3 ou posterior, … é recomendável que você não use o rótulo .local para o nome DNS completo do seu domínio interno. Se você precisar usar o rótulo .local, também deverá definir as configurações nos computadores Macintosh para que eles possam descobrir outros computadores na rede

    RFC 6762

    Qualquer consulta DNS para um nome que termina com ".local". DEVE ser enviado para o
    endereço multicast mDNS IPv4 link-local 224.0.0.251 (ou seu
    equivalente IPv6 FF02::FB).

    ......

    1. Mapeamento de endereço reverso

      Assim como ".local.", os domínios de mapeamento reverso IPv4 e IPv6 também são definidos como link-local:

      Qualquer consulta DNS para um nome que termine com "254.169.in-addr.arpa". DEVE ser enviado para o endereço multicast mDNS IPv4 link-local 224.0.0.251 ou para o endereço multicast mDNS IPv6 FF02::FB. Como os nomes neste domínio correspondem a endereços locais de link IPv4, é lógico que o link local seja o melhor local para encontrar informações referentes a esses nomes.

    ......

    Nenhum controle especial é necessário para habilitar e desabilitar o DNS Multicast para nomes que terminam explicitamente com ".local". conforme digitado pelo usuário.
    O usuário não precisa de uma maneira de desabilitar o DNS Multicast para nomes que terminam com ".local.", porque se o usuário não quiser usar o DNS Multicast, ele pode conseguir isso simplesmente não usando esses nomes.
    Se um usuário inserir um nome que termina em ".local.", podemos presumir com segurança que a intenção do usuário era provavelmente que ele funcionasse.

    Embora não seja de uma fonte oficial, também encontrei 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

    O domínio .local é o que é chamado de domínio de pseudo-nível superior. O que isso significa? Isso significa que não é um domínio oficial de primeiro nível utilizável (roteável) na internet, mas tem uma posição semi-oficial porque é usado em alguns aplicativos.
    No caso de .local, é usado pelo Multicast Domain Name Service (mDNS). Os hosts que implementam esse serviço usam .local como seus nomes de domínio e têm sua própria maneira de resolver nomes. Normalmente, isso não seria um problema; no entanto, se você também implementar o DNS em sua rede com .local como o domínio de nível superior, isso causará sérios problemas de resolução de nomes.
    Já vi isso acontecer muito em sistemas Linux e imagino que o OS X da Apple provavelmente também terá esses problemas. Normalmente, nesses tipos de redes, você descobre que a resolução de nomes DNS não funciona ou funciona apenas algumas vezes. No final, você acaba tendo que usar endereços IP o tempo todo porque não sabe se um nome pode resolver ou não (o que nega todo o ponto de ter um servidor DNS em primeiro lugar).

    • 12

  3. Talvez você tenha um NBNS conflitante com um DNS , então corrija isso ou edite seu arquivo hosts ou envolva seus comandos;

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

    DNS deve ser inspecionado com dig ;

    dig @$SERVER $NAME +short

    Suponho que o host pesquise primeiro o NBNS (ou o contrário).

    • 0

relate perguntas