16.10 falha ao resolver DNS

Question

Após atualizar minha instalação do 16.04 para o 16.10, tenho problemas com o DNS.

Primeiro eu tenho problemas algumas vezes quando conectado ao WiFi, enquanto ele trabalhava em ethernet. Agora parece funcionar em WiFi também. Não sei porquê, e se de alguma forma está relacionado com o problema que enfrento agora:

Ao conectar-se a um host VPN com o Cisco Anyconnect VPN , ele adiciona uma linha em '/etc/resolv.conf' . Eu entendo que o Ubuntu agora está usando systemd-resolve , e a página man diz que existem três modos diferentes para manipular o /etc/resolv.conf. Meu /etc/resolv.conf não é um link simbólico, e não lista 127.0.0.53 como um servidor DNS, então, tanto quanto eu entendi systemd-resolvido deve "lê-lo para dados de configuração do DNS". No entanto, não parece se importar com isso.

dig

O estranho (para mim) é que dig host.customer.tld , retorna uma boa resposta com uma SECÇÃO DE RESPOSTA mostrando o ip do host requisitado, e se refere ao servidor dns adicionado ao /etc/resolv.conf pelo cliente vpn como o servidor. Quando a conexão vpn está desativada, não obtenho resposta. Ou seja dig lê /etc/resolv.conf.

ping

O navegador, por outro lado, não acessa o /etc/resolv.conf e não consegue resolver o nome do host. Nem o ping / curl, a propósito.

nmcli

Eu encontrei uma postagem relacionada e tentei executar

nmcli device show <interfacename> | grep IP4.DNS

mas não lista nenhum dns para o dispositivo cscotun0. (Isso também não acontece em 16.04.) Além disso, a nmcli lista meu servidor dhcp (meu roteador) como host IP4.DNS para minhas conexões eth / wlan. Usar dig @192.168.0.1 xxx para qualquer domínio público funciona bem.

configuração

Existem alguns outros servidores DNS listados em meu /run/systemd/resolve/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Estes não são servidos pelo meu servidor DHCP. o arquivo /etc/systemd/resolved.conf contém apenas linhas comentadas, exceto o cabeçalho da seção:

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

A página man do resolved.conf diz que

  

DNS =     Uma lista separada por espaço de endereços IPv4 e IPv6 para usar como servidores DNS do sistema.     ...     Por motivos de compatibilidade, se essa configuração não for especificada, os servidores DNS     listados em /etc/resolv.conf são usados em vez disso, se esse arquivo existir e     servidores são configurados nele. Esta configuração é padronizada para a lista vazia.

     

FallbackDNS =     Uma lista separada por espaço de endereços IPv4 e IPv6 para usar como DNS de fallback   servidores. Qualquer servidor DNS por link obtido de systemd-networkd.service (8)   ter precedência sobre essa configuração, assim como qualquer servidor configurado via DNS = acima ou   /etc/resolv.conf. Essa configuração é usada apenas se nenhum outro servidor DNS   informação é conhecida. Se esta opção não for fornecida, será usada uma lista compilada de servidores DNS.

Parece que o fallback acaba em /run/systemd/resolve/resolv.conf no meu caso.

EDIT: Eu não tinha certeza qual era o problema, e para ser honesto eu ainda não sei exatamente como isso funciona, mas pelo menos aconteceu que a solução no meu caso foi desative o serviço systemd-resolved . Eu pensei que o serviço era necessário, que era o componente que fornecia o serviço DNS para todos os aplicativos locais, mas aparentemente há algo mais fazendo esse trabalho.

    

Answer 1

Eu tive problemas semelhantes, por exemplo, adicionando um dongle USB extra. Primeiro desativei o dnsmasq no networkmanager como descrito acima e parei o dnsmasq (service dnsmasq stop)

Eu percebi que quando a resolução quebrou durante minha conexão VPN, a tabela de roteamento parece um pouco diferente (saída do comando route). O nome do Gateway é DD-WRT no caso de não funcionar e simplesmente 'gateway' quando funciona. A saída disso não mudou:

nmcli device show wlp1s0 | grep IP4.DNS

Ele continuou mostrando o IP do meu roteador. Uma solução para fazê-lo funcionar por um tempo é reiniciar o systemd-resolvd:

sudo service systemd-resolved restart

Como o dnsmasq está fora da equação, é o systemd-resolvd que é a causa do problema, ou qualquer coisa que mude a tabela de roteamento.

Portanto, esta é a única diferença que vejo:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    601    0        0 

que funciona. E isso quando não funciona:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    601    0        0 wlp1s0

E a mesma diferença de nome na linha da VPN:

vpn-dns.name gateway         255.255.255.255 UGH   0      0        0 wlp1s0

Quem sabe o que pode influenciar a tabela de roteamento? Seria ótimo se pudéssemos identificar isso para que um relatório de bug pudesse ser arquivado. Estou ficando seriamente doente e cansado de perseguir todos esses bugs, mas gostaria de corrigi-los para que futuros usuários e nós fiquem felizes:).

[atualização] Parece que parar o systemd-resolved pode corrigir isso e não afetar negativamente outras coisas. Você pode tentar isso e informá-lo se ele quebrar alguma coisa. Eu vi ao executar o systemd-resolvd na depuração quando ele quebrou:

Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *

Para desativar:

sudo systemctl disable systemd-resolved.service

Eu atualizei o relatório do Ubuntu com sugestões. [/atualizar] Adicionar: Nota: o relatório de erros: link tem um patch para 17,04 para alguns problemas. Por favor, verifique o relatório do bug e, se possível, teste o patch. Obrigada!

[atualização]

Por favor, verifique o relatório de erros acima mencionado, o problema parece ser resolvido por 17.10 e com um comando simples, o vazamento de DNS pode ser desabilitado também.

[/ update]

    

Answer 2

O comportamento do DNS durante a conexão OpenVPN melhorou imediatamente quando eu segui uma sugestão em ubuntuforums:

1. Abra /etc/NetworkManager/NetworkManager.conf em um editor com direitos de root.
2. Excluir (ou comentar com um hash # ) a linha que lê dns=dnsmasq
3. Reinicie o NetworkManager via sudo service NetworkManager restart

Answer 3

Correu para o mesmo problema. De alguma forma eu devo ter instalado o DNSmasq com algum aplicativo. Simplesmente remover o dnsmasq resolveu o problema para mim.

sudo apt-get remove dnsmasq 

Desde então, não há mais desconexões ou alguns sites não podem mais ser carregados (tive um problema ao carregar o gmail, ou seja, de repente não consegui me conectar ao Gmail, embora outros sites funcionassem).

    

Answer 4

Edite /etc/nsswitch.conf e altere

hosts:          files mdns4_minimal [NOTFOUND=return] dns

para

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Editar:

Eu tenho os mesmos problemas há algum tempo. Consegui resolver nomes de domínio da vpn, mas não consegui fazer ping ou enrolar esses nomes ou usá-los em outros aplicativos. A mudança descrita acima resolveu para mim.