Source: https://deployando.me/podcast/11-unbound/
Timestamp: 2020-01-20 20:47:41+00:00

Document:
https://deployando.me/podcast-player/129/11-unbound.mp3
Download file | Play in new window | Duration: 9:19 | Recorded on 3 de marzo de 2017
Bienvenidos al episodio 11 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 3 de marzo de 2017.
Quiero agradecer a todos los que edición tras edición van apoyándonos en las redes sociales, ya sea retuiteando o hablando en algún que otro hámbito. También a los que hacen comentarios en nuestro blog, en https://deployando.me; saben que los comentarios nos ayudan a darle una visión más amplia a los quemas que voy tratando.
En este podcast vamos a ver un tema sobre la resolución de los nombres. Todos sabemos que la resolución de nombres en Internet es la base, si esta resolución está degradada toda nuestra experiencia en La Red va estar igualmente perjudicada.
Generalmente para la resolución de nombres lo que hacemos es configurar unos servidores externos. Tenemos unas IPes y ponemos que toda la resolución se encargan los servidores IP tal e IP cual y generamos todas las consultas contra ello. Esto funciona muy bien para la mayoría de los usuarios.
En algunos casos si tenemos una infraestructura muy grande que está resolviendo contra servidores externos, vamos a tener un tráfico interesante en esta sesión de resolver. En esos casos, lo que se suele hacer es colocar un servicio de resolución dentro de nuestra propia red. Y toda la red consulta a ese servicio de resolución (DNS) interno y ese servicio cuando no conoce alguno de los nombres lo sale a consultar en internet.
Hay algunos casos donde hacemos un uso más intensivo del proceso de resolución. Por ejemplo en servidores de correo, donde por cada correo que se recibe se va a estar controlando el reverso del servidor que viene a entregar el correo. También en los servidores donde se hace análisis de contenido allí podemos estar verificando que los contenidos sean válidos que sus orígenes estén correctamente configurados, antes de entregar a los consumidores finales. Otro lugar donde se produce una alta frecuencia de resolución de nombres es en los proxies de navegación: toda la infraestructura va contra ese proxy y va estar resolviendo muchos nombres.
En estos casos ir a un servicio externo puede generar una latencia extra y lo que se hace es instalar un servicio local, que genera un cache local para atender esa alta demanda de resolución DNS. Y de esto precisamente vamos a hablar en esta edición del podcast.
Entonces, en contexto lo que tenemos es un servicio que por sus características hace un uso intensivo del DNS. En esos casos generalmente lo que hacía es instalar un BIND que configuraba exclusivamente como gestor del cache. Su configuración es bastante simple para esta tarea y funciona de manera excelente; pero me encontré problemas a la hora de gestionar el cache. Cuando ese cache no se refresca como se quiere, lo que he hecho es borrarlo y reiniciar Bind para volver a generar el 100% de las consultas.
Esto me ha parecido siempre bastante ineficiente y que tendría que haber algo mejor. Así es que encontré UNBOUND que es lo que quiero contarles ahora.
UNBOUND es servicio para resolver nombres en forma recursiva y generar un cache para responder futuras consultas.
A su vez, puede realizar validaciones DNSSEC asegurando la información que responde.
Implementa un mínimo de funcionalidad autoritaria para prevenir fugas de los root nameservers, como por ejemplo, resolver externamente localhost o el reverso de las IP 127.0.0.1 o ::1.
Al ser solamente un servicio de resolución y cache, tiene herramientas de gestión optimizadas exclusivamente para dicha tarea y es lo que a mi me gusta mucho.
Con la utilidad unbound-control podemos controlar el servicio, saber su estado, estadísticas (del cache) o modificar comportamiento en runtime, por ejemplo colocándole forwarding para distintas zonas o acceso a consultas a distintas sub-redes y, si lo queremos hacer permanente, lo habilitamos dentro del archivo de configuración.
UNBOUND está disponible como paquete en la mayoría de las distribuciones GNU/Linux. Es un servicio se instala y pone a funcionar. La configuración básica es sencilla, casi que queda funcionando por defecto.
Aunque viene en modo seguro por defecto con validación DNSSEC, por lo que he tenido que relajar los chequeos para adaptar mis instalaciones cuando no tengo un sistema DNSSEC.
Pero a su vez permite una alta personalizar para atender a necesidades del entorno o de seguridad de la instalación. Inclusive meterse a hilar fino con el cache, los timeout, los datos válidos y una larga lista de directivas adicionales.
Sus autores datan el nacimiento de Unbound en Enero de 2004 y es desarrollado por NLnet Labs una fundación sin fines de lucro con sede en Holanda que fue fundada en 1999.
Actualmente se encuentra en la versión 1.4.20 y está licenciado como BSD. NLnet Labs ofrece todo el software que desarrolla como software libre y la mayoría está licenciado como BSD.
Por todos estos motivos, me he volcado por unbound en las infraestructuras que administro.
Sitio unbound
terminal nullmailer ssh hashicorp packer chef ansible containers git sendmail atlas kernel piso13 datacenter etc augeas orquestación selinux immutable infrastructure aprovisionamiento dominio ios GNU automatización ssmtp virtualización DNS bash app nameserver etckeeper proxy correo openstack unbound ssl bind puppet vagrant shell sysadmin e-mail cifrado docker seguridad

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
in fine