[caiu] GigaDNS

Sexta Outubro 30 22:15:33 BRST 2015

Obrigado pelas sugestoes. Verifiquei com o namebench e obtive confirmacao
de que o GigaDNS seria uma pessima escolha para mim; ele é 76% mais lendo
que os servidores da propria GVT. Meu problema original era lentidao e
timeouts para resolucoes no Google DNS, e por isso estava buscando
alternativas, só que de forma manual. O namebench vai ajudar muito nesta
busca! por enquanto voutei para os servidores da GVT, até encontrar uma
alternativa razoavel independente da operadora. Infelizmente tenho apenas
um ADSL residencial por isso não é viavel rodar um recursivo proprio; não
quero manter um servidor ligado em casa para isso. A menos que eu consiga
usar meu router com OpenWRT.... hummm... ja tenho o que fazer no final de
semana :)

Gelson

Em 30 de outubro de 2015 22:07, Juliano Primavesi | Giga Internet Digital <
juliano em giga.com.br> escreveu:

>  A GVT normalmente prefere o PTT-SP, se o anuncio for igual em todos os
> PTTs, mesmo você estando no RS por exemplo.
>
> Em 30 de outubro de 2015 21:56, Diego Canton de Brito <
> diegocanton em ensite.com.br> escreveu:
>
> >
> >
> > 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
> > _______________________________________________
> > caiu mailing list
> > caiu em eng.registro.br
> > https://eng.registro.br/mailman/listinfo/caiu
> >
> >
> > --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >
> > https://eng.registro.br/mailman/options/caiu
> >
> _______________________________________________
> caiu mailing list
> caiu em eng.registro.br
> https://eng.registro.br/mailman/listinfo/caiu
>
>
> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>
> https://eng.registro.br/mailman/options/caiu
>