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

[Douglas Fischer]

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