[caiu] GigaDNS

Sexta Outubro 30 21:56:15 BRST 2015

Costumo usar esses pra testar. 

https://www.grc.com/dns/benchmark.htm 

https://code.google.com/p/namebench/ 

---

Att.

-------------------------

DIEGO CANTON DE BRITO

Em 2015-10-30 21:15, Eduardo Rigler escreveu: 

> Um aplicativo interessante para testar DNS é o namebench[1 [1]], ele faz
> bechmark de servidores públicos e privados e ao final do teste mostra
> alguns gráficos e sugestões sobre quais são os melhores para usar e
> inclusive sugere a ordem de pesquisa.
> 
> [1] https://code.google.com/p/namebench/ [2]
> 
> []'s
> Em 30/10/2015 8:49 PM, "Gelson Dias Santos" <gelson.santos em metaverse.com.br>
> escreveu:
> Ja que venho enfrentando timeouts com o Google DNS, resolvi hoje experimentar o GigaDNS, imaginando que teria uma vantagem enorme pela proximidade, ja que sou de Porto legre, cliente GVT. Para minha surpresa, o MTR mostra que estou consultando servidores em SP, e que existe uma perda enorme no caminho. Eu nao deveria ser redirecionado para os servidores em POA? Gelson |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | Vortex.lan - 0 | 21 | 21 | 0 | 0 | 3 | 0 | | 192.168.25.1 - 0 | 21 | 21 | 1 | 2 | 7 | 2 | | gvt-b-se01.pae.gvt.net.br - 0 | 21 | 21 | 7 | 8 | 16 | 7 | | 179.184.83.111.dynamic.adsl.gvt.net.br - 0 | 21 | 21 | 7 | 9 | 17 | 8 | | gvt-te-0-3-0-9.rc01.pae.gvt.net.br - 0 | 21 | 21 | 9 | 11 | 17 | 11 | | gvt-te-0-5-0-8.rc03.cta.gvt.net.br - 0 | 21 | 21 | 18 | 20 |
23 | 20 | | gvt-te-0-4-0-6.rc01.spo.gvt.net.br - 0 | 21 | 21 | 24 | 25 | 29 | 28 | | gvt-te-0-0-0-2.rt01.spo.gvt.net.br - 0 | 21 | 21 | 24 | 26 | 29 | 27 | | 187-100-61-121.dsl.telesp.net.br - 0 | 21 | 21 | 23 | 28 | 73 | 23 | | 64.208.27.29 - 0 | 21 | 21 | 24 | 28 | 86 | 25 | | ae2-30G.ar1.CTA1.GRU.gblx.net - 16 | 13 | 11 | 24 | 26 | 31 | 25 | | 122.43.125.189.static.impsat.net.br - 0 | 21 | 21 | 24 | 25 | 30 | 27 | | dns2.gigadns.com.br - 6 | 17 | 16 | 24 | 25 | 33 | 25 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider Em 30 de outubro de 2015 19:54, Diego Canton de Brito < diegocanton em ensite.com.br> escreveu: De cara, o mais óbvio é que você vai conseguir controlar por onde virá o feed do cache. Sim, isso já fazemos hoje, escolhemos um dos trânsitos para receber na vdd um /23 que contem o /24 de CDN, e para SP o próprio /24, ainda assim o trafego não vem
de SP; E, salvo engano, além de direcionar para o repositório que contenha o resultado desejado, o DNS de lá também deve implementar algum tipo de balanceamento em relação à carga de cada cache. P.S.: E como algum outro colega citou, talvez até algum tipo de Layering em função do tipo de CDN contratada por cada publicador. Sim, ambos são esperados. Pelo que observei da Akamai, alguns tipo de serviços acabam com DNS final akamai.net (americanas, submarino, bancos), que me parece ser a geral e responder no cache de vez em quando; Outros recebem edgekey.net ou akadns.net, esses parecem ser serviços diferentes, tanto que "nunca" são direcionado para os cache, exemplo Linkedin (no edge) e Apple (no akadns, acho que MS também tem coisas). Partindo do princípio que o DNS e o IPs do Cache e dos NS recursivos usados pelo cache estejam no mesmo /24. É improvável que eles(akamai) implementem regras diferentes para destinos de entrega mais miúdos que
 256 

> IPs. Afinal é censo comum que o menor prefixo internético seja /24 Será
 que 

> isso faz sentido? Agora veio uma definição interessante que posso testar, vou verificar com o pessoal aqui para trocarmos o IP de um dos anycasts para testar isso; Mas acho improvável funcionar, temos que enviar os anúncios em uma sessão BGP multihop para eles, mandamos inclusive /24 para ver se isso influenciaria, afinal o que anuncio para eles é que irá receber resultados de DNS. --- Att. ------------------------- DIEGO CANTON DE BRITO Em 2015-10-30 17:54, Douglas Fischer escreveu: 
> 
>> De cara, o mais óbvio é que você vai conseguir controlar por onde virá
 o 

>> feed do cache. E, salvo engano, além de direcionar para o repositório que contenha o resultado desejado, o DNS de lá também deve implementar algum tipo de balanceamento em relação à carga de cada cache. P.S.: E como algum outro colega citou, talvez até algum tipo de Layering em função do tipo de CDN contratada por cada publicador. Com isso o source da querie DNS também pesa nessa matemática. Partindo do princípio que o DNS e o IPs do Cache e dos NS recursivos
> usados 
> 
>> pelo cache estejam no mesmo /24. É improvável que eles(akamai) implementem regras diferentes para
 destinos 

>> de entrega mais miúdos que 256 IPs. Afinal é censo comum que o menor prefixo internético seja /24 Será que isso faz sentido? https://eng.registro.br/mailman/listinfo/caiu [1] [1 [1]] --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em: https://eng.registro.br/mailman/options/caiu [3] [2 [3]]
> Links: ------ [1] https://eng.registro.br/mailman/listinfo/caiu [1] [2] https://eng.registro.br/mailman/options/caiu [3] _______________________________________________ caiu mailing list caiu em eng.registro.br https://eng.registro.br/mailman/listinfo/caiu [1] --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em: https://eng.registro.br/mailman/options/caiu [3]
 _______________________________________________ caiu mailing list
caiu em eng.registro.br https://eng.registro.br/mailman/listinfo/caiu [1]
--> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
https://eng.registro.br/mailman/options/caiu [3] 

_______________________________________________
caiu mailing list
caiu em eng.registro.br
https://eng.registro.br/mailman/listinfo/caiu [1]

--> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:

https://eng.registro.br/mailman/options/caiu [3]

Links:
------
[1] https://eng.registro.br/mailman/listinfo/caiu
[2] https://code.google.com/p/namebench/
[3] https://eng.registro.br/mailman/options/caiu