Um arquivo / etc / hosts longo pode atrasar a pesquisa de DNS?

Estou enfrentando uma pequena pergunta aqui. Eu tenho um /etc/hostsarquivo longo . (trabalhando na Web, estou hospedando muitos sites localmente para desenvolvimento). Vamos dizer que tem cerca de 40, 50 linhas. Todos redirecionando para 127.0.0.1.

Agora, ao verificar o inspetor do Chrome, parece que minhas páginas da Web locais estão carregando lentamente devido à parte Pesquisa de DNS. Em um mygreatwebsite.localURL também definido no /etc/hostsarquivo.

Após uma verificação rápida, parece que reduzir o hostsarquivo para algumas linhas acelera drasticamente a parte de pesquisa do DNS. Então, minha pergunta, é possível ser confrontado com diferenças de cerca de 5 segundos para 50 linhas e tempos insignificantes para algumas linhas? Ou estou completamente faltando alguma coisa?

Seu tld .local pode ser o problema, o zeroconf usa isso. Não existe um padrão real, mas o tld sugerido para um tld interno é .site ou .internal. Veja http://en.wikipedia.org/wiki/Top-level_domain#Pseudo-domains para isso.

Um arquivo / etc / hosts longo pode atrasar a pesquisa de DNS?

A resposta é sim , em uma máquina Windows (XP / Vista / 7).

É um problema conhecido que um arquivo hosts longo não funciona bem com o serviço "Cliente DNS".

http://winhelp2002.mvps.org/hosts.htm :

na maioria dos casos, um arquivo HOSTS grande (acima de 135 kb) tende a desacelerar a máquina.

[Solução: defina o serviço "Cliente DNS" para manual ou desabilitado]

http://vlaurie.com/computers2/Articles/hosts.htm :

Observe que um arquivo de hosts com mais de 100 KB pode realmente atrasar a navegação, a menos que o serviço "Cliente DNS" esteja definido para iniciar manualmente.

www.ericphelps.com/scripting/samples/Hosts/:

O mais importante a ser feito antes de usar arquivos HOSTS grandes é desativar o serviço do cliente do Serviço de Nome de Domínio ("Cliente DNS" ou "DnsCache") em sua máquina. Parece bizarro, mas o cliente DNS não é necessário para fazer o DNS. Pior, se você tiver um arquivo HOSTS grande (o que eu sugiro), o cliente DNS bloqueia todo o seu PC.

... e eu pessoalmente testemunhei isso em três máquinas Windows diferentes: XP Pro, Vista e 7 Starter.

Eu sugeriria o uso do tcpdump para ver o que realmente está acontecendo. Sem ele, você estará apenas adivinhando.

A sintaxe básica seria

tcpdump -n -i eth0 port 80 or port 53

(se você estiver interessado em ver as portas 80 e 53, -n para impedir pesquisas de DNS, supondo que toda a comunicação esteja ocorrendo no eth0).

Se essas informações forem muito rápidas ou demais, redirecione-as para o arquivo de despejo adicionando:

 -s 0 -w /tmp/dump

e use ie wireshark para examinar o arquivo de despejo. Você pode ver informações precisas de tempo no arquivo e muito mais ...

Quando eu usava o Spybot, ele inseria cerca de 50.000 entradas de arquivos de hosts que redirecionavam sites maliciosos conhecidos para 127.0.0.1. Eu nunca notei nenhum problema em ter um longo arquivo de hosts dessa natureza. Provavelmente tem mais a ver com a configuração do desenvolvedor ou com o próprio código. Quantos sites você está servindo localmente (50?) Todo mundo leva um tempo para responder quando 50 entradas estão presentes?

Por várias razões, tenho arquivos de hosts em algumas máquinas com centenas de entradas. Isso não tem impacto nas pesquisas de DNS simplesmente porque, uma vez que a máquina encontrou uma entrada no arquivo hosts, ela não fará uma pesquisa pelas mesmas informações. Se tudo o mais estiver configurado corretamente, informando o tamanho do arquivo hosts não afetará o desempenho, pois mesmo com mil entradas, esse arquivo ainda pode ser analisado mais rapidamente do que uma pesquisa DNS. Verifique a ordem em que sua máquina está resolvendo endereços. O arquivo hosts deve ser o primeiro.

Com base nos meus testes, um arquivo hosts de 34 MB com alguns milhões de entradas torna a navegação no Windows um pouco mais lenta, mesmo quando o serviço "Cliente DNS" está desativado. Portanto, há um tamanho máximo além do qual você provavelmente não deseja ir.