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

Mie Oct 23 17:01:47 -03 2019

... o simplemente le pones solo dirección IPv4 a unos recursivos y solo
IPv6 a otros recursivos, si no entendí mal el problema.

Saludos,
Nico

El mar., 22 de oct. de 2019 a la(s) 20:09, Nico via dns-esp (
dns-esp en listas.nic.cl) escribió:

> 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
> ipv6
>
> Saludos
>
> On Tue, Oct 22, 2019, 18:46 Mauricio Vergara Ereche via dns-esp <
> dns-esp en 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:
>>
>> https://www.icann.org/sites/default/files/packages/ids-2019/02-dagon-icann-ids2019-10may19-en.pdf
>>
>> Y el audio de ese día (empieza app a los 0:36:30)
>>
>> https://icann.zoom.us/recording/play/d2W2BusSHGj1rjkNL7N6vv3aqnAXpNptl1Yfe_HmLbj2M-z2j1HS_gKljwcPgH2Q?startTime=1557454159000
>>
>> Saludos!
>>
>> On Tue, Oct 22, 2019 at 1:18 PM Douglas Fischer via dns-esp <
>> dns-esp en 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 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
>>> _______________________________________________
>>> dns-esp mailing list
>>> dns-esp en listas.nic.cl
>>> https://listas.nic.cl/mailman/listinfo/dns-esp
>>>
>>
>>
>> --
>> Mauricio Vergara Ereche
>> about.me/mave
>>
>> _______________________________________________
>> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20191023/4d3e1ecb/attachment-0001.html>