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

Mie Oct 23 16:49:01 -03 2019

Todo esto que plantea Douglas sucede el 100% en el mundo de los ISP de la
region y sobre todo si son medianos o pequeños.
En este grupo recuerdo hay un par de especialistas en DNS recursivos con
los cuales podríamos hablar y entender cuales serian las mejores "posibles"
practicas.
Agrego el "posibles" dado que en la region muchas veces no todo se puede
aplicar.

Saludos.
Luciano.

El mar., 22 de oct. de 2019 a la(s) 17:18, Douglas Fischer via dns-esp (
dns-esp en listas.nic.cl) escribió:

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