Hola Douglas,No lo probé, pero si utilizas dnsdist, podes armar dos pools de nameservers con su correspondiente cache independiente.Luego generas reglas que si src es ipv4 va a un cache/pool y si es ipv6 va a otro.De esta manera, también los backend dns pueden operar solo sobre ipv4 o ipv6Saludos_______________________________________________On Tue, Oct 22, 2019, 18:46 Mauricio Vergara Ereche via dns-esp <dns-esp@listas.nic.cl> wrote:Hola!Complementando un poco los comentarios de Hugo y Douglas, recordé el keynote que dio Dave Dagon, un investigador que se especializa en temas de seguridad del Georgia Tech y que dio a principios de este año en el ICANN DNS Symposium donde habló precisamente sobre sus estudios de uso sobre EDNS-Client-subnet, su adopción en el mundo y cómo muchas veces terminaban haciendo un leak de privacidad no intencional afuera.Por si a alguien le interesa, los slides:Y el audio de ese día (empieza app a los 0:36:30)Saludos!On Tue, Oct 22, 2019 at 1:18 PM Douglas Fischer via dns-esp <dns-esp@listas.nic.cl> wrote: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@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@listas.nic.cl
> https://listas.nic.cl/mailman/listinfo/dns-esp
_______________________________________________
dns-esp mailing list
dns-esp@listas.nic.cl
https://listas.nic.cl/mailman/listinfo/dns-esp
--Douglas Fernando Fischer_______________________________________________
Engº de Controle e Automação
dns-esp mailing list
dns-esp@listas.nic.cl
https://listas.nic.cl/mailman/listinfo/dns-esp
--_______________________________________________
dns-esp mailing list
dns-esp@listas.nic.cl
https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list
dns-esp@listas.nic.cl
https://listas.nic.cl/mailman/listinfo/dns-esp