[caiu] GigaDNS
Eduardo Schoedler
listas em esds.com.br
Sexta Outubro 30 21:04:03 BRST 2015
Existe rate-limite de ICMP nos clusters.
Você está tendo dificuldade com respostas no uso normal ou somente perdendo
pacotes?
Att.
Em sexta-feira, 30 de outubro de 2015, 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 <javascript:;>> 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]
> > >
> > > --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> > >
> > > https://eng.registro.br/mailman/options/caiu [2]
> >
> >
> > Links:
> > ------
> > [1] https://eng.registro.br/mailman/listinfo/caiu
> > [2] https://eng.registro.br/mailman/options/caiu
> > _______________________________________________
> > caiu mailing list
> > caiu em eng.registro.br <javascript:;>
> > 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 <javascript:;>
> https://eng.registro.br/mailman/listinfo/caiu
>
>
> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>
> https://eng.registro.br/mailman/options/caiu
>
--
Eduardo Schoedler
Mais detalhes sobre a lista de discussão caiu