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

Mar Oct 22 18:46:27 -03 2019

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20191022/11c6c1b3/attachment.html>