Recapitulemos: los servidores dns de mi proveedor se caen a menudo, y quería instalar un dns que haga de caché. No me fío de BIND (named), porque parece que no es muy seguro ni estable.
Primera opción: resolv.conf
jamarier y atopos me recomendaban endiñar más servidores en /etc/resolv.conf, en particular dos de Telefónica Data y dos de Auna. No es mala idea, pero sigues dependiendo de tres servidores para resolver nombres (el resto son ignorados). Además, mi idea era aprender a istalar algo que vaya en mi red local.
A vueltas con named
ridiculum me invitaba a probar con BIND, a pesar de los problemas de seguridad. Esta opción no me atrae demasiado; es posible que en mis condiciones actuales no tenga que preocuparme mucho por la seguridad, pero para qué aprender algo que es complejo y poco fiable. También ha usado pdnsd, aunque veo en la página de Bernstein sobre la competencia un buffer overflow.
De güiner is...
melenas recomienda tinydns, parte de djbdns, de Dan J Bernstein. Como quiera que melenas es mi ídolo, y siempre me trago lo que me cuenta, me decidí a probarlo. Y, ¡oh desgracia!, los RPMs son sólo para RedHat, y las instrucciones que nos apuntó están anticuadas. Así que paso a contaros mis experiencias con Mandrake 9.1.
Mini-HowTo: dnscache en Mandrake
Para empezar, el tal Bernstein parece que es un tipo peculiar. Tiene una guerra declarada contra la mitad de la internés, incluyendo BIND, sendmail, Verisign, IETF, y los Estados Unidos. En particular, y lo que nos interesa aquí, es su guerra contra el Filesystem Hierarchy Standard. Resulta que el tío tiene sus propias ideas sobre dónde colocar los paquetes que uno se instala, porque el sistema de /usr/local y demás es inconsistente: a veces actualizas una aplicación y la versión antigua se te queda en /usr/share. No me veo cualificado para saber si tendrá razón, el caso es que según sus instrucciones tienes que instalar sus herramientas en /package.
Según la licencia, el software en sí es modificable, pero no puedes distribuir las modificaciones. Cualquier distribución binaria debe dejar los mismos ficheros que si se realiza una instalación manual. (En esa página, Bernstein no explica sus motivos, sino que se lanza a una de sus diatribas contra un tal Rick Moen.) Es decir, que no es software libre, pero se podría parecer (siempre puedo distribuir su paquete y mis propios parches).
Istalación oficial
Las istrucciones de istalación dicen que primero hay que istalar daemontools, donde está svscan: el programa que va a mantener el servicio corriendo. (Casi se me olvida decir que a Bernstein no le gustan inittab ni init.d.) Os cuento los pasos que seguí:
- Como
root, creo un directorio /package:
mkdir -p /package
chmod 1755 /package
cd /package
- Descargo daemontools-0.76.tar.gz en
/package. Descomprimo el paquete daemontools:
gunzip daemontools-0.76.tar
tar -xpf daemontools-0.76.tar
rm daemontools-0.76.tar
cd admin/daemontools-0.76
- Compilo e istalo los programas
daemontools:
package/install
- y a tomal pol culo la bicicleta, obtengo múltiples errores
undefined reference to 'errno'
Veo por ahí que parece ser un problema en glibc, algo evidentemente fuera de mis posibilidades de arreglo.
Mandrake al rescate
Es hora de darles caña a mis superpoderes investigatorios. Algún alma caritativa de MandrakeSecure mantiene una versión RPMizada, lo que nos va a venir muy bien. Hay que decir que esta versión viola flagrantemente la licencia de djbdns, ya que no istala todo en /package. Espero que a Bernstein no le importe demasiado, a mí personalmente me da igual.
El enlace que viene en la página de Mandrake Secure no funciona; tenemos que irnos a esta otra página de rpmhelp, elegir nuestra versión de Mandrake (9.2 incluida) y bajarnos los paquetes a mano. Es una gozada, ninguno llega a los 100k: son daemontools, ucspi-tcp y djbdns. Encontramos tres variantes del último:
djbdns-localcache istala y configura dnscache para responder a peticiones sólo de nuestra máquina local,
djbdns-extcache es igual, pero permite consultas desde cualquier máquina que esté en la subred 255.255.255.0,
- y
djbdns es el servidor tinydns completo.
Yo me decido por la segunda opción, ya que tengo una cutre-red local de 2 ordenadores. Istalo los tres RPMs: primero daemontools, luego ucspi-tcp y por fin djbdns-extcache; y ¡voilá!, automáticamente
- se crean los usuarios
dnscache y dnslog, bajo los que correrá el servicio de dns;
- se crea el directorio
/service donde svscan (parte de daemontools) busca servicios que mantener andando;
- una entrada en
/service que apunta a djbdns,
- y los enlaces en
/etc/rc.d/rcX.d que arrancan svscan.
Ahora sólo queda modificar /etc/resolv.conf para que apunte a la máquina local; y, en mi caso, abrir el puerto de resolución de nombres (53) en el shorewall para que deje pasar las consultas del iMac.
Por algún extraño motivo, si hago consultas de nombres a localhost
host www.yahoo.com 127.0.0.1
no me responde; pero si utilizo la dirección IP local sí. Como no es mayor problema, lo dejaré así.
El funcionamiento de dnscache
¿Por qué es mejor tener dnscache que trastear el resolv.conf? El paquete incluye una lista de trece servidores en los que busca por defecto, en
/var/djbdns/dnscachex/root/servers/@;
son servidores de Verisign, la universidad de Tokio... supuestamente los servidores root de internet. ¿Qué puede ser más fiable?
La configuración es inexistente. Los registros de nombres que recibe dnscache traen un TTL, tiempo de vida, que es lo que utiliza para mantener la caché; tras una semana máximo, los descarta.
Despedida
Bueno, amigos, ya vale por hoy de dar la paliza. Sólo nos queda esperar a que Google indexe esta página para que el próximo pardillo que le haga caso al melenas lo tenga un poco más fácil :)
