DNS LACNOG October 2019

dns@listas.nog.lat

12 participants
3 discussions

[dns-esp] DNS Recursivo - Separar Cache v4 e v6 - Como medir a efetividade?
by Douglas Fischer 23 Oct '19

23 Oct '19

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

6 6

[dns-esp] Invitación a DNS WG BoF en LACNOG 2019 Panamá
by Mauricio Vergara Ereche 22 Oct '19

22 Oct '19

Estimados DNS entusiastas, Para aquellos que estén físicamente en Panamá para las reuniones LACNIC 32 y LACNOG 2019, el día *Jueves 10 de Octubre a las 18:00 hr* aproximadamente (luego del término de las sesiones de LACNOG) en la *sala 9* del mismo lugar de la conferencia, junto a Hugo Salgado de NIC Chile y quien les escribe, les invitamos a participar en una sesión de BoF para conversar temas sobre DNS y el Working Group DNS de LACNOG. La agenda tentativa para esa jornada es la siguiente: - Qué es y qué hace el WG DNS de LACNOG - Tópicos de discusión sobre Seguridad y Privacidad sobre DNS - Algunos tips sobre DoT y DoH - Preguntas abiertas / Ideas de proyectos / Comentarios sobre el futuro del WG. El único requisito para participar es estar inscrito, traer su credencial de la reunión LACNOG y estar interesados en asistir a esta jornada trayendo sus comentarios, inquietudes, ideas y cualquier otro tema que sea relacionado con el mundo DNS. La reunión no durará más de 1 hora. Hasta el momento no tenemos asignado audio/video para participantes remotos, pero si existe interés en participar a distancia, por favor responda a este mismo correo en forma privada, e intentaremos dar algún acceso. Saludos cordiales, Hugo, Mauricio -- Mauricio Vergara Ereche about.me/mave

6 9

[dns-esp] [DNS-ES] Consulta sobre query y delegación
by Miguel Angel Amador 18 Oct '19

18 Oct '19

Estimados Recurro a la lista por un caso puntual a resolver. en mi vista interna tengo el dominio pepito.com (por dar un ejemplo) ... pero se requiere que www.pepito.com apunta hacia cloudflare, donde vive todos los sitios web, entonces lo que se hizo fue crear en el dns interno el registro: pepito.com www 3600 IN NS rafe.ns.cloudflare.com. www 3600 IN NS zeus.ns.cloudflare.com. y en cloudflare es autoritativo para pepto.com en internet y en el el registro www.pepito.com A 200.20.20.20 , pero a su vez es proxeado por cloudflare. entonces mi duda es...una consulta en mi dns resolver interno no hace recursion, si no que va y consulta el www directo hacia cloudflare... y esta query es respondida por cloudflare como autoritativo, dando las ip's que el presenta, ¿La query es diferente a si yo la envio a un resolver de internet que si va a un autoritaritativo directamente? yo encuentro un poco sucia o poco elegante esa forma, pero no tengo un argumento tecnico de buena practica para decir que no es correcto y es lo que busco... o si es correcto, bueno, aceptarlo. Quedo atento. Gracias!

8 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

DNS LACNOG October 2019