Configuración de un servidor DNS en debian

Conceptos previos

Antes de comenzar cualquier configuración es necesario algunos conceptos:

• Servidor autoritativo: es el servidor DNS que tiene la información de un determinado dominio. En cambio, si para resolver un dominio necesita consultar otros servidores entonces no es autoritativo. Obsérvese que un servidor es autoritativo para un dominio o un conjunto de dominios; y no autoritativo para los restantes. Esto último, claro está, si el servidor no se niega a resolver nombres que no gestiona él, o dicho de otro modo, si el servidor permite consultas recursivas.
• Servidor maestro: es el servidor que contiene primariamente la información del dominio.
• Servidor esclavo: es un servidor que replica la información de dominio de un servidor maestro, gracias a que se sincroniza con éste, y cualquier cambio que se realiza en el servidor maestro se propaga al esclavo.
• Resolución directa: es la resolución que permite obtener una dirección ip a partir de un nombre.
• Resolución inversa: es la resolución que permite obtener el nombre a partir de una dirección ip.
• Vista: es la perspectiva desde la que un cliente ve un servidor DNS, la cual habitualmente depende de la ip que tenga dicho cliente. Esta diferente perspectiva se traduce en que el servidor podrá resolver de diferente forma los nombres. Por ejemplo, supóngase un servidor que da servicio tanto a una red interna como a internet. Para los mismos nombres de máquina los clientes situados en internet deberán obtener direcciones públicas (o la dirección pública, si sólo se dispone de una), mientras que los clientes internos podrán obtener direcciones privadas.
• Consulta recursiva: es aquella que realiza un servidor DNS, cuando al no conocer la respuesta a una petición, procura averiguarla consultándole a su vez, a otro servidor.

Instalación del servidor dns

El servidor DNS más conocido es BIND, que fue totalmente rescrito para la última versión oficial, la versión 9. La instalación en debian es análoga a la de cualquier otro paquete:

$ aptitude install bind9

La orden instalará el servidor, que como tiene incluido en su configuración los servidores raíz, ya es capaz de resolver dominios. Para comprobarlo, basta con usar el comando dig:

$ dig @localhost www.iescastillodeluna.tk

Se ha incluido @locahost, porque probablemente no se haya cambiado aún /etc/resolv.conf para que la máquina use nuestro propio servidor:

# echo nameserver 127.0.0.1 > /etc/resolv.conf

Aunque quizás también hubiéramos querido definiir domain y search en este fichero.

Enjaulamiento

El servicio dns es tristemente célebre por sus repetidos... problemas de seguridad. Por ello es muy recomendable enjaular el servicio dentro de un directorio que llamaremos /var/lib/chroot-dns.

Paremos el servicio para hacer los cambios:

# invoke-rc.d bind9 stop

Antes de empezar, no obstante, es también recomendable, evitar que el posible atacante conozca la versión de nuestro servidor. Para ello en named.conf.options puede añadirse:

version "3.1416";

o cualquier otro número de versión absurdo.

Procedamos ahora a enjaular. Lo primero es crear los directorios necesarios:

# mkdir -p /var/lib/chroot-dns/{etc,dev,var/{cache,run}}

Dentro de dev, necesitamos tener ficheros especiales null y random:

# mknod /var/lib/chroot-dns/dev/null c 1 3
# mknod /var/lib/chroot-dns/dev/random c 1 8
# chmod 666 /var/lib/chroot-dns/dev/*

Pasamos /etc/bind a su nueva ubicación:

# mv /etc/bind /var/lib/chroot-dns/etc
# ln -s /var/lib/chroot-dns/etc/bind /etc

Otro tanto hacemos con /var/cache/bind:

# mv /var/cache/bind /var/lib/chroot-dns/var/cache
# ln -s /var/lib/chroot-dns/var/cache/bind /var/cache

Y con /var/run/named:

# mv /var/run/named /var/lib/chroot-dns/var/run
# ln -s /var/lib/chroot-dns/var/run/named /var/run

Asignamos ahora permisos:

