DNS (y bind9)
Introducción
De vez en cuando conviene comprobar cómo hemos dejado las cosas, y en este caso el DNS, gestionado por bind9, suele tener bastantes pegas, quizás por lo complejo de su configuración, y quizás porque muchas veces es demasiado grande para las necesidades reales del lugar en el que funciona.
En la página de enlaces hay varios sitios donde comprobar cómo nos ven desde fuera respecto a la resolución de nombres de nuestros dominios.
En el caso de mi empresa, Venexma Europa, he descubierto varios errores que ni me imaginaba y que voy a arreglar siguiendo varias fuentes, y a dejar constancia aquí de lo realizado.
Enlaces de referencia
Problemas encontrados
Son los siguientes:
- El servidor DNS permite búsquedas recursivas a todo el mundo.
- Los servidores DNS no tiene el mismo número de serie
- Desde el punto de vista exterior a veces se resuelven nombres a direcciones internas y a veces a externas, provocando un caos y varios servicios fallidos.
Solución aplicada
Se utiliza una característica de Bind9 denominada vistas y que consisten en presentar un conjunto de datos concreto dependiendo de quién los pida.
En nuestro caso vamos a utilizar el archivo /etc/bind/named.conf.options incluído automáticamente en /etc/bind/named.conf y le vamos a añadir estas lístas de acceso:
acl "trusted" {
192.168.0.0/24;
localhost;
};
acl "slaves" {
111.222.333.444;
};
La primera zona incluye toda nuestra red local y la máquina local, mientras que la segunda incluye la dirección IP de nuestro servidor de nombres secundario.
Ahora creamos una vista desde el punto de vista interno:
view "internal" {
match-clients { trusted; };
recursion yes;
};
y otra desde el punto de vista externo:
view "external" {
match-clients { any; };
recursion no;
};
y como puede observarse, lo que las diferencia es quién puede conectar a ella. En la interior únicamente los definimos como nodos fiables, a los que además se les permite búsquedas recursivas, y en la exterior se aplica a todo el mundo y no se permite más que consultas directas. Éste último punto es el que ataja uno de los problemas mencionados: al apertura del servidor DNS al mundo mundial.
Conviene recordar que el orden de las vistas es fundamental tal y como hemos definido los accesos. El primero limita a un subconjunto de direcciones IP y el segundo se queda con todas las demás. El servidor, por otra parte, está escuchando normalmente en todos los puertos e interfaces de red, puesto que asumimos que está dando servicio de nombres en la puerta de acceso a Internet.
Ahora vamos a definir contenido para las vistas y lo llevamos a cabo definiendo zonas dentro de ellas como en:
view "internal" {
match-clients { trusted; };
recursion yes;
zone "venexma.net" {
type master;
file "db.venexma.internal";
allow transfer { any; };
};
};
y en
view "external" {
match-clients { any; };
recursion no;
notify yes;
zone "venexma.net" {
type master;
file "db.venexma.external";
allow-query { any; };
allow-transfer { slaves; };
};
};
Esto es, ambas zonas tiene archivos separados para definir las correspondencias entre nombres y direcciones IP y, mientras que en la interior se permite prácticamente todo a las máquinas internas, la exterior sólo tiene acceso abierto para transferir las zonas a los servidores secundarios, a los que notificará la existencia de cambios en la base de datos (claúsula notify de la vista).
Lo anterior soluciona los problemas 2 y 3 expuestos arriba, puesto que nuestro servidor se encargará de notificar los cambios a los esclavos de manera que todos presenten siempre una misma correlación de direcciones y nombres.
Nota: Para este problema en concreto debemos tener claro que el servidor secundario es externo a la red, por lo que sólo necesita conocer una de las dos vistas; si necesitamos configuraciones más avanzadas, como servidores esclavos que sincronizan ambas vistas, es mejor consultar los enlaces anteriormente descritos.