Ele irá comparar vários servidores DNS públicos, incluindo o Google, ao atual.
Eu estava pesquisando informações sobre como usar o DNS do Google em nosso site, mas encontrei informações sobre o uso do DNS público do Google para nossos computadores locais.
Alguém sabe se é mais rápido? Ou uma boa maneira de medir isso?
Ele irá comparar vários servidores DNS públicos, incluindo o Google, ao atual.
Há também o teste de referência de DNS do GRC . Embora pareça que é apenas o Windows (a página da web alega que o Linux / WINE funciona).
Usar o DNS do Google (ou OpenDNS) pode ter efeitos negativos em alguns ISPs quando você está usando serviços (como o iTunes ou o YouTube) que usam redes CDN como a Akamai para distribuir conteúdo.
Meu entendimento é que as CDNs pagarão para peer ou co-localizar com redes ISP, e rotearão o tráfego da rede do ISP para o CDN através de uma conexão de fibra escura, evitando assim o congestionamento da Internet e melhorando o desempenho. A AOL Transit Data Network é um exemplo de tal serviço para os assinantes do serviço de cabo Road Runner.
O IMO, usando o DNS do Google, só faz sentido nesses cenários:
Para mim, a filial da Upstate NY Time Warner tem uma rede muito boa, então eu uso o ISP DNS. Eu acho que o DNS do ISP vai melhorar de qualquer maneira, já que os computadores estão ficando muito mais rápidos, e as caixas antigas que normalmente executam o trabalho de utilitário como servir DNS são absorvidas nos clusters VMWare.
Aqui está uma comparação do uso do DNS do Google e DNS do ISP para um vídeo do YouTube:
DNS do Google
$ ping v16.lscache2.c.youtube.com
PING v16.lscache2.l.google.com (209.85.239.38): 56 data bytes
64 bytes from 209.85.239.38: icmp_seq=0 ttl=47 time=54.822 ms
64 bytes from 209.85.239.38: icmp_seq=1 ttl=47 time=59.130 ms
64 bytes from 209.85.239.38: icmp_seq=2 ttl=47 time=56.981 ms
...
64 bytes from 209.85.239.38: icmp_seq=30 ttl=47 time=64.127 ms
^C
--- 209.85.239.38 ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 53.596/69.145/104.663/13.599 ms
DNS do ISP
$ ping v16.lscache2.c.youtube.com
PING v16.lscache2.l.google.com (74.125.0.38): 56 data bytes
64 bytes from 74.125.0.38: icmp_seq=0 ttl=54 time=37.129 ms
64 bytes from 74.125.0.38: icmp_seq=1 ttl=54 time=26.411 ms
64 bytes from 74.125.0.38: icmp_seq=2 ttl=54 time=21.199 ms
...
64 bytes from 74.125.0.38: icmp_seq=29 ttl=54 time=25.591 ms
64 bytes from 74.125.0.38: icmp_seq=30 ttl=54 time=20.021 ms
^C
--- v16.lscache2.l.google.com ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.686/24.215/37.129/4.080 ms
OBSERVAÇÃO IMPORTANTE: Este não é um teste científico por qualquer meio - outros fenômenos podem ser responsáveis pelo resultado diferente do DNS.
O DNS público do Google (8.8.8.8 ou 8.8.4.4) fornece um tempo de resposta relativamente consistente. Usando o utilitário de escavação, você pode verificar isso por si mesmo digitando:
dig @8.8.8.8 www.serverfault.com
No final, você terá algo assim:
;; Query time: 67 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 19 09:07:15 2010
;; MSG SIZE rcvd: 246
A execução do comando dig novamente com a escavação provavelmente acelerará um pouco a resposta:
;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 19 09:07:15 2010
;; MSG SIZE rcvd: 246
Isso porque a maioria dos servidores DNS armazenará em cache uma pesquisa para um servidor que está fora de si para pesquisa. Sites populares provavelmente já estarão no cache. Pesquisas subseqüentes vêm do cache e obtêm um aumento de desempenho.
Ao usar o DNS público do Google, a diferença entre uma pesquisa completa e uma pesquisa em cache não é tão dramática. No entanto, se você estiver executando seu próprio servidor DNS com cache (menos ocupado), poderá ver diferenças drásticas.
Se você fizer uma pesquisa por um site que não esteja em seu cache, poderá ver um tempo inicial de consulta de várias centenas de milissegundos. No entanto, quando estiver no cache, a pesquisa provavelmente estará próxima de zero (0) milissegundos.
Consulta inicial:
dig @Your.DNS.Server.IP www.serverfault.com
O que dá o seguinte resultado no final:
;; Query time: 184 msec
;; SERVER: Your.DNS.Server.IP#x53(Your.DNS.Server.IP)
;; WHEN: Fri Feb 19 09:14:19 2010
;; MSG SIZE rcvd: 217
Consulta subseqüente:
dig @Your.DNS.Server.IP www.serverfault.com
O que dá o seguinte resultado no final:
;; Query time: 0 msec
;; SERVER: Your.DNS.Server.IP#x53(Your.DNS.Server.IP)
;; WHEN: Fri Feb 19 09:14:19 2010
;; MSG SIZE rcvd: 217
Esse tempo de consulta próximo a zero (se não zero) durará enquanto a consulta do site www.serverfault.com não estiver fora do cache de resolução de nome do seu servidor de DNS local.
Esses números podem aumentar com o tempo. As pesquisas iniciais de um endereço com seu DNS provavelmente serão muito mais longas do que a pesquisa inicial com o DNS público do Google. No entanto, as pesquisas subseqüentes (contanto que permaneçam no cache) provavelmente serão significativamente mais rápidas. O DNS público do Google, por outro lado, parece consistentemente variar de aproximadamente 30 milissegundos a 60 milissegundos (de nossa localização, em testes não científicos).
Você terá que pesar os prós e contras por si mesmo.
Agora, é engraçado, enquanto eu estava testando isso, não consegui acessar os servidores DNS públicos do Google da minha rede. Não sei por que e estou investigando. Felizmente, usamos nossos próprios servidores e não somos efetivamente desconectados. Se eu estivesse nesse local e dependesse apenas do servidor DNS público do Google, eu teria sérios problemas de conectividade até que o problema fosse solucionado. Então, pese essa dependência externa também.
Tags google google-public-dns