chown -R bind:bind /var/lib/chroot-dns/*

Y cambiamos el servicio de log:

# echo '$AddUnixListenSocket /var/lib/chroot-dns/dev/log' > /etc/rsyslog.d/dns-chroot.conf
# invoke-rc.d rsyslog restart

Listo. Ahora indiquémosle a bind, cuál es el directorio en que se hallará enjaulado. Para ello ha de editarse el fichero /etc/default/bind y dejar una línea del siguiente modo:

OPTIONS="-u bind -t /var/lib/chroot-dns"

Reiniciemos el servicio:

# invoke-rc.d bind9 start

Si el sistema es gestionado por systemd (caso de jessie) necesita añadir el parámetro -f a las opciones.

En el momento de revisar estos apuntes, existe en jessie un bug que hace que systemd no atienda a la configuración del anterior fichero. con lo que el cambio no entrá efecto. Por tanto, es muy conveniente que compruebe con qué parámetros se ejecutó bind9 (si no cargan los parámetros especificados, lea con atención el enlace: en él se explica cómo arreglarlo):

# invoke-rc.d bind9 status

Casos de estudio

Basaremos todas nuestras configuraciones en esta red:

La red, cuando se complete la configuración más compleja, debería funcionar del siguiente modo:

1. El servidor principal resuelve el dominio iescdl.tk como maestro y tiene definidas tres vistas distintas:
   • La que se ve desde internet.
   • La que ven las redes 172.22.0.0/24 y 192.168.10.0/24, y el propio servidor.
   • La que ven las redes 172.31.0.0/24 y 192.168.20.0/25.
   Además también es servidor esclavo del subdominio frances.iescdl.tk y maestro de ingles.iescdl.tk.
2. El servidor de la primera intranet será servidor esclavo de los subdominios frances.iescdl.tk e iescdl.tk.
3. El servidor de la segunda intranet será el servidor maestro del subdominio ingles.iescdl.tk y servidor esclavo de iescdl.tk.
4. En el servidor principal hay también un servidor dhcp que se encarga de servir direcciones a las dos redes internas. Además se habilita la asignación dinámica de nombres, de modo que al asignarse una dirección se le otorgue un nombre a la nueva máquina.

Obviamente esta configuración planteada no es la más lógica: sería más recomendable hacer una configuración simétrica en la que los dos servidores internos fueran servidor maestros de sus respectivas subredes o bien en la que ambos fueran los servidores esclavos. No se hace, simplemente, para abarcar más circunstancias y poder analizar más casos.

Cómo resolver directamente el problema es enormemente complejo y, por tanto, escasamente didáctico. Por ello, nuestro modus operandi consistirá en no considerar partes de las red ni redundancias del servicio e irlas añadiendo paulatinamente. Esto obligará no sólo a crear nuevos ficheros de configuración, sino a enmendar algunos ya escritos.

El plan de estudio será el siguiente:

1. Configuración básica: solo consideraremos la red 172.22.0.0/16 y el dominio iescdl.tk, para el cual sólo existirá un servidor maestro en el servidor princial
2. Configuración con subdominios: añadiremos las redes 192.168.10.0/24 y 192.168.20.0/25, de manera que para la primera red el servidor maestro sea el principal; y para la segunda, el servidor interno.
3. Configuración con resolución inversa en redes sin clase: para la red 192.168.20.0/25, que no es una red pura de clase C, añadimos la resolución inversa, que es más complicada que la resolución de clases puras.
4. Configuración con servidor esclavo: para añadir redundancia haremos que el servidor principal haga de secundario de la red interna 192.168.20.0/25 y el servidor interno de la red 192.168.0.0/24.
5. Configuración con actualizaciones dinámicas: habilitaremos el servidor dhcp para que al conceder direcciones, registre también nombres en el servidor dns.
6. Configuración con vistas: Añadiremos una vista para que los clientes de internet obtengan la ip pública al preguntar por máquinas del dominio iescdl.tk.
7. Configuración con actualizaciones en dos o más vistas: añadiremos la red 172.31.0.0/16 y una tercera vista para ella y para la red 192.168.20.0/25. Esto provocará que las actualizaciones automáticas se tengan que propagar de la vista en la que se realizan a la otra.

Los ficheros de configuración

Toda la configuración de bind9 se encuentra dentro del directorio /etc/bind. El fichero básico de configuración es named.conf. Ese fichero, mediante sentencias include incluye los contenidos de otros dos (named.conf.options y named.conf.local), de manera que por regla general en debian no se habrá de tocar el fichero habitual sino los otros dos.

Esquemáticamente, los ficheros del directorio son:

named.conf,

es realmente el fichero de configuración. debian, sin embargo, delega parte de las configuraciones en otros dos ficheros, que vienen descritos a continuación.

named.conf.options,

es la parte de la configuración que se encarga de algunas opciones. La más importante es la definición de los forwarders. Estos son servidores a los que nuestro servidor DNS consultará las direcciones que no conoce, en vez de hacerlo directamente a los servidores raíz. Si estos servidores no son accesibles, entonces nuestro servidor preguntará a los servidores raiz. Si no se quiere, sin embargo, esto último se puede añadir la directiva:

forward only

named.conf.local,

es el fichero destinado a la definición de nuestras propias zonas. Siempre que se quiera incluir la definición de un dominio propio, habrá que declararla aquí y, después crear un fichero de tipo db.*, donde se desglosen las máquinas.

db.*,

distintos ficheros que definen cada una de los dominios. Por ejemplo, db.local, define la zona para la interfaz de loopback. db.root contiene la resolución de los servidores raíz. También es interesante db.empty, que es un fichero que se puede tomar como plantilla para definir nuestros propios dominios.

Además, el sistema está organizado de modo que se espera que la definición de nuestros dominios (sus ficheros db.*), se incluya dentro de /var/cache/bind.

Configuración inicial

Supongamos que para el dominio iescdl.tk definimos una máquina ns, que será el servidor de nombres, una máquina mail que será el servidor de correo, una máquina www que será el servidor web, una maquina ftp que será el servidor ftp y que coincide con el servidor web, y el router:

zona iescdl.tk

Nombre	IP
ns	172.22.0.2
www	172.22.0.2
ftp	www
mail	172.22.0.2
smtp	mail
pop3	mail
imap	mail
router	172.22.0.1

Lo primero es indicarle a nuestro servidor si usaremos forwarder. Es aconsejable usar alguno, en vez de recurrir a los servidores raíz. Puede escogerse el de nuestro ISP, los de openDNS (208.67.222.222 ó 208.67.220.220) o incluso los de google que son fáciles de recordar (8.8.8.8 ó 8.8.4.4), por ejemplo. Tal cosa se hace descomentando las líneas apropiadas en named.conf.options.

forwarders {
   194.179.1.100;
   8.8.8.8;
   8.8.4.4;
};

Obsérvese que en este fichero hay una línea que dice:

directory "/var/cache/bind";

Es esta línea la que determina que, si no se especifica la ruta de algún fichero, este sea el directorio en el que se busque.

Declaremos ahora las zonas de resolución directa e inversa para el dominio iescdl.tk en named.conf.local:

zone "iescdl.tk" {
   type master;
   file "db.iescdl.tk";
};

zone "22.172.in-addr.arpa" {
   type master;
   file "db.iescdl.tk.rev";
};

Obsérvense las dos declaraciones de zone: la primera sirve para declarar el fichero que definirá la resolución directa de nombres, esto es, la conversión de una ip simbólica a una ip numérica. La segunda sirve para hacer lo contrario: preguntar por el nombre de una ip numérica. La palabra que acompaña a zone no es caprichosa: en el primer caso está claro: el nombre del subdominio; el segundo es algo más enrevesado: consiste en poner los bytes de la parte red en orden inverso (en vez de 172.22, 22.172) y añadir in-addr.arpa. Si la parte de red no son octetos completos entonces la cosa se complica bastante.

Dentro de cada declaración hay dos líneas. La segunda línea es el fichero en que asociaremos nombres a ips. La primera es el tipo (type), que puede ser master, slave o forward. Los dos primeros tipos declaran si el servidor es maestro o esclavo En esta configuración, sin embargo, sólo estamos configurando un maestro, así que es tipo es master. forward indica que para un determinado dominio se usará un servidor dns de apoyo. Por ejemplo:

zone "google.es" {
   type forward;
   forwarders {};
}

Si incluyésemos esto, el subdominio google.es se resolvería recurriendo directamente a los servidores raíz, ya que la lista de forwarders se dejó vacía.

Volvamos a nuestra configuración. Queda, por último, escribir los ficheros db.iescdl.tk y db.22.172. Para ello lo mejor es copiar db.empty y no empezar de cero:

# cd /var/cache/bind
# cp /etc/bind/db.empty db.iescdl.tk
# cp /etc/bind/db.empty db.22.172

Estos ficheros de definición de zonas se construyen incluyendo registros, así que antes de continuar con la configuración es necesario conocer qué tipos de registros pueden escribirse.

Registros y tipos de registros

Dentro de los ficheros db.* se incluyen las definiciones de las distintas zonas. Para ello se usan registros que tienen la siguiente forma:

<nombre_registro> [<TTL>] IN <tipo_de_registro> <valor_registro>

TTL, que es accesorio, es el tiempo en segundos de vigencia del nombre. Es accesorio, porque existe unha directiva global (también llamda TTL) que permite hacer una definición que se aplique a todos los registros.

En los servidores DNS hay distintos tipos de registros que cumplen distintas funciones, y los valores de nombre_registro y valor_registro depende de qué tipo de registro se esté definiendo.

SOA

En todo fichero de definición de zona hay un registro SOA, que sirve definir algunos aspectos de la propia zona y del resto de registros de la zona. Un registro SOA típico tiene el siguiente aspecto:

@   IN    SOA   localhost.  root.localhost. (
                       1   ; Serial
                  604800   ; Refresh
                   86400   ; Retry
                 2419200   ; Expire
                   86400 ) ; Negative Cache TTL

Obsérvese antes de nada que el nombre de registro es @. Este símbolo significa, simplemente, esta zona o este dominio. Si intentasemos pasar a lenguaje natural este trozo de código podríamos decir: el registro SOA para este dominio tiene el valor ... o una cosa parecida.

En cuanto al valor de registro, lo primero es la máquina que mantiene el archivo, lo segundo el correo electrónico de la persona encargada de mantenerlo (la @ está sustituida por un punto (.). El resto de parámetros son interesantes:

• La versión del fichero: cada vez que hay un cambio en este fichero el valor se incrementa en uno.
• El tiempo de de actualización, que es el tiempo en segundos que pasa hasta que un servidor esclavo vuelve a pedir una transferencia completa de la zona.
• El tiempo de reintento, que es el tiempo en segundos que espera un servidor esclavo para volver a pedir una transferencia de zona, en caso de que fallase el anterior intento.
• El tiempo de expiración, que es el tiempo en segundos que un servidor secundario considerará su propia información como fiable si no ha logrado volver a transferir los datos de zona del servidor primario. Tras este tiempo, el servidor secundario dejará de resolver los nombres del dominio.
• El tiempo de vida, que es el tiempo en segundos que los servidores DNS deben considerar como válida la información del resto de registros. Por ejemplo, la información de un registro A que indica cuál es el nombre asociado a una ip. Durante este tiempo, estos servidores podrán mantener en su caché el dato sin tener que volverlo a preguntar al servidor autoritativo. Hay una directiva $TTL que permite alterar este valor.

A

Es el tipo de registro que indica cuál es el nombre de una dirección ip. Así por ejemplo, si la máquina www tiene la ip 172.22.0.2, el registro quedará así:

www            IN     A      192.168.20.31

Hay que hacer notar algo al respecto. Obsérvese que se ha incluido el nombre de la máquina, pero no el dominio. Esto es debido a que los registros aparecen dentro de los fichero db.* que ya se citaron y cada uno de estos ficheros desarrolla un dominio. Cuando el nombre no acaba con un punto, el software añade el dominio que se esté definiendo con el fichero. Si el fichero definía el dominio iescdl.tk entonces el registro anterior es equivalente a este otro:

www.iescdl.tk. IN     A      192.168.20.31

Es posible resolver un mismo nombre a dos direcciones ips distintas:

www     IN     A      192.168.20.31
               A      192.168.20.32

En este caso, el comportamiento habitual del servidor es devolver ambas resoluciones, pero cambiar alternativamente el orden en que se devuelven. Habitualmente, los clientes intentan la primera resolución y, si esta falla, intentan la segunda. El propósito de ir alterando el orden es balancear la carga entre ambas máquinas.

Existe una directiva $ORIGIN que permite cambiar el dominio de referencia dentro de estos ficheros. Ya se verá más adelante.

Los registros (estos de tipo A y los que se explicarán a continuación) tienen de modo predeterminado la vigencia que se hubiera indicado en el registro SOA (el campo TTL que se incluyó en último lugar). También es posible indicaresto mediante una directiva:

$TTL 86400

Sin embargo, es posible indicar un tiempo TTL particular para un registro, incluyendo el valor antes de la palabra IN:

www     300     IN     A      192.168.20.31

Indicar particularmente el TTL de un registro es aplicable al resto de tipos que se explican a continuación.

NS

Es el registro que define cuál es el servidor de nombres para el dominio que se espefique en el nombre de registro. Por ejemplo:

iescdl.tk.      IN      NS    ns

significa que la máquina ns.iescdl.tk (se ha puesto sólo ns, pero no se ha acabado en un punto el nombre) gestiona el dominio iescdl.tk (ojo con . final porque de lo contrario sería el dominio iescdl.tk.iescdl.tk). Como cuando nos queremos referir al propio dominio, se puede poner una @, la sentencia anterior podría ser simplemente:

@              IN      NS    ns

Por supuesto, esto no está del todo completo ya que ¿quién es la máquina ns.iescdl.tk? Así que a la línea anterior habría que añadir un registro de tipo A que lo indique:

ns             IN      A     172.22.0.2

Por tanto, para definir la máquina que hace de servidor de dominio necesitamos dos líneas:

@              IN      NS    ns
ns             IN      A     172.22.0.2

MX

Son los registros que indican cuál es el servidor de correo, es decir, los que indican a qué máquina deben ir dirigidos los correos de la forma xxx@iescdl.tk. Obsérvese que en la dirección de correo sólo se expresa el dominio, así que cuando un servidor de correo tiene que buscar al servidor de correo destino, no puede basarse exclusivamente en la dirección de correo: necesita consultar con dns cuál es la máquina que se encarga de la labor. Los registros se escriben así:

@              IN      MX    10 mail

Esto siginifica que el servidor de correo de este dominio (@) es la máquina llamada mail (o sea, mail.iescdl.tk). El extraño 10 indica la prioridad del servidor de correo, ya que para un mismo dominio puede haber definidos varios. Cuanto menor sea el número, mayor será la prioridad. Como en el caso anterior, la definición no está completa, porque no se conoce cuál es la ip Por ello se necesita un registro A que complemente a este:

mail           IN      A     172.22.0.2

Obsérvese que si en un dominio definimos un servidor de correo tendremos dos registros así:

@              IN      NS    ns
@              IN      MX    10 mail

En estos casos, podemos ahorrarnos la parte común y escribir simplemente:

@              IN      NS    ns
                       MX    10 mail

CNAME

Son registros que permiten dar un nombre alternativo a una máquina. Por ejemplo, si la máquina mail queremos que también se llame smtp podemos hacer:

smtp            IN     CNAME  mail

PTR

Son registro que hacen lo contrario que A, o sea, asociar ip numéricas a nombres de equipos:

2.0              IN     PTR    ns.iescdl.tk.

Obviamente no aparecerá ningun registro de este tipo en el fichero db.iescdl.tk, sino en db.iescdl.tk.rev

TXT

Son registros que nos permiten, simplemente, incluir información adicional sobre el propio registro. En muchas ocasiones se utlizan para identificar al propietario del registro.

@              IN      TXT   "Dominio IESCDL.TK"
                       NS    ns
                       MX    10 mail

SRV

Los registros SRV (abreviatura de SeRVice) sirven para declarar qué máquinas del dominio contienen determinados servicios y, además, establecer una preferencia para el caso en que varias máquinas ofrezcan un mismo servicio (esto último, sería una generalización de la prefeencia que permite establecer el registro MX para servidores de correo).

Tienen un aspecto algo más complicado que los vistos hasta ahora. Veámoslo con un ejemplo para el protocolo http:

_http._tcp.www   IN   SRV  0   2   80     www
                      SRV  0   1   80     www2
                      SRV  1   1   8080   w3

En estas líneas, _http._tcp.www viene a decir: cuando pidamos una página web (o sea protocolo de capa de aplicación http de la capa de transporte tcp) a la dirección www.iescdl.tk, dicho servicio se ofrecerá a través de tres máquinas www.iescdl.tk, www2.iescdl.tk y w3.iescdl.tk. Los número que acompañan a cada máquina indican la prioridad (cuando más pequeña, más prioritaria), el peso y el puerto de escucha. En el ejemplo, el servicio lo ofrecerán siempre www.iescdl.tk y www2.iescdl.tk por elpuerto 80, puesto que son más prioritarias, y sólo en caso de que ambas sean inaccesibles, se ofrecerá a través de w3.iescdl.tk por elpuerto 8080. Además, el peso de www.iescdl.tk es el doble de el de www2.iescdl.tk, por lo que dos de cada tres veces la petición debería ser resuelta como www.iescdl.tk.

Por supuesto, es necesario tener registros de tipo A que indiquen cuáles son las direcciones ip de www.iescdl.tk, www2.iescdl.tk y w3.iescdl.tk.

Desgraciadamente estos registros no son consultados por todos los servicios (de hecho, el servicio web no está entre ellos). Para más información consúltese esto.

Definición de las zonas

Volvamos a los ficheros de definición de zona. Teniendo en cuenta cómo se escribían los registros, el fichero para la resolución directa puede dejarse así:

Obsérvese la última línea:

*              IN      CNAME www

Esta línea permite que cualquier nombre de máquina que no se haya definido, en vez devolver un error, resuelva a la máquina www, que es la que previsiblemente tiene el servidor web.

La resolución inversa, por su parte, puede hacerse así:

Recuérdese que la zona es 22.172.in-addr.arpa, así que al escribir los registros debe incluirse lo que falta para completar la dirección: 2.0 y 1.0 (recuérdese que deben escribirse al revés). Aunque hay varios nombres que responden a la dirección 172.22.0.2 al hacer la resolución inversa es recomendable que sólo se indique uno.

Comprobación de los ficheros

Antes de levantar el servidor (o si lo hemos levantado y no funciona) es útil comprobar si tenemos erratas en los ficheros que hemos escrito. Para ello existen dos utilidades: named-checkconf y named-checkzone. Se usan del siguiente modo:

# named-checkconf /etc/bind/named.options.local
# named-checkzone castillo /var/cache/bind/db.iescdl.tk

Para usar el primero no hay más que indicar cuál es el fichero de configuración que se quiere probar. Para el segundo, hay que incluir como primer parámetro el dominio que define el fichero de zona.

El comando rdnc

rndc permite realizar algunas acciones interesantes. Por ejemplo, si se quiere borrar la caché basta con:

# rndc flush

Si se hace:

# rndc dumpdb  -cache

Lograremos volcar la caché en el fichero named_dump.db dentro de /var/cache/bind. En este fichero puede abservarse, por ejemplo, el tiempo que aún resta antes de que un determinado nombre vuelva a resolverse usando un dns externo. Obviamente este tiempo en la resta del TTL de registro y el tiempo que ha trascurrido desde que se realizó la consulta.

Por último,

# rndc reload

permite recargar los ficheros de zona sin reiniciar el servidor. Puede especificarse también una zona en particular:

# rndc reload iescdl.tk

También puede especificarse la vista de la que se recargara la zona:

# rndc reload iescdl.tk in vista-particular

Configuración del dominio de primer nivel

En la declaración de zonas hay que introducir algunos cambios:

zone "iescdl.tk" {
   type master;
   file "db.iescdl.tk";
   forwarders {};
};

zone "22.172.in-addr.arpa" {
   type master;
   file "db.iescdl.tk.rev";
};

zone "frances.iescdl.tk" {
   type master;
   file "db.frances.iescdl.tk";
};

zone "10.168.192.in-addr.arpa" {
   type master;
   file "db.frances.iescdl.tk.rev";
}

Obsérvese que para el dominio iescdl.tk, se han eliminado los forwarders, incluyendo una lista de forwarders vacía. En otro caso, no se podrá hacer la resolución del dominio de segundo nivel ingles.iescdl.tk, porque al no estar gestionada aquí, se intentaría resolver acudiendo a los servidores externos. Se nota en este fichero la ausencia del dominio inglés, pero esto es debido a que no es gestionado aquí, sino delegado gracias al fichero de definición de la zona iescdl.tk.

En cuanto a los ficheros de definición de zonas, habría que escribir db.iescdl.tk, db.iescdl.tk.rev, db.frances.iescdl.tk y db.frances.iescdl.tk.rev. Todos los ficheros se escriben de modo semejante a como se hizo en el apartado anterior, excepto db.iescdl.tk que tiene que delegar inglés en uno de los servidors internos. Esta delegación se logra incluyendo estal líneas:

ingles     IN      NS     ns.ingles
ns.ingles  IN      A      192.168.20.2

Esto indica que ns.ingles.iescdl.tk es el servidor de nombres del subdominio ingles.iescdl.tk y que dicha máquina tiene la ip 192.168.20.2. Obsérvese que, como nuestro dominio es iescdl.tk, éste se añade automáticamente al no incluirse un punto final. Ahora bien, existe la directiva $ORIGIN, que permite modificar el dominio de referencia, así que lo de arriba también puede escribirse así:

$ORIGIN ingles.iescdl.tk.
@     IN      NS     ns
ns    IN      A      192.168.20.2

Si hubiera más delegaciones de subdominios, habría que repetir esto más veces. Haciendo estos cambios el fichero queda así:

Se ha añadido una delegación también para francés, aunque estrictamente no es necesario.

Configuración de los dominios de segundo nivel

La definición de los dominios de segundo nivel ha de hacerse la de frances en el propio servidor principal y la de inglés en el servidor interno de esta red. Se definen exactamente igual que se hizo para definir un dominio simple. Eso sí, en los servidores internos de francés e inglés habrá que forzar a que, cuando no sepa resolver, se recurra al servidor principal: así serán capaces de resolver cualquier máquina de los dominios iescdl.tk, frances.iescdl.tk e ingles.iescdl.tk. Por tanto, en el named.conf.options del servidor de inglés habría que escribir:

forwarders {
   192.168.20.1;
};

Y otro tanto parecido (pero 192.168.10.1) en el de francés. Además, en ambos servidores de segundo nivel se debería fijar dnssec-validation a no:

dnssec-validation no;

Investigar la validación...

Obsérvese que, si francés se hubiera delegado y no se definiera en el propio servidor principal, inglés seguiría siendo capaz de resolver los otros dos dominios, puesto que el servidor principal, aunque no gestionara francés, sí sabría como resolverlo.

Los ficheros que permiten esta configuración pueden descargarse de aquí.

Configuración del servidor DNS

La primera de las adiciones es la generación y definición de una clave que servirá para impedir que cualquiera pueda añadir registros indiscriminadamente. La generación puede hacerse con dnssec:

# dnssec-keygen -r /dev/urandom -a hmac-md5 -b 256 -n HOST rnc-key

...que generará un fichero K*.key que contendrá el valor de la clave generada. Este valor habría que copiarlo en un fichero, pero debian ya provee de un fichero adecuado con una clave que puede usarse (no obstante, puede generarse la clave y sustituir la clave generada de debian por la generada por nosotros):

# cat /etc/bind/rnc.key
key "rndc-key" {
        algorithm hmac-md5;
        secret "JY58MD+sP4FymdhgP1HoNw==";
};

Esta clave servirá para validar al cliente que intente realizar un actualización de registros en el servidor dns. En este caso concreto, el cliente será siempre el servidor dhcp del servidor principal; en cambio, el servidor dns no siempre es el mismo: cuando se añada una resolución de francés, el servidor será el principal, pero cuando se añada una de inglés el servidor será el interno que corre en dicha red. Por ello, lo más sencillo es tomar este misma clave y migrar al servidor de inglés, sobreescribiendo la que haya en él:

# scp /etc/bind/rndc.key root@192.168.20.2:/etc/bind/rndc.key

A continuación habrá que incluir la clave en la configuración del servidor y permitir actualizaciones automáticas. Esto debemos hacerlo tante en el servidor principal como en el de inglés. En el principal, debe añadirse lo siguiente al fichero named.conf:

include "/etc/bind/rndc.key";
controls {
   inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};

La sentencia controls indica que se aceptarán conexiones sólo por la interfaz de loopback (inet), sólo para la máquina localhost y con la clave rndc-key: todo congruente con que sea el servidor dhcp de la propia máquina el que se encarga de pasar los nuevos nombres. Por otro lado, en la declaración de zonas (named.conf.local) debe incluirse la sentencia apropiada para permitir la actualización:

zone "frances.iescdl.tk" {
   type master;
   file "db.frances.iescdl.tk";
   also-notify { 192.168.10.2; };
   update-policy { grant "rndc-key" zonesub any; };
};

zone "10.168.192.in-addr.arpa" {
   type master;
   file "db.frances.iescdl.tk";
   also-notify { 192.168.10.2; };
   update-policy { grant "rndc-key" zonesub any; };
};

Con esto debería bastar para tener lista la actualización dinámica en el dominio frances.iescdl.tk, porque en el servidor esclavo, no es necesario cambiar nada. Ahora debe pasarse a hacer lo análogo en el servidor de inglés. A su named.conf hay que añadir:

include "/etc/bind/rndc.key";

acl rndc-users {
   192.168.20.1;
};

controls {
   inet 192.168.20.2 allow { rndc-users; } keys { "rndc-key"; };
};

Recuérdese que en este caso las actualizaciones se recibirán del servidor principal (192.168.20.1). Las declaraciones de zona deberían quedar así:

zone "ingles.iescdl.tk" {
   type master;
   file "db.ingles.iescdl.tk";
   also-notify { 192.168.20.1; };
   update-policy { grant "rndc-key" zonesub any; };
};

zone "20.168.192.in-addr.arpa" {
   type master;
   file "db.super-ingles.iescdl.tk.rev";
   also-notify { 192.168.20.1; };
};

zone "20.168.192.subnet0-25.in-addr.arpa" {
   type master;
   file "db.ingles.iescdl.tk.rev";
   also-notify { 192.168.20.1; };
   update-policy { grant "rndc-key" zonesub any; };
};

La zona 20.168.192.in-addr.arpa no recibirá actualizaciones puesto que simplemente tiene la cláusula GENERATE que remite a la zona 20.168.192.subnet0-25.in-addr.arpa.

Antes de configurar el servidor dhcp, es útil realizar una prueba manual para ver si se realiza la actualización:

root@servidorprincipal:~# cat | nsupdate -k /etc/bind/rndc.key
server ns.iescdl.tk
zone 10.168.192.in-addr.arpa
update add 100.10.168.192.in-addr.arpa. 86400 IN PTR fantasma.frances.iescdl.tk.
send
zone frances.iescdl.tk
update add fantasma.frances.iescdl.tk. 86400 IN A 192.168.10.100
send

Hecho esto, nuestra máquina debería ser capaz de resolver fantasma.frances.iescdl.tk. En principio, debería haberse añadido un registro al fichero db.frances.iescdl.tk y otro a db.192.168.10, pero puede ocurrir que en vez de eso se hallan creado ficheros .jnl, que son ficheros temporales y que en algún momento volcarán la información en el fichero correspondiente. Si queremos forzar a que esto ocurra podemos hacer:

# rndc freeze
# rndc unfreeze

Las dos órdenes en realidad suspenden las actualizaciones y las vuelven a reiniciar, pero el efecto secundario es que se escriben los cambios en el db.* correspondiente.

Para comprobar si el dominio inglés se actualiza automáticamente, conviene realizar una prueba similar. Adviértase que la prueba, en este caso, también tiene que hacerse en el servidor principal.

Configuración del servidor DHCP

Démosle una vuelta de tuerca a lo anterior: en vez de actualizar manualmente el dns, vamos a hacer que automáticamente un servidor dhcp vaya añadiendo los nombres de máquina al dominio, según conceda ips. Las estrategias pueden ser tres:

• Que el nombre de máquina se fije en el fichero de configuración dhcpd.conf para una mac determinada.
• Que el propio cliente indique cuál es el nombre que quiere que se le adjudique.
• Que el servidor dhcp genere automáticamente nombres para las máquinas que se unen a la red.

Con estas ideas se puede escribir el siguiente fichero dhcpd.conf:

El fichero contiene las explicaciones pertinentes, pero es aconsejable remarcar algunos aspectos:

• El nombre que obtendrá la máquina lo determina la cláusula ddns-hostname. En este fichero se usa primero la opción host-name, y si no, un nombre generado automáticamente a partir de la dirección ip asignada (la opción comentada es para usar la dirección MAC). La opción host-name nunca se fija en este fichero, porque se espera que los clientes la fijen en su fichero /etc/dhcp/dhclient.conf:

  send option host-name "este-nombre-quiero";

  No obstante, para las máquinas conocidas que tienen un nombre (pagano y bautizado), ddns-hostname se redefine para que se les asigne ese mismo nombre.
• La cláusula:

  primary 127.0.0.1

  indica al dhcp cuál es el servidor maestro dns al que comunicará las nombres. Este, a su vez, comunicará estas actualizaciones a los esclavos.
• La opción:

  option domain-search        "frances.iescdl.tk", "iescdl.tk";

  permite pasar al cliente dos dominios de búsqueda: de este modo, si se indica un nombre de máquina sin dominio, si no es de la zona frances.iescdl.tk, se intentará hallar iescdl.tk.
• El valor de la cláusula ddnds-rev-domainname es lo que se añade a la dirección ip puesta al revés para apuntar el registro PTR. Cuando se trata de una red pura (caso de frances.iescdl.tk) su valor basta con que sea in-addr.arpa, ya que para poder obtener, por ejemplo, la resolución de 192.168.10.100 necesitamos apuntar el registro 100.10.168.192.in-addr.arpa. Sin embargo, esto no es así para las redes no puras. Recordemos que tal y como hicimos esta resolución inversa necesitamos registros de la forma 100.20.168.192.subnet0-25.in-addr.arpa. Así pues, el valor de la cláusula en este caso será subnet0-25.in-addr.arpa. Esta es la razón por la que optamos por esta notación: la dirección ip completa en orden inverso siempre tiene que aparecer a la izquierda.
• El nombre que obtiene la máquina no es excesivamente bonito: la máquina con ip 192.168.10.100 tendría como nombre host-192-168-10-100.frances.iescdl.tk. Puede complicarse un poco la sentencia para que quede mejor. Por ejemplo:

  option name  code 1234 = string;
  option name "pc";
  ddns-hostname = concat(config-option name,binary-to-ascii(10,8, "-", reverse(1,suffix(leased-address,2))));

  Esto permitiría obtener un nombre del tipo pc100-10.frances.iescdl.tk.