<div dir="auto">Hola Douglas,<div dir="auto">No lo probé, pero si utilizas dnsdist, podes armar dos pools de nameservers con su correspondiente cache independiente. </div><div dir="auto">Luego generas reglas que si src es ipv4 va a un cache/pool y si es ipv6 va a otro. </div><div dir="auto">De esta manera, también los backend dns pueden operar solo sobre ipv4 o ipv6</div><div dir="auto"><br></div><div dir="auto">Saludos </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 22, 2019, 18:46 Mauricio Vergara Ereche via dns-esp <<a href="mailto:dns-esp@listas.nic.cl">dns-esp@listas.nic.cl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hola!</div><div><br></div>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.<div><br></div><div>Por si a alguien le interesa, los slides:<br><div><a href="https://www.icann.org/sites/default/files/packages/ids-2019/02-dagon-icann-ids2019-10may19-en.pdf" target="_blank" rel="noreferrer">https://www.icann.org/sites/default/files/packages/ids-2019/02-dagon-icann-ids2019-10may19-en.pdf</a><br></div></div><div><br></div><div>Y el audio de ese día (empieza app a los 0:36:30)</div><div><a href="https://icann.zoom.us/recording/play/d2W2BusSHGj1rjkNL7N6vv3aqnAXpNptl1Yfe_HmLbj2M-z2j1HS_gKljwcPgH2Q?startTime=1557454159000" target="_blank" rel="noreferrer">https://icann.zoom.us/recording/play/d2W2BusSHGj1rjkNL7N6vv3aqnAXpNptl1Yfe_HmLbj2M-z2j1HS_gKljwcPgH2Q?startTime=1557454159000</a><br></div><div><br></div><div>Saludos!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 22, 2019 at 1:18 PM Douglas Fischer via dns-esp <<a href="mailto:dns-esp@listas.nic.cl" target="_blank" rel="noreferrer">dns-esp@listas.nic.cl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Concordo contigo que EDNSO Client-Subnet "resolveria" o problema!<br><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Mas aí encontramos, como você bem disse, os problemas da vida real...<br><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">1- Muitos ISPs usando Recursivos com versões sem suporte a EDNS0, ou sem as configurações corretas para isso.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">1.1 - Um exemplo de configurações incorretas são recursivos de diversos ISPs mandando Redes Inválidas como Client-Subnet.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">2- Firewalls mais antigos, sem suporte a EDNS, no meio do caminho interferindo nas perguntas com EDNS0.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">3- Assim com apontando na questão do DNS64, a questão da privacidade está também interferindo nisso!<br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Existem diversas orientações para se desligar a feature de Client-Subnet nos recursivos.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Inclusive, se não estou enganado, o Quad9 não encaminha Client-Subnet propositalmente.<br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">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?<br><br><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Mas essas são Advinhações de minha parte.<br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">O correto mesmo seria pensar num método para verificar e medir isso.<br><br></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Considerando o quanto é complexo o ecosistema de DNS, não sei nem aonde seria o lugar certo para pensar em fazer essas medições.</div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><br></div><span class="gmail_default" style="font-family:"courier new",monospace;font-size:small"></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter, 22 de out de 2019 às 15:12, Hugo Salgado-Hernández <<a href="mailto:hsalgado@nic.cl" target="_blank" rel="noreferrer">hsalgado@nic.cl</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hola Douglas! Português é bom! ;)<br>
Obrigado pela contribuição.<br>
<br>
Respecto a lo que mencionas, entiendo que esto se resuelve con el<br>
uso de la extensión EDNS0 client-subnet. Me parece que las CDNs<br>
hacen uso masivo de esa extensión, justamente para retornar<br>
respuestas cercanas al cliente final.<br>
<br>
En el caso de tu ejemplo la query de e) debería ir con un ECS<br>
como <a href="http://200.189.189.0/24" rel="noreferrer noreferrer" target="_blank">200.189.189.0/24</a>, y la respuesta debiera ser cacheada<br>
considerando ese "source prefix-length". Entonces cuando en<br>
h) venga una query con source 2001:189:190::/48 el cache no<br>
debiera reutilizar su respuesta anterior, y debe pasarla al<br>
upstream, que en este caso considerante ese source debería<br>
responder con la 2001:1:1::80.<br>
<br>
Esto se encuentra en el RFC7871, sección 7.3.<br>
<br>
Sin embargo, esto es la teoría ;) si tu has encontrado el problema<br>
en el mundo real, sería interesante armar un laboratorio de prueba<br>
y reproducirlo! Podríamos mandar un bug report a los desarrolladores<br>
de los recursivos culpables.<br>
<br>
[]s,<br>
<br>
Hugo<br>
<br>
On 16:42 18/10, Douglas Fischer wrote:<br>
> Olá a todos!<br>
> Uma saudação principal aqueles que estavam no BoF de DNS no LACNIC32.<br>
> <br>
> Bom, o nome da lista é "DNS em Espanhol", mas vou tomar a liberdade de<br>
> escrever em português...<br>
> (Consultei os colegas, e me disseram que não haveria problemas).<br>
> <br>
> Para meu primeiro contato com o Working Group, resolvi trazer a tona aquele<br>
> tema que comentei na reunião presencial.<br>
> <br>
> *** Caches Separados para DNS Recursivo para IPv6 e para IPv4. ***<br>
> *** Como fazer uma análise para verificar se isso é realmente efetivo? ***<br>
> <br>
> Apenas para clarificar:<br>
> Não falo e eliminar resposta v4 das consultas para o socket v6 e nem<br>
> eliminar respostas v6 para cunsultas feitas para o socket v4.<br>
> <br>
> Essa teoria tem a ver com a formação dos caches e com a diferença da tabela<br>
> de roteamento IPv4 e IPv6<br>
> <br>
> <br>
> Vou tentar exemplificar:<br>
> a - Imagine que uma CDN(Akamai, Azion, EdgeCast, etc...) tenha os seguintes<br>
> nodos:<br>
> a.1 - São Paulo - 200.1.55.80 - 2001:1:55:80<br>
> a.2 - Miami - 200.1.1.80 - 2001:1:1::80<br>
> b - Quando um cliente acessa algum site que use essa CDN para entrega de<br>
> conteúdo, ele provavelmente vai receber alguma coisa como<br>
> <a href="https://staticcontent.siteacessed.com/photoofthecompany.png" rel="noreferrer noreferrer" target="_blank">https://staticcontent.siteacessed.com/photoofthecompany.png</a>.<br>
> c - A primeira coisa que vai acontecer é que a empresa <a href="http://siteacessed.com" rel="noreferrer noreferrer" target="_blank">siteacessed.com</a> vai<br>
> apontar <a href="http://staticcontent.siteacessed.com" rel="noreferrer noreferrer" target="_blank">staticcontent.siteacessed.com</a> para a CDN. Provavelmente com um<br>
> CNAME para <a href="http://siteacessed.somecdnname.net" rel="noreferrer noreferrer" target="_blank">siteacessed.somecdnname.net</a>.<br>
> d - Imaginando um end-user usando IPv4 (200.189.189.189) de um ISP no Rio<br>
> de Janeiro esteja acessando esse site, ele vai mandar para o NS recursivo<br>
> usando IPv4 (200.189.180.53) do ISP a pergunta: ?<a href="http://siteacessed.somecdnname.net" rel="noreferrer noreferrer" target="_blank">siteacessed.somecdnname.net</a><br>
> ?<br>
> e - O Recursivo vai fazer a consulta e vai perguntar para os NS<br>
> autoritativo(x.y.z.53) da CDN ?<a href="http://siteacessed.somecdnname.net" rel="noreferrer noreferrer" target="_blank">siteacessed.somecdnname.net</a>?<br>
> f - O mecanismo inteligente do Autoritativo da CDN vai analisar que o<br>
> servidor que está mais "PERTO" desse cliente é o nodo de São Paulo, e vai<br>
> responder<br>
> A -> 200.1.55.80<br>
> AAAA -> 2001:1:55::80<br>
> g - O end-user vai acessar o conteúdo em 200.1.55.80,<br>
> RioDeJaneiro->SãoPaulo_SãoPaulo->RioDeJaneiro e vai ser feliz...<br>
> ---<br>
> Até aqui tudo normal<br>
> ---<br>
> h - Agora um outro end-user desse mesmo ISP do Rio de janeiro, usando IPv6<br>
> 2001:189:190::1234, resolve acessar o mesmo conteúdo que o usuário<br>
> anterior, e vai mandar a pergunta ?<a href="http://siteacessed.somecdnname.net" rel="noreferrer noreferrer" target="_blank">siteacessed.somecdnname.net</a>? para o<br>
> mesmo NS recursivo só que por IPv6 (2001:189:180::53)<br>
> i - Acontece que agora o NS Recursivo tem no Cache as duas respostas... E<br>
> vai mandar para o end-user.<br>
> A -> 200.1.55.80<br>
> AAAA -> 2001:1:55::80<br>
> j - O end-user vai pegar essa resposta e vai tentar acessar 2001:1:55::80<br>
> que é de São Paulo. Porém, por uma diferença nas políticas de roteamentos<br>
> dos ASNs envolvidos, para acesssar esse IPv6, os pacotes tem que ir<br>
> RioDeJaneiro->Miami->SãoPaulo_SãoPaulo->Miami->RioDeJaneiro...<br>
> <br>
> <br>
> A diferença entre J e G é absurda... Certo?<br>
> <br>
> Para resolver isso, o que as CDNs fazem?<br>
> -> Reduzem o TTL para 1 minuto...<br>
> Bom, sabemos que isso não é saudável. E além de resolver completamente,<br>
> pode também causar o problema contrário... No caso de a primeira pergunta<br>
> depois da expiração do cache ser em IPv6.<br>
> <br>
> <br>
> A minha proposta é que para contornar isso, os ISPs criem servidores<br>
> separados para v4 e para v6:<br>
> - Server v4 só responde para IPv4, prefere fazer perguntas aos<br>
> autoritativosm em IPv4<br>
> - Server v6 só responde para IPv6, prefere fazer perguntas aos<br>
> autoritativosm em IPv6<br>
> <br>
> <br>
> Pronto. Contei a história!<br>
> E aí? Faz algum sentido para os senhores?<br>
> <br>
> Se faz sentido, como criar comprovar isso?<br>
> <br>
> -- <br>
> Douglas Fernando Fischer<br>
> Engº de Controle e Automação<br>
<br>
> _______________________________________________<br>
> dns-esp mailing list<br>
> <a href="mailto:dns-esp@listas.nic.cl" target="_blank" rel="noreferrer">dns-esp@listas.nic.cl</a><br>
> <a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
<br>
_______________________________________________<br>
dns-esp mailing list<br>
<a href="mailto:dns-esp@listas.nic.cl" target="_blank" rel="noreferrer">dns-esp@listas.nic.cl</a><br>
<a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><font size="2"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"><span style="font-family:"courier new",monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div>
_______________________________________________<br>
dns-esp mailing list<br>
<a href="mailto:dns-esp@listas.nic.cl" target="_blank" rel="noreferrer">dns-esp@listas.nic.cl</a><br>
<a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8px">Mauricio Vergara Ereche</span><br></div><div><a href="http://about.me/mave" target="_blank" rel="noreferrer">about.me/mave</a></div><div><br></div></div></div></div>
_______________________________________________<br>
dns-esp mailing list<br>
<a href="mailto:dns-esp@listas.nic.cl" target="_blank" rel="noreferrer">dns-esp@listas.nic.cl</a><br>
<a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
</blockquote></div>