Servidor dns

El servidor DNS bind admite tres modos de funcionamiento

Servidor DNS maestro
Servidor DNS esclavo
Servidor caché DNS

Servidor maestro

En este modo de funcionamiento, nuestro servidor se comporta como un auténtico servidor DNS para
nuestra red local. Atenderá directamente a las peticiones de resolución de direcciones pertenecientes a
la
red local y reenviará a servidores DNS externos las peticiones del resto de direcciones de Internet.

servidor dns esclavo

Un servidor esclavo actuará como un servidor espejo de un servidor DNS maestro. Permanecerá
sincronizado con el maestro. Se utilizan para repartir las peticiones entre varios servidores aunque las
modificaciones solo se realicen en el maestro. En redes locales salvo por razones de disponibilidad, es
raro
que exista la necesidad de tener dos servidores DNS ya que con uno será suficiente.

servidor cache dns

En este modo de funcionamiento, nuestro servidor se comporta como si fuera un auténtico servidor
DNS
para nuestra red local aunque realmente no sea un servidor DNS propiamente dicho. Cuando recibe una
petición de DNS por parte de un cliente de nuestra red, la trasladará a un DNS maestro que puede estar
en
nuestra red o fuera, almacenará en una memoria caché la respuesta y a la vez la comunicará a quien
hizo la
petición. Si un segundo cliente vuelve a realizar la misma petición, como nuestro servidor tiene la
respuesta
almacenada en su memoria caché, responderá inmediatamente sin tener que cursar la petición a ningún
servidor DNS de Internet.
Disponer de un servidor caché DNS en nuestra red local aumenta la velocidad de la conexión a Internet
pues cuando navegamos por diferentes lugares, continuamente se están realizando peticiones DNS. Si
nuestro caché DNS almacena la gran mayoría de peticiones que se realizan desde la red local, las
respuestas de los clientes se satisfarán prácticamente de forma instantánea proporcionando al usuario
una
sensación de velocidad en la conexión.

Archivos de configuracion DNS

El archivo de configuración del DNS es el archivo /etc/bind/named.conf, pero este hace referencia a
otros
cuantos archivos como por ejemplo:

named.conf - Archivo principal de configuración

named.conf.options - Opciones genéricas
named.conf.local - Especificación particular de este servidor DNS
db.127 - Especificación dirección de retorno
db.root - DNSs de nivel superior
otros - db.0, db.255, db.empty, db.local, rndc.conf, rndc.key,
zones.rfc1918

Configurando un cache dns

Por defecto, al instalar el paquete bind está preconfigurado como servidor caché DNS. Tan solo será
necesario editar el archivo /etc/bind/named.conf.options y en la sección forwarders añadir las IPs de
dos servidores DNS donde redirigir las peticiones DNS:

// Configuración como caché DNS

// Añadir IPs de los DNS de nuestro proveedor en /etc/bind/named.conf.options
options {
forwarders {
80.58.0.33; 80.58.32.97;
};
};

Normalmente los servidores que aparecen aquí son los que nos proporciona nuestro ISP.

Configuranco un DNS maestro

Por razones de accesibilidad y organizativas, podemos dar un nombre a los equipos de nuestra red
local. Para ello instalaremos un DNS privado con un dominio ficticio. En nuestro caso se ha instalado
un servidor virtual en el cual instalaremos una serie de servicios a lo largo del trimestre.
Nuestro dominio ficticio en cuestion se llama “lol.virtual.gcap.net” cuya direccion ip es
“192.168.112.110”
Esta practiva tiene como objetivo registrar una serie de servicios que son los que se detallan a
continuacion:
El propio vps como dns,www,ftp y vps.
Uno de los equipos del grupo como dns2.
Otro de los equipos del grupo como ubuntu. Así este equipo se podrá identificar como p.e.
ubuntu.tux.virtual.gcap.net.

Esto quedaria de la siguiente manera:

192.168.112.110 - www
192.168.112.110 - ftp
192.168.112.110 - dns
192.168.112.110 - vps
192.168.112.7 - dns2
192.168.112.201 - ubuntu

nuestro servidor sera capaz de resolver peticiones internas tanto directas como inversas, para ello es
necesario añadir en el archivo de configuracion 7etc/bind/named.conf.local la especificacion de
maestro para el dominio y para la resolucion inversa:

