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