[dns-esp] DNS Recursivo - Separar Cache v4 e v6 - Como medir a efetividade?
Nico
nicomail en gmail.com
Mar Oct 22 20:09:26 -03 2019
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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20191022/6af492b0/attachment-0001.html>
Más información sobre la lista de distribución dns-esp