// Añadir en /etc/bind/named.conf.local
// Archivo para búsquedas directas
zone "lol.virtual.gcap.net" {
type master;
file "/etc/bind/lol.db";
};
// Archivo para búsquedas inversas
zone "112.168.192.in-addr.arpa" {
type master;
file "/etc/bind/192.rev";
};

Evidentemente sera necesario crear los archivos lol.db y 192.rev en el que se recogera la asociacion
entre nombres y direcciones ip de nuestra red, en un sentido y en otro respectivamente.
Archivo de busqueda directa.

virtual:/etc/bind# cat lol.db

;
; BIND data file for lol.virtual.gcap.net
;

@ IN SOA lol.virtual.gcap.net. root.lol.virtual.gcap.net. (

1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
;
@ IN NS lol.virtual.gcap.net.

www IN A 192.168.112.110
dns IN A 192.168.112.110
mail IN A 192.168.112.110
ftp IN A 192.168.112.110
vps IN A 192.168.112.110
ubuntu IN A 192.168.112.201
dns2 IN A 192.168.112.7

Las primeras líneas son unos parámetros relacionados con la actualización del DNS (número de serie y
periodos de actuación). (NS = Name Server) (MX = Mail eXchange). Las siguentes líneas especifican
las IPs de los distintos PCs componentes del dominio (A = Address).

Archivo de busqueda inversa

; BIND reverse data file for 192.168.112.110

;

;
$TTL 86400
@ IN SOA lol.virtual.gcap.net. root.lol.virtual.gcap.net. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
110 IN NS dns.lol.virtual.gcap.net
110 IN PTR www.lol.virtual.gcap.net
110 IN PTR ftp.lol.virtual.gcap.net
110 IN PTR vsp.lol.virtual.gcap.net
201 IN PTR ubuntu.lol.virtual.gcap.net
7 IN PTR dns2.lol.virtual.gcap.net

Una vez configurado nuestro servidor dns, debemos indicarle a nuestro servidor linux, que el servidor
dns es el mismo, y que el subdominio es “lol.virtual.gcap.net”y esto se hace modificando el archivo
/etc/resolv.conf

virtual:/etc/bind# cat /etc/resolv.conf

nameserver 127.0.0.1
search lol.virtual.gcap.net

En el resto de PCs de la red, indicaremos que el servidor DNS es 192.168.112.110

// En el resto de PCs de la red indicamos quién es el DNS

// Editar /etc/resolv.conf del resto de PCs de la red
nameserver 192.168.112.110

Una vez hecho esto reiniciamos el demonio de bind9 para que se cargen las modificaciones realizadas:
// Arranque del servidor DNS
# /etc/init.d/bind9 restart

si todo se ha realizado correctamente, con las herramientas dig, host, o nslookup realizamos las pruebas
correspondientes:

virtual:/etc/bind# host ubuntu

ubuntu.lol.virtual.gcap.net A 192.168.112.14
virtual:/etc/bind# host dns2
dns2.lol.virtual.gcap.net A 192.168.112.201

configurando servidor esclavo

Si deseamos configurar nuestro servidor DNS para que actue como esclavo de un servidor DNS
maestro, la configuración es mucho más sencilla que en el caso anterior ya que únicamente será
necesario indicar en el DNS esclavo quién es el servidor DNS maestro, y en el DNS maestro, la IP del
DNS esclavo

Supongamos que nuestro servidor esclavo se llamara dns2.lol.virtual.gcap.net (192.168.112.7)

En nuestro archivo lol.db del servidor maestro añadimos la siguiente linea:

IN NS dns2.lol.virtual.gcap.net

de esta forma indicamos que existen mas servidores dns para esta zona, lo mismo haremos con el
archivo "192.rev" de la zona inversa:

7 IN NS dns2.lol.virtual.gcap.net

En el archivo /etc/bind/named.conf.local del servidor esclavo se debe indicar tambien que se trata
de un servidor esclavo y quien es el maestro.
// Añadir en /etc/bind/named.conf.local del esclavo
zone "lol.virtual.gcap.net" {
type slave;
file "/etc/bind/lol.db";
masters { 192.168.112.110; };
};
zone "112.168.192.in-addr.arpa" {
type slave;
file "/etc/bind/192.rev";
masters { 192.168.112.110; };
};

Tambien podemos sincronizar los servidores maestro y esclavos de manera que cualquier cambio en la
zona quede reflejado en todos servidores dns's de la zona. Est ose consigue añadiendo la linea "also-
notify"

// Archivo /etc/bind/named.conf.local del maestro

zone "lol.virtual.gcap.net" {
type master;
file "/etc/bind/lol.db";
also-notify {192.168.112.7;}
};
zone "112.168.192.in-addr.arpa" {
type master;
file "/etc/bind/192.rev";
also-notify {192.168.112.7;}
};

De ésta forma dispondremos en la red de un servidor DNS esclavo que podrá satisfacer las
peticiones DNS al igual que lo haría el maestro. Es interesante si el número de peticiones es muy
elevado y se requiere distribuir la carga entre los dos servidores, o si deseamos disponer de
servicio DNS de alta disponibilidad de forma que aunque el servidor maestro deje de funcionar, el
servidor esclavo podrá seguir ofreciendo el servicio.
Cada vez que hagamos un cambio en los archivos /etc/bind/ieslapaloma.db y /etc/bind/192.rev del
maestro, debemos acordarnos de actualizar el parámetro serial (incrementar en una unidad) para
que los dns dependientes del maestro sepan que ha cambiado y actualicen su información para
mantenerse perfectamente sincronizados

Una vez realizado esto ocurre algo que es propio de las nuevas distribuciones de Ubuntu, y es que
el demonio apparmor evita que se hagan modificaciones en la carpeta /etc/bind quitandole al
grupo bind los permisos de escritura sobre dicha carpeta, esto lo hace por motivos de seguridad
para que si en algun momento alguien logra tener acceso al sistema con el usuario bind, este no
pueda realizar modificaciones en los archivos de configuracion dns antes mencionados.

De esta forma lo primero que tenemos que hacer es, en el servidor esclavo, darle al grupo bind
permisos de escritura sobre la carpeta /etc/bind:

chmod g+w /etc/bind

una vez hecho esto en el archivo /etc/apparmor.d/usr.sbin.named modificamos la linea donde se le

quita permiso de escritura a la carpeta /etc/bind, añadiendo "w"

Con esto garantizamos que al iniciar el demonio bind9, este sincronize con el servidor maestro
para recibir un archivo "lol.db" actualizado, en caso de que se hayan realizado modificaciones en
la zona.

# vim:syntax=apparmor
# Last Modified: Fri Jun 1 16:43:22 2007
#include <tunables/global>

/usr/sbin/named {
#include <abstractions/base>
#include <abstractions/nameservice>

capability net_bind_service,
capability setgid,
capability setuid,
capability sys_chroot,
capability sys_resource,

# /etc/bind should be read-only for bind

# /var/lib/bind is for dynamically updated zone (and journal) files.
# /var/cache/bind is for slave/stub data, since we're not the origin of it.
# See /usr/share/doc/bind9/README.Debian.gz
/etc/bind/** rw, /////////dar permiso de escritura
/var/lib/bind/** rw,
/var/lib/bind/ rw,
/var/cache/bind/** rw,
/var/cache/bind/ rw,

Para hacer efectivos estos cambios, reiniciamos el demonio apparmor y luego el demonio bind9

sudo /etc/init.d/apparmor restart

sudo /etc/init.d/bind9 restart

Una vez hecho esto, para comprobar que se a llevado a cabo la sincronizacion, lo podemos
comprobar facilmente en los log del sistema.

cat /var/log/syslog

Jan 19 13:42:56 sparda-desktop named[6171]: running

Jan 19 13:42:56 sparda-desktop named[6171]: zone lol.virtual.gcap.net/IN: Transfer
started.
Jan 19 13:42:56 sparda-desktop named[6171]: transfer of 'lol.virtual.gcap.net/IN' from
192.168.112.110#53: connected using 192.168.112.7#37069
Jan 19 13:42:56 sparda-desktop named[6171]: zone lol.virtual.gcap.net/IN: transferred
serial 1
Jan 19 13:42:56 sparda-desktop named[6171]: transfer of 'lol.virtual.gcap.net/IN' from
192.168.112.110#53: Transfer completed: 1 messages, 10 records, 274 bytes, 0.102
secs (2686 bytes/sec)