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?
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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
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@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
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-i...
Y el audio de ese día (empieza app a los 0:36:30) https://icann.zoom.us/recording/play/d2W2BusSHGj1rjkNL7N6vv3aqnAXpNptl1Yfe_H...
Saludos!
On Tue, Oct 22, 2019 at 1:18 PM Douglas Fischer via dns-esp < dns-esp@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@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list dns-esp@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
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@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-i...
Y el audio de ese día (empieza app a los 0:36:30)
https://icann.zoom.us/recording/play/d2W2BusSHGj1rjkNL7N6vv3aqnAXpNptl1Yfe_H...
Saludos!
On Tue, Oct 22, 2019 at 1:18 PM Douglas Fischer via dns-esp < dns-esp@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@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list dns-esp@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
-- Mauricio Vergara Ereche about.me/mave
dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
... 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@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@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-i...
Y el audio de ese día (empieza app a los 0:36:30)
https://icann.zoom.us/recording/play/d2W2BusSHGj1rjkNL7N6vv3aqnAXpNptl1Yfe_H...
Saludos!
On Tue, Oct 22, 2019 at 1:18 PM Douglas Fischer via dns-esp < dns-esp@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@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list dns-esp@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
-- Mauricio Vergara Ereche about.me/mave
dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
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@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@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
dns-esp mailing list dns-esp@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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
-
Douglas Fischer -
Hugo Salgado-Hernández -
Luciano Minuchin -
Mauricio Vergara Ereche -
Nico -
Nicolas Antoniello