<div dir="ltr">Hola Douglas y todos/as,<div><br></div><div>Justamente con el objetivo que vos mencionas de disponer de información para operaciones de servidores DNS (recursivos y autoritativos) desde ICANN venimos trabajando en el desarrollo de lo que llamamos KINDNS. El objetivo es desarrollar un marco que se centre en las mejores prácticas operativas más importantes o instancias concretas de las mejores prácticas de seguridad en torno al DNS. La idea es trabajar con la comunidad técnica, identificando y documentando un conjunto de normas acordadas mutuamente que respaldan un ecosistema de DNS seguro para que los operadores pequeños y grandes pueden complementar fácilmente y recurrir allí para referencia sobre los temas.</div><div><br></div><div>Aquí hay una descripción inicial e ideas de los objetivos del programa que espero podamos tenerlo disponible en el correr del este año.</div><div><a href="https://community.icann.org/display/KINDNS">https://community.icann.org/display/KINDNS</a><br></div><div><br></div><div>Mientras tanto, hay documentos desplegados por varios sitios con buenas prácticas, experiencias y recomendaciones (además de los estándares de la IETF); por ejemplo en los sitios de APNIC, RIPE y en algunos sitios de operadores de servidores DNS recursivos públicos que también han publicado algunas de sus experiencias.</div><div>También podemos armar una serie de instancias de capacitación en temas de DNS (con centro en lo operativo) en el correr de este año... qué les parece?</div><div>En la comunidad aquí en LAC tenemos unas cuantas personas que pueden contribuir con su experiencia y podemos armar un buen plan para ir desarrollando en el año.</div><div><br></div><div>Voy a armar un borrador de serie de webinars y charlas posibles sobre DNS y se los envío para que contribuyan con lo que les parezca más adecuado y así podemos armar algo bien interesante y comenzar a desarrollarlo por ejemplo a partir de Marzo.</div><div><br></div><div>Tomo los temas que planteó Douglas para integrarlos en el plan.</div><div><br></div><div>Fraterno saludo,</div><div>Nico</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié, 19 ene 2022 a la(s) 07:13, Douglas Fischer via dns-esp (<a href="mailto:dns-esp@listas.nic.cl">dns-esp@listas.nic.cl</a>) escribió:<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">¡Hola Alejandro!<br><br>¡Gracias por la pronta respuesta!<br><br>¡Tu blog ya está en la lista de favoritos de mi navegador! jajaja.<br><br>Pero me refiero a crear un compendio de técnicas y mejores prácticas para garantizar una seguridad y calidad muy altas en la entrega del servicio de DNS Recursivo a los clientes de un ISP.<br><br>Por ejemplo, un ISP con una gran cantidad de clientes (50 000 o más) sin duda debe tener preocupaciones como la alta disponibilidad y el equilibrio de carga.<br>Y para eso, la mejor solución es sin duda instanciar un conjunto Anycast dentro de su red.<br><br>¡Esta implementación de Anycast, por sí sola, ya es compleja de implementar!<br>Existe el problema del verificador de estado del servicio DNS y con eso interactuará con el motor del protocolo de enrutamiento para anunciar (o no) esa IP anycast.<br><br>Pero hay otros problemas como DNSSEC, que en un servidor DNS masivo puede ser traicionero. ¡Y necesita la atención adecuada!<br>Y ni siquiera me atrevo a discutirlo contigo aquí... jajaja.<br><br>Otro problema es habilitar en estos servidores funciones como la minimización de consultas, hiperlocal, DoT, DoH, etc.<br>Además de hiperlocal, sé que hay otros TLD que permiten la copia XFR de la zona completa, pero no tengo a mano una lista de estas zonas.<br><br>Para mí, una práctica que se recomienda, pero que estoy buscando los fundamentos técnicos para ayudar a defender el tema, es el uso de IP reservadas para uso privado como las IP que escuchan el servicio DNS y otra IP (en otra interfaz ) a las consultas externas.<br><br>Un tema que he visto como un tema recurrente de debate es si el DNS recursivo primario y secundario deben usar diferentes motores de DNS o no.<br><br>Y además de todo eso, vienen características complementarias como: whoami, estadísticas, lista negra arbitraria, etc.<br><br>Por fin...<br>Cada oración que cité aquí produciría un gran documento que explicaría por qué esta característica debería o no debería usarse, y cómo implementarla usando las herramientas de código abierto (o no) disponibles.<br>Y mira, ni siquiera mencioné todas las mejores prácticas posibles....<br><br>Ahora imagínelo todo compilado en un solo documento.<br><br>¡Para mí sería un sueño!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 19 de jan. de 2022 às 00:26, Alejandro Acosta via dns-esp <<a href="mailto:dns-esp@listas.nic.cl" target="_blank">dns-esp@listas.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, un gusto saludarte,<br>
<br>
   En mi blog tengo varias cosas de DNS, pero ya algunas tienen muchos <br>
años :-(<br>
<br>
   Sin embargo, leyendo lo que solicitas me vino a la mente este post <br>
del cual recibí buen feedback y parece ser que algo así es lo que buscas:<br>
<br>
<a href="https://blog.acostasite.com/2017/01/3-recomendaciones-al-construir-el.html" rel="noreferrer" target="_blank">https://blog.acostasite.com/2017/01/3-recomendaciones-al-construir-el.html</a><br>
<br>
<br>
   Y especificamente sobre recursivos -si, también sirve en <br>
autoritativos- (no tan viejo), tengo este:<br>
<br>
<a href="https://blog.acostasite.com/2019/07/por-fin-rrl-en-bind-por-defecto-con.html" rel="noreferrer" target="_blank">https://blog.acostasite.com/2019/07/por-fin-rrl-en-bind-por-defecto-con.html</a><br>
<br>
<br>
Saludos,<br>
<br>
<br>
Alejandro,<br>
<br>
<br>
On 18/1/22 9:31 PM, Douglas Fischer via dns-esp wrote:<br>
> ¡Hola a todos!<br>
><br>
> Estoy buscando documentación, recetas de pasteles, guías prácticas, <br>
> mejores prácticas para implementar servidores DNS recursivos para ISP.<br>
><br>
> Cosas como hyperlocal, anycast interno, dnssec y etc.<br>
><br>
> Yo también estoy tratando de tirar de la memoria...<br>
> algo sobre usar IPs reservadas para uso privado para que sean las IPs <br>
> de los servidores DNS Recursivos, y en el mismo servidor tener otras <br>
> IPs (v4 y v6) para que sean las que se usen para las recursiones.<br>
><br>
> ¿Algún colega puede sugerir alguna documentación?<br>
><br>
> _______________________________________________<br>
> dns-esp mailing list<br>
> <a href="mailto:dns-esp@listas.nic.cl" target="_blank">dns-esp@listas.nic.cl</a><br>
> <a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
_______________________________________________<br>
dns-esp mailing list<br>
<a href="mailto:dns-esp@listas.nic.cl" target="_blank">dns-esp@listas.nic.cl</a><br>
<a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="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">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><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></div>
_______________________________________________<br>
dns-esp mailing list<br>
<a href="mailto:dns-esp@listas.nic.cl" target="_blank">dns-esp@listas.nic.cl</a><br>
<a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
</blockquote></div>