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

Mar Oct 22 17:18:19 -03 2019

Concordo contigo que EDNSO Client-Subnet "resolveria" o problema!

Mas aí encontramos, como você bem disse, os problemas da vida real...

1- Muitos ISPs usando Recursivos com versões sem suporte a EDNS0, ou sem as
configurações corretas para isso.
1.1 - Um exemplo de configurações incorretas são recursivos de diversos
ISPs mandando Redes Inválidas como Client-Subnet.

2- Firewalls mais antigos, sem suporte a EDNS, no meio do caminho
interferindo nas perguntas com EDNS0.

3- Assim com apontando na questão do DNS64, a questão da privacidade está
também interferindo nisso!
Existem diversas orientações para se desligar a feature de Client-Subnet
nos recursivos.
Inclusive, se não estou enganado, o Quad9 não encaminha Client-Subnet
propositalmente.

4- Desconsiderando as CDNs diretas dos próprios Content-Providers(Google,
Facebook, Netflix) e focando só nas comerciais... Fora a Cloudflare, quem
mais está usando EDNS0-Client-Subnet?

Mas essas são Advinhações de minha parte.
O correto mesmo seria pensar num método para verificar e medir isso.

Considerando o quanto é complexo o ecosistema de DNS, não sei nem aonde
seria o lugar certo para pensar em fazer essas medições.

Em ter, 22 de out de 2019 às 15:12, Hugo Salgado-Hernández <hsalgado en nic.cl>
escreveu:

> 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
>
> _______________________________________________
> dns-esp mailing list
> dns-esp en listas.nic.cl
> https://listas.nic.cl/mailman/listinfo/dns-esp
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20191022/f26fbb6e/attachment-0001.html>