Optimizar DNS mediante dnsmasq

En este artículo mostraré una manera de lograr una resolución eficiente de nombres de dominio, en este caso mediante dnsmasq.

Es conocido que en GNU/Linux, el archivo /etc/resolv.conf contiene los servidores que el sistema utilizará para la resolución de nombres de dominio (en otras palabras, los nameservers). Lo que no es tan conocido es que aunque en este archivo se coloquen decenas de nameservers, solo se admiten y consultan los primeros tres, indistintamente.

Esto puede resultar inconveniente cuando se necesita consultar direcciones de muchas subredes privadas diferentes. También puede ser ineficiente si por ejemplo uno de los nameservers es privado y los otros dos públicos, y se desea resolver una dirección de nuestra red, pero por algún motivo el sistema consulta los servidores públicos primero.

Ante estas limitantes, algunos optan por instalar localmente BIND, ignorando que podrían conseguir lo mismo e incluso más con dnsmasq, que es notablemente más liviano y fácil de configurar como forwarder, y además facilita algunos trucos de optimización. De modo que sin más preámbulos, pasemos a instalarlo y configurarlo.

Instalación y configuración

El primer paso consiste en instalar el paquete. A los efectos de este artículo asumamos que se utiliza Debian o una derivada; entonces instalar es tan sencillo como:

Una vez instalado el paquete, creamos un archivo de configuración personalizado:

El contenido de este archivo naturalmente dependerá de nuestra red y lo que deseemos lograr. Asumamos el siguiente escenario de ejemplo:

El equipo que estamos configurando tiene salida directa hacia internet mediante NAT. Nuestro ISP (ETECSA) nos ha delegado el dominio miempresa.cu (tanto para la zona directa como inversa) y tenemos nuestros nameservers (primario y secundario) en una DMZ, con las direcciones 192.168.53.3 y 192.168.53.4, respectivamente.

Para que cualquier consulta sobre miempresa.cu vaya exclusivamente a nuestros nameservers, y el resto salga a buscar los nameservers públicos, pero todo esto estrictamente en el orden que deseemos, podríamos colocar entonces en el archivo que acabamos de crear algo como esto:

Opcionalmente, puede declararse un archivo independiente para colocar ahi las líneas server y rev-server, de modo que cualquier cambio que se realice en los nameservers se cargue al vuelo sin necesitar recargar el servicio:

Ahora solo queda hacer que el sistema use nuestro nameserver local para resolver.

Para esto, primero ajustemos en la definición de interfaces cualquier referencia a los nameservers (las líneas dns-*), pues estas se usan para regenerar el archivo /etc/resolv.conf.

Revisamos los archivos /etc/network/interfaces y cualquier otro dentro de /etc/network/interfaces.d/ para o bien eliminar las líneas que aparezcan relacionadas con el servicio DNS (especialmente si no está instalado el paquete resolvconf), o dejarlas así:

Una vez hecho esto, verificamos que el contenido de /etc/resolv.conf sea solamente este:

Si queremos asegurar que el archivo no se modifique, opcionalmente podríamos hacerlo inmutable:

Tras estos cambios, solo queda reiniciar el servicio:

Lo que debe ocurrir en adelante, es que cuando el sistema intente resolver una dirección sin calificar, la tomará normalmente de /etc/hosts, pero si es una dirección plenamente calificada (FQDN), la consulta irá a dnsmasq y este a su vez la redirigirá al nameserver que corresponda. En el caso de una dirección interna como otroequipo.miempresa.cu, la consulta se dirigirá exclusivamente a nuestros nameservers, nunca a un nameserver externo. Y en el caso de una dirección externa como www.cubadebate.cu, la consulta se redirigirá a los nameservers externos, pero intentándolo estrictamente en el orden que los declaramos. Adicionalmente, dnsmasq almacenará localmente los resultados en su cache, por si se necesitan próximamente.

Usualmente esto será suficiente para notar un mejor rendimiento. No obstante, a veces nos encontramos el caso de equipos que necesitan realizar muchas consultas similares durante el día, como por ejemplo un MTA de nuestra empresa que intenta verificar la autenticidad de otros MTA en instancias remotas de nuestra misma empresa. Para tal caso, podríamos lograr un poco más de eficiencia declarando localmente los registros MX, A, PTR y SPF de esos MTA, por ejemplo:

De esta manera, nuestro MTA no necesita salir innecesariamente a consultar nameservers y puede entregar de inmediato, sin requerir que agreguemos la direccion IP de esos MTA a las redes de confianza de nuestro MTA. La opción host-record ofrece la ventaja de permitir declarar de una vez tanto el registro A en la zona directa como el registro PTR en la zona inversa, lo cual simplifica la configuración.

Conclusiones

Como puede apreciarse, la configuración de dnsmasq es flexible y razonablemente fácil. Llevo años utilizando esta aplicación y puedo afirmar que aunque no se haya concebido para funcionar como un nameserver real, dnsmasq es una herramienta sumamente efectiva apoyando como forwarder.

Dado que permite además muchas otras cosas, como hacer alias de direcciones IP, usar DNSSEC, crear un servicio DHCP autoritario, servir arranque por PXE, entre otras, dnsmasq resulta muy útil para cosas como crear un laboratorio virtual donde probar servicios antes de implementarlos en una red real para producción.

Para más detalles sobre las abundantes opciones de configuración de dnsmasq, puede consultarse el manual:

En fin, espero que encuentren la información de este artículo tan útil como asegura nuestro colega Héctor Suárez, quien me animó a escribirlo.

(Visited 195 times, 1 visits today)
Hugo Florentino
Sobre Hugo Florentino 7 Artículos
Administrador de redes y sistemas. Usuario regular de GNU/Linux desde Octubre de 2008. Miembro fundador del Grupo de Usuarios de Tecnologías Libres (GUTL).

7 Comentarios

  1. Saludos, Chamaco.

    Oh, te botaste. Fuiste más allá de lo que había concebido acá en mi trabajo, además de saber algunas cosas que ignoraba. Gran post.

    Les exhorto a que prueben esta opción. Yo que estoy detrás de un proveedor la voy a implementar. Ah, y de manera interna funciona con una rapidez espantosa, lo cual me gustó mucho.

    No obtante, Hugo, gracias por el post.

    🙂

  2. Ah, Hugo, se me olvidaba algo.

    ¿Podrías hace run post con una variante para dominio puramente interno? O sea, no un DNS que esté de cara a Inet o a la Red CUBA, sino uno interno de una institución.

    Ah, y la ventaja es que, si los Servidores DNS a consultar no tienen habilitada la recursividad, es mucho mejor; aunque también sería bueno deshabilitarla en el DNS forwarder.

    🙂

    • No tiene ciencia, basta con declarar los nameservers que desees utilizar, a dnsmasq le da lo mismo que estén dentro o fuera de la institución, el simplemente los usará para resolver y entregar los resultados al cliente que le pregunte. En el caso específico de este artículo, el cliente será exclusivamente el propio equipo, pero dnsmasq puede escuchar peticiones de toda una red y funcionar como nameserver recursivo. Para que no funcione la recursividad, basta con solo declararle los nameservers autoritarios de la institución.

  3. Leo tutos buenos como este y me da rabia estar en un VPN, por eso secundo al HECTOR, de hacer esto mismo pero dentro de mi red interna…dale huguete q tu sabes pa eso

    • ¿Que parte de que no tiene ciencia no entendiste?

      Solo declara a dnsmasq exclusivamente los nameservers que desees que use para consultar, da igual si estan en tu VPN o fuera, si los declaras y dnsmasq les llega, los usará.

        • Quizas lo encontré tan obvio que no me supe explicar; lo único que es necesario modificar para utilizar nameservers internos son las opciones server y rev-server para colocar ahi los ns de la red interna, y hacer que dnsmasq reenvíe las peticiones a estos.

          A diferencia de BIND, dnsmasq no trabaja con vistas, sino que en la declaración de un servidor uno puede decirle o no si es específicmente para resolver sólo un dominio.

          Ahora, si bien dnsmasq permite declarar registros y en ocasiones de hecho lo he utilizado como nameserver autoritario, no es para lo que está diseñado, de modo que en ese sentido tendrá limitantes en comparación a proyectos como BIND o NSD, por ejemplo. En resumen: dnsmasq para lo que es realmente bueno es como reenviador (forwarder).

          Espero haber comprendido correctamente la duda y haberla aclarado. En cualquier caso, la documentación de dnsmasq es bastante detallada y muestra todo lo que puede hacerse.

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*