[caiu] GigaDNS
Diego Canton de Brito
diegocanton em ensite.com.br
Sexta Outubro 30 20:57:02 BRST 2015
Se seus anúncios no RS forem menores e se iguais, mais antigos que os de SP sim, se não segue-se as regras de BGP e escolhe-se a menor rota.
--
Enviado do aplicativo myMail para Android sexta-feira, 30 outubro 2015, 08:48PM -02:00 de Gelson Dias Santos < gelson.santos em metaverse.com.br> :
>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]
>> >
>> > --> 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
>> 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
Mais detalhes sobre a lista de discussão caiu