[dns-esp] DNS Recursivo - Separar Cache v4 e v6 - Como medir a efetividade?

[Hugo Salgado-Hernández]

Hola Douglas! Português é bom! ;)
Obrigado pela contribuição.

Respecto a lo que mencionas, entiendo que esto se resuelve con el
uso de la extensión EDNS0 client-subnet. Me parece que las CDNs
hacen uso masivo de esa extensión, justamente para retornar
respuestas cercanas al cliente final.

En el caso de tu ejemplo la query de e) debería ir con un ECS
como 200.189.189.0/24, y la respuesta debiera ser cacheada
considerando ese "source prefix-length". Entonces cuando en
h) venga una query con source 2001:189:190::/48 el cache no
debiera reutilizar su respuesta anterior, y debe pasarla al
upstream, que en este caso considerante ese source debería
responder con la 2001:1:1::80.

Esto se encuentra en el RFC7871, sección 7.3.

Sin embargo, esto es la teoría ;) si tu has encontrado el problema
en el mundo real, sería interesante armar un laboratorio de prueba
y reproducirlo! Podríamos mandar un bug report a los desarrolladores
de los recursivos culpables.

[]s,

Hugo

On 16:42 18/10, Douglas Fischer wrote:
> Olá a todos!
> Uma saudação principal aqueles que estavam no BoF de DNS no LACNIC32.
> 
> Bom, o nome da lista é "DNS em Espanhol", mas vou tomar a liberdade de
> escrever em português...
> (Consultei os colegas, e me disseram que não haveria problemas).
> 
> Para meu primeiro contato com o Working Group, resolvi trazer a tona aquele
> tema que comentei na reunião presencial.
> 
> *** Caches Separados para DNS Recursivo para IPv6 e para IPv4. ***
> *** Como fazer uma análise para verificar se isso é realmente efetivo? ***
> 
> Apenas para clarificar:
> Não falo e eliminar resposta v4 das consultas para o socket v6 e nem
> eliminar respostas v6 para cunsultas feitas para o socket v4.
> 
> Essa teoria tem a ver com a formação dos caches e com a diferença da tabela
> de roteamento IPv4 e IPv6
> 
> 
> Vou tentar exemplificar:
> a - Imagine que uma CDN(Akamai, Azion, EdgeCast, etc...) tenha os seguintes
> nodos:
>  a.1 - São Paulo - 200.1.55.80 - 2001:1:55:80
>  a.2 - Miami - 200.1.1.80 - 2001:1:1::80
> b - Quando um cliente acessa algum site que use essa CDN para entrega de
> conteúdo, ele provavelmente vai receber alguma coisa como
> https://staticcontent.siteacessed.com/photoofthecompany.png.
> c - A primeira coisa que vai acontecer é que a empresa siteacessed.com vai
> apontar staticcontent.siteacessed.com para a CDN. Provavelmente com um
> CNAME para siteacessed.somecdnname.net.
> d - Imaginando um end-user usando IPv4 (200.189.189.189) de um ISP no Rio
> de Janeiro esteja acessando esse site, ele vai mandar para o NS recursivo
> usando IPv4 (200.189.180.53) do ISP a pergunta: ?siteacessed.somecdnname.net
> ?
> e - O Recursivo vai fazer a consulta e vai perguntar para os NS
> autoritativo(x.y.z.53) da CDN ?siteacessed.somecdnname.net?
> f - O mecanismo inteligente do Autoritativo da CDN vai analisar que o
> servidor que está mais "PERTO" desse cliente é o nodo de São Paulo, e vai
> responder
>     A -> 200.1.55.80
>     AAAA -> 2001:1:55::80
> g - O end-user vai acessar o conteúdo em 200.1.55.80,
> RioDeJaneiro->SãoPaulo_SãoPaulo->RioDeJaneiro e vai ser feliz...
> ---
> Até aqui tudo normal
> ---
> h - Agora um outro end-user desse mesmo ISP do Rio de janeiro, usando IPv6
> 2001:189:190::1234, resolve acessar o mesmo conteúdo que o usuário
> anterior, e vai mandar a pergunta ?siteacessed.somecdnname.net? para o
> mesmo NS recursivo só que por IPv6 (2001:189:180::53)
> i -  Acontece que agora o NS Recursivo tem no Cache as duas respostas... E
> vai mandar para o end-user.
>     A -> 200.1.55.80
>     AAAA -> 2001:1:55::80
> j - O end-user vai pegar essa resposta e vai tentar acessar 2001:1:55::80
> que é de São Paulo. Porém, por uma diferença nas políticas de roteamentos
> dos ASNs envolvidos, para acesssar esse IPv6, os pacotes tem que ir
> RioDeJaneiro->Miami->SãoPaulo_SãoPaulo->Miami->RioDeJaneiro...
> 
> 
> A diferença entre J e G é absurda... Certo?
> 
> Para resolver isso, o que as CDNs fazem?
>  -> Reduzem o TTL para 1 minuto...
> Bom, sabemos que isso não é saudável. E além de resolver completamente,
> pode também causar o problema contrário... No caso de a primeira pergunta
> depois da expiração do cache ser em IPv6.
> 
> 
> A minha proposta é que para contornar isso, os ISPs criem servidores
> separados para v4 e para v6:
> - Server v4 só responde para IPv4, prefere fazer perguntas aos
> autoritativosm em IPv4
> - Server v6 só responde para IPv6, prefere fazer perguntas aos
> autoritativosm em IPv6
> 
> 
> Pronto. Contei a história!
> E aí? Faz algum sentido para os senhores?
> 
> Se faz sentido, como criar comprovar isso?
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

> _______________________________________________
> dns-esp mailing list
> dns-esp en listas.nic.cl
> https://listas.nic.cl/mailman/listinfo/dns-esp

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: no disponible
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20191022/2c0157f7/attachment.sig>