[atualização e atualização II: veja minhas soluções inadequadas e adequadas no final da pergunta, com base em uma das respostas]
Eu tenho uma pesquisa de DNS extremamente lenta quando meu arquivo resolv.conf inclui o endereço IP 127.0.0.1, na verdade, muitos nomes não são resolvidos, já que (certamente) esgotam o tempo limite.
Encontrei uma pergunta com o que parece ser uma resposta válida aqui:
Pesquisa de DNS extremamente lenta
exceto que eu posso ver que a ferramenta dnsmasq está executando para o intervalo de IP 192.168.122.2 a 192.168.122.254. Isso se parece com os IPs usados pelo VirtualBox e pelo qemu, então imagino que, se eu desligar o dnsmasq, o acesso à Internet a partir de um sistema virtual irá falhar!
Haverá outro motivo para a lentidão e / ou o tempo limite? (note que o problema é mais proeminente com sistemas específicos, como as imagens do usuário em todos os sites do stackoverflow, incluindo askubuntu, quando o problema ocorre.)
Neste ponto, removo o IP do arquivo resolv.conf e ignoro o problema enquanto navego, mas não acho que seja a melhor solução (e, é claro, esse IP é reinstalado lá em cada reinicialização! ) Eu gostaria de uma solução mais permanente para este problema que ainda me permite rodar os sistemas virtuais como esperado.
P.S. Eu não corro o Gerenciador de Rede.
Conteúdo de / etc / network / interfaces
Observe que tive o problema antes de adicionar o segundo IP na eth1 (por exemplo, eth1: 0).
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth1
iface eth1 inet static
address 162.226.130.121
netmask 255.255.255.248
network 162.226.130.120
broadcast 162.226.130.127
gateway 162.226.130.126
auto eth1:0
iface eth1:0 inet static
name Local network
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
# bridge for virtual box
auto br0
iface br0 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
bridge_ports eth3
bridge_stp off
bridge_maxwait 0
bridge_fd 0
Conteúdo do /etc/resolv.conf (que ainda é um link suave como esperado) após uma inicialização:
# 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
nameserver 127.0.0.1
search m2osw.com
nameserver 192.168.122.1
nameserver 206.13.31.12
nameserver 206.13.28.12
Atualização:
Eu mesmo não escrevo uma resposta porque usei outra resposta aqui para resolver meu problema, embora não seja realmente o que eu queria fazer, é a solução mais fácil neste momento. O bug referenciado pelo autor do resolvconf abaixo, encontrado aqui:
link
indica claramente que se você quiser usar o bind9, você irá obter o namespace 127.0.0.1 no seu arquivo resolv.conf. Nenhuma escolha (RESOLVCONF = não parece não fazer nada, embora eu possa ter uma surpresa após uma reinicialização que farei muito em breve!)
Como uma observação: Se eu apontar o /etc/resolvconf/resolv.conf.d/tail softlink para / dev / null (como mencionado abaixo), então eu obtenho um resolv.conf que se parece com isto:
# 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
nameserver 127.0.0.1
Em outras palavras, eu ainda recebo o 127.0.0.1 que é o culpado neste momento. Mas também perco completamente os outros dois servidores de nomes, apesar de estarem claramente especificados na minha interface eth1. Dito isto, olhando no diretório / run / resolvconf / interface /, vejo um arquivo eth1.net e lo.named. O lo.named é copiado para o resolv.conf, mas não o eth1.net. Eu não tenho idéia de como esses arquivos são criados e depois copiados para o resolv.conf, mas esse é o dinamismo usado pelo resolvconf ...
De qualquer forma, existem duas soluções mencionadas no bug:
(1) Exclua o link /etc/resolv.conf e substitua-o por um arquivo simples com exatamente o que você deseja. Isso pode funcionar para você, mas achei que manter o arquivo dinâmico padrão seria melhor.
(2) Altere as configurações do bind9 para que o BIND possa responder a essas solicitações DNS locais. O interessante é que os nomes agora serão armazenados em cache no seu computador. Então nem tudo é ruim. Dito isto, eu não estava muito interessado em abrir o meu servidor de nomes para todos os nomes de domínio ... Mas isso funciona e eu não tenho que destruir o dinâmico resolv.conf.
Apenas no caso, há um exemplo de configuração para o vínculo para que isso funcione:
options {
[...]
forwarders {
// Google DNSes
8.8.8.8;
8.8.4.4;
};
[...]
};
Atualização II:
Tudo bem! A reinicialização livrou-se do arquivo lo.named no diretório / run / resolvconf / interface. Isso deve ser porque o bind sabe criá-lo se RESOLVCONF = yes, mas não o exclui se RESOLVCONF = no. No entanto, uma reinicialização cuida disso porque o diretório / run é um disco RAM.
Sem esse arquivo no caminho, o /etc/resolv.conf é configurado exatamente com o que eu esperaria, que é a lista de servidores de nomes conforme definido na minha definição eth1 encontrada em / etc / network / interface, como mostrado anteriormente.
Então ... é uma grande bagunça porque há muitos fatores e, em alguns casos, é necessário reiniciar o computador!