Estou usando um servidor BIND9 local para hospedar alguns registros DNS locais. Ao tentar cavar um nome de domínio local, não consigo encontrá-lo se não disser explicitamente ao dig para usar meu servidor BIND9 local.
user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @192.168.1.7 heimdal.lan.se
192.168.1.2
Ubuntu 17.04 e resolvido pelo sistema são usados. Este é o conteúdo do meu /etc/resolvido
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
E a saída de systemd-resolve --status
Global
DNS Servers: 192.168.1.7
192.168.1.1
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
A seção Servidores DNS parece ter configurado corretamente 192.168.1.7 como o servidor DNS principal (minha instância BIND9 local). Não consigo entender por que não é usado ... ?
Portanto, alterar minha interface eth0 com fio para ser gerenciada resolveu esse problema para mim.
Alterando ifupdown para managed=true em /etc/NetworkManager/NetworkManager.conf
Em seguida, reinicie o NetworkManager
Depois disso funciona perfeitamente..
Isso não foi 100%. Também apliquei essas alterações para tentar matar o resolvedor
Muito obrigado a esta postagem no blog sobre o assunto: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/
Vamos rezar para que isso funcione. Todo esse negócio de resolução de sistema é tão feio.
Meu palpite é que seu
systemd-resolvedserviço está configurado corretamente, mas nunca consegue ver a solicitação. O.localdomínio é tratado especialmente por sistemas rodando mDNS .avahi-daemon, que fornece serviços mDNS/DNS-SD (também conhecido como "Bonjour" em produtos Apple) pode ser configurado para ter precedência sobre o DNS durante a resolução de nomes; parece que o Ubuntu faz isso.Existem algumas opções que você pode escolher:
Renomeie seu
.localdomínio para algo diferente (possivelmente.internalou.lan). Isso pode ser o mais fácil de fazer na prática, porque você só precisa alterar algumas coisas no seu servidor DNS e funciona melhor com o Avahi. Eu recomendaria este método.Altere seu
/etc/nsswitch.confarquivo colocando adnsentrada na frente dasmdnsentradas.Altere a configuração do Avahi para alterar o domínio mDNS
.localpara outra coisa editando/etc/avahi/avahi-daemon.confe alterando (ou adicionando)domain-name=.something(localizado na[server]seção). Você precisará fazer isso em todos os computadores que usam mDNS para que eles ainda funcionem juntos.Parece que isso seria melhor como um comentário, mas não tem reputação suficiente....
A auto-resposta de Civing estava mais de acordo com o que eu queria.
Eu também tive que adicionar
dns=noneà[main]seção de/etc/NetworkManager/NetworkManager.conf, então ficou assim:Acabei de atualizar para o xubuntu 18.04, de 14.04, e tenho uma LAN mais antiga que isso, com muitos pequenos ajustes acumulados ao longo dos anos. Portanto, quero que meu DNS faça o que eu quero (sim, comprei muitas cópias do livro de Cricket Lius ao longo dos anos, começando com a segunda edição).
Como um aparte, eu já havia adicionado as informações de resolução de DNS que desejo ver ao arquivo
/etc/resolvconf/resolv.conf.d/head.Resumindo, uma vez eu tinha um /etc/resolv.conf funcionando, como root:
Mas agora, eu apenas edito /etc/resolv.conf diretamente, e ele fica parado. Os visitantes da minha LAN, que estão usando systemd/resolvconf, são SOOL. Eles não existem.
A leitura
man 8 resolvconfajudou. Muito. Não segui as instruções para colocar as coisas onde o programa ifup pudesse encontrá-las. Principalmente porque há toda uma superestrutura na GUI que já estava sendo ignorada por tudo o que foi feito durante a atualização. Esse parece ser um problema maior (WTF, Ubuntu?).Portanto, isso é horrível e ainda há o problema de que o que eu inseri (há muito tempo) na GUI do painel de controle de rede não estava sendo obedecido pelo sistema recém-atualizado, mas essa é uma questão totalmente diferente, uma vez que eu descubra como pergunte isso.
Para mim, executando um 18.04 instalado recentemente, fiz a primeira alteração citada por @Civing:
então, percebendo que /etc/resolv.conf estava sempre apontando para stub-resolv.conf e que um resolv.conf razoável com o servidor LAN DNS adequado estava sendo gerado, alterei o link simbólico:
e, em seguida, todos os nomes de host locais resolvidos via ping.
Resta saber por quanto tempo isso continua funcionando.
Quando instalei inicialmente, a configuração da rede sem fio falhou e não posso deixar de me perguntar se a instalação deixou o /etc/resolv.conf nesse estado inicial.
Então, uma sugestão é olhar o que o resolvido está gerando; você já pode ter uma base de trabalho.
Eu estava usando o Ubuntu 18 e estou mais acostumado com o debian e o centOS. Sugestão de confusão.
resolve.conf disse que está usando systemd-resolvido ok...
systemd mostra configurações globais e por link ok...
a pesquisa mostra que pode significar que está usando o netplan
Então, abra /etc/netplan/01-network-manager-all.yaml, e ele diz...renderer: NetworkManager
Acontece que o NetworkManager está no gui e é uma maneira de ativar as configurações por link. Mas... você pode instalar o nmcli e configurar esse otário na linha de comando...
Espero que isso tenha ajudado alguém.