INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Pruebas con el servidor DNS.

Los apartados siguientes se realizan sobre la máquina virtual de Ubuntu Server 15.04 64 bits creada
en el tema anterior. Antes de empezar con la instalación y las pruebas del servicio DNS necesitamos
instalar otras aplicaciones. Estas instalaciones se detallan en los siguientes puntos.

Instalando un navegador web en nuestro servidor.

A pesar de que en el entorno gráfico tenemos un icono para Internet en el escritorio no hay ningún
navegador instalado. Podemos instalar el Firefox con el comando:
$ sudo apt-get install Firefox

También podemos optar por instalar otro navegador como el midori (es el que he instalado yo). Este
tiene la ventaja de ser un navegador rápido y ligero. Midori es un navegador de código abierto muy
ligero y que cumple perfectamente su función: navegar por Internet. Tiene un campo de texto para
poner la URL y otro para hacer una búsqueda en Google, por ejemplo. Se puede cambiar por Duck
Duck Go u otro que esté disponible en su lista. Por supuesto, soporta HTML5 y CSS3.
Para instalarlo hay que ejecutar los siguientes comandos:
$ sudo add-apt-repository ppa:midori/ppa
$ sudo apt-get update
$ sudo apt-get install midori

En el caso del midori además fue necesario cerrar la sesión y volver a entrar para que funcionara.
Podemos abrir ahora el navegador web desde el botón del escritorio.

Imagen 1: Navegador Midori funcionando en nuestro server.

1
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Instalando el servidor web Apache.

Para hacer las pruebas del servidor DNS vamos a instalar además un servidor web. De esta forma
podremos probar fácilmente que el servidor DNS funciona (más adelante están explicadas las
pruebas que realizaremos.
Para instalar el apache simplemente hay que ejecutar el comando:
$ sudo apt-get install apache2

Para comprobar la instalación en la barra de direcciones del navegador escribimos "localhost" y nos
abrirá una ventana como la de la siguiente imagen:

Imagen 2: Página por defecto del servidor web Apache 2.

Como nos dice en la misma página por defecto, esta página esta localizada en
"/var/www/html/index.html". Podemos modificar esta página para cambiarle el aspecto y
personalizarla.

Imagen 3: Página por defecto del apache modificada. Podéis modificar el archivo
/var/www/html/index.html o substituilo por otro nuevo. Los usaremos en las pruebas para
distinguir los distintos servidores que hemos instalado.

2
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Cambiando el nombre del servidor.

Todos nuestros servidores tienen el mismo nombre. Para cambiar el nombre del servidor tenemos
que editar el archivo /etc/hostname. Allí sustituiremos el nombre que hay por otro. Como vamos a
tener varios servidores en funcionamiento en la misma aula, les cambiaremos el nombre a server-
nombre, cambiando nombre por el vuestro. En mi caso el nombre de mi servidor es server-joan.

Imagen 4: Contenido del archivo /etc/hostname después de modificarlo.

Se puede comprobar el cambio con el comando hostname, pero os encontrareis con que el nombre
no ha cambiado, al menos aún. Es necesario reiniciar el servidor para que tengan efecto los
cambios.
Como a veces es complicado o al menos no conveniente reiniciar un servidor, podemos hacer que
los cambios tengan efecto con el comando hostname seguido del nombre que hemos usado para
nuestro server.
$ sudo localhost server-joan

Una vez realizado el cambio podéis comprobar que funciona escribiendo en la barra de direcciones
del navegador server-joan y realizara el mismo efecto que usar localhost.

Modificando el archivo hosts.

El archivo hosts de un ordenador es usado por el sistema operativo para guardar la correspondencia
entre dominios de Internet y direcciones IP. Este es uno de los diferentes métodos que usa el sistema
operativo para resolver nombres de dominios. Antiguamente cuando no había servidores DNS que
resolvieran los dominios, el archivo hosts era el único encargado de hacerlo, pero dejó de utilizarse
cuando Internet empezó a crecer en nombres de dominio, pasando a usar servidores de resolución
de DNS.
En Linux se encuentra en /etc/hosts y en Windows en C:\Windows\System32\drivers\etc\hosts. El
archivo /etc/hosts contiene una lista de los hosts conocidos por el equipo y su correspondiente IP.
Por defecto, solo suele incluir la definición de localhost para pruebas de loopback, aunque en
Ubuntu también incluye una línea relacionando el nombre de host con la dirección 127.0.1.1.

Imagen 5: Contenido del archivo /etc/hosts

Un problema que he encontrado es que si cambias el nombre del equipo, no se actualiza el archivo
hosts. Así que hay que modificarlo a mano. Podemos incluir cualquier alias para el equipo usando
una dirección de loopback (cualquiera en la red 127.0.0.0/8) o la IP del equipo, aunque esta última
opción solo es recomendable si tenemos una IP fija.

3
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Los equipos añadidos al archivo hosts tiene prioridad sobre las búsquedas a servidores DNS, por lo
que estas direcciones se resuelven de forma local. Algunas de las utilidades de incluir equipos en
hosts son acelerar el acceso a un equipo concreto, acceder de forma local a un equipo cuando se
usan DNS dinámicos (p.e. no-ip), añadir alias a equipos como impresoras o servidores en redes
pequeñas o evitar los accesos a un equipo desviándolos a otro.

Instalación de BIND9.
El siguiente paso es instalar el servidor DNS en nuestro sistema:
$ sudo apt-get install bind9

Una vez instalado BIND9, sería recomendable instalar también BIND9-DOC que nos aportará la
documentación referente a este software. Para ello ejecutaremos:

$ sudo apt-get install bind9-doc

Con todo esto ya disponemos de un servidor DNS instalado en nuestro sistema. Ahora nos falta
configurarlo.

Configurando el servidor DNS BIND9

Los ficheros de configuración de bind están guardados en /etc/bind/
El principal archivo de configuración es named.conf. Este archivo hace referencia al resto de
archivos de configuración y no se suele modificar. Su contenido por defecto es el que se ve en la
siguiente imagen.

Imagen 6: Contenido del archivo named.conf. Contiene enlaces a otros

archivos de configuración del servidor DNS bind.

Fijaos en que en este archivo simplemente hay enlaces a otros archivos donde estará el resto de
la configuración del servidor DNS.

Escenarios de configuración BIND9

Antes de empezar a configurar el servidor DNS tenemos que saber para que vamos a utilizarlo.
Bind puede proporcionar diferentes servicios DNS. Algunas de las configuraciones más útiles son:
• Servidor caché: En esta configuración BIND9 buscará la respuesta a las consultas de
nombres y recordará la respuesta para las próximas consultas. Esto puede ser útil para
una conexión a Internet lenta. Al almacenar en caché las consultas DNS, se reducirá el
ancho de banda y (más importante) la latencia (tiempo en recibir respuesta)

4
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

• Primary Master Server o Servidor Primario Maestro. BIND9 puede ser utilizado para
almacenar y servir registros DNS (los grupos de registros se denominan zonas) para un
nombre de dominio registrado o uno inventado (estos último sólo se podrán usar en una
red restringida).
• Secondary Master Server o Servidor Secundario Maestro. Un servidor DNS secundario
se utiliza para complementar un servidor DNS maestro primario sirviendo una copia de la
zona o zonas configuradas en el servidor primario. Los servidores secundarios se
recomiendan en las configuraciones más grandes. Si tiene la intención de servir un nombre
de dominio registrado, de esta forma se asegura de que la zona DNS está disponible
incluso si el servidor principal no está en línea.
• Híbridos. Se puede configurar BIND9 para usar como caché y al mismo tiempo como
servidor primario maestro, caché y servidor maestro secundario o incluso caché, Primary
Master (de una o varias zonas) y servidor secundario (de otras zonas). Todo lo que se
requiere es simplemente la combinación de los diferentes ejemplos de configuración.

Configuración de un DNS caché

La configuración por defecto de bind es la de funcionar como servidor caché. Todo lo que se
requiere en este caso es añadir los servidores DNS de nuestro ISP (Internet Service Provider) o usar
servidores públicos como los de Google.
Simplemente hay que eliminar el comentario e introducir las direcciones de los servidores DNS en
el archivo /etc/bind/named.conf.options:
/etc/bind/named.conf.options
[...]

forwarders {
1.2.3.4;
5.6.7.8;
};

[...]
Donde 1.2.3.4 y 5.6.7.8 son las direcciones IP de los servidores DNS de nuestro ISP.
Esta es la configuración que suelen llevar todos los routers ADSL.

6
4
3
2

1 5

Imagen 7: Esquema funcionamiento de un servidor DNS caché

5
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

En la imagen anterior el router ADSL está configurado como DNS caché (como se ha comentado es
la configuración que tienen por defecto). Cuando un equipo intenta acceder a la dirección
www.empresa.com le pregunta al servidor DNS (el router) cual es la IP correspondiente (1), si el
servidor no la conoce se la pregunta al servidor del ISP (2), si este tampoco la conoce se conectará a
otros servidores DNS para obtener la dirección (3). Una vez obtenida la dirección IP de
www.empresa.com se devuelve al servidor DNS del ISP (4), este seguramente guardará la dirección
por si hay nuevas peticiones de algún otro cliente y la devuelve al router (5), este la almacena en su
memoria y la pasa al equipo que la ha pedido (6).
Las nuevas peticiones de cualquier equipo de la red a esa dirección se devuelven directamente. La
petición se almacena durante el tiempo TTL indicado en el registro SOA del servidor maestro que
gestiona la zona empresa.com.
PRÁCTICA 1:
Esta práctica y las siguientes se pueden realizar de forma individual o por grupos de 2 o 3
personas.
Paso 1:
Configura la máquina virtual del servidor para que funcione como servidor DNS caché
usando las direcciones de los servidores de Google. Hay que modificar el contenido del
archivo /etc/bind/named.conf.options descomentando las líneas de forwarders y añadir las
direcciones de los dns de Google.

Paso 2:
Reinicia el servidor bind con el comando sudo /etc/init.d/bind9 restart. Puedes comprobar
que realmente está funcionando con sudo /etc/init.d/bind9 status.

Paso 3:
Usa el comando dig para comprobar que el servidor esta realmente resolviendo las peticiones

6
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

que se le hacen. Para ello necesitas saber tu dirección IP, en mi caso es 192.168.1.116.1

Paso 4:
Configura otra máquina virtual (mejor si está en otro equipo) para que tenga como servidor
DNS al anterior. Si es una máquina Ubuntu lo más sencillo es editar el archivo /etc/resolv.conf
y sustituir las IP por las de nuestro servidor DNS en nameserver.

No hace falta reiniciar ningún servicio para que funcionen los cambios. Si ejecutamos ahora el
comando dig www.google.es debería aparecer el mismo resultado que en el paso 3.
Para entregar:
Hay que entregar una captura de pantalla del archivo de configuración y de las dos pruebas
con el dig.
Opcional:
Comprueba en casa si tu router esta funcionando como servidor DNS caché. Si tienes
Windows usa el comando nslookup en vez de dig.
Si tienes Windows, usa el comando ipconfig para averiguar la IP del router (es la puerta de
enlace predeterminada) y después nslookup y una dirección de dominio.

1 Si no devuelve ninguna dirección para la url www.google.es puede deberse a problemas con el cortafuegos, que no
deja hacer peticiones a servidores DNS que no sean los de conselleria.

7
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Si tienes Ubuntu usa route -n para la dirección del router y después dig más una dirección de
dominio. La información devuelta del server debe coincidir con la ip del router.
Adjunta también una captura de pantalla con esta prueba.

Configuración de un Servidor Maestro Primario.

En este punto configuraremos el servidor maestro primario para el dominio example.com. Para
cualquier otro dominio solo habría que sustituir example.com por el nombre de dominio
correspondiente.

Archivo de zona.
Para añadir una zona DNS a BIND9, convirtiendo BIND9 en un servidor maestro primario, todo lo
que hay que hacer es editar el fichero named.conf.local añadiendo las siguientes líneas:
/etc/bind/named.conf.local
[...]

zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};

[...]

Ahora hay que crear el archivo de zona al que se hace referencia en named.conf.local. Para no
empezar desde cero se suele utilizar uno de los ejemplos de BIND como plantilla. El siguiente
comando copia la plantilla creando el nuevo archivo:
$ sudo cp /etc/bind/db.local /etc/bind/db.example.com

Editar el nuevo archivo de zona /etc/bind/db.example.com localhost cambiando localhost. al FQDN

(Full Qualified Domain Name) de su servidor, dejando el adicional "." al final. También hay que
cambiar 127.0.0.1 a la dirección IP del servidor de nombres y root.localhost a una dirección de
correo electrónico válida, pero con un "." en vez de "@". dejando también el "." al final.
Una buena costumbre es añadir en los comentarios en que zona estamos, es decir, a quien hace
referencia @ en este archivo.
Añadiremos un registro NS como mínimo, el correspondiente al servidor donde esta este archivo,
ns.example.com, es el servidor de nombres en este ejemplo. He añadido un servidor secundario (lo
configuraremos más adelante) llamado ns2.example.com. No hay que olvidarse de crear un registro
A para cada servidor de nombres en la zona.
Otros elementos de esta zona añadidos al ejemplo de configuración son los siguientes:
• Servidor de correo: mail.example.com
• Además hay registrados varios dispositivos, algunos de ellos con alías.

8
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

/etc/bind/db.example.com
;
; BIND data file for local loopback interface
;
; datos de la zona exemple.com ( @ = exemple.com. )

;
$TTL 604800
@ IN SOA ns.example.com. hostmaster.example.com. (
2015111001 ; Serial
43200 ; Refresh
1800 ; Retry
1209600 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS ns.example.com. Serial: Número de serie de la zona. Sirve de
@ IN NS ns2.example.com.
referencia a los servidores secundarios de la
@ IN MX 10 mail.example.com. zona para saber cuando deben de hacer una
actualización de su base de datos. Se suele
expresar como una fechaacabada en un número
ns IN A 192.168.1.10 de versión.
ns2 IN A 192.168.1.11 Refresh: Cada cuanto un servidor secundario
mail IN A 192.168.1.12 debe contactar con el servidor primario para
;lista other computers comprobar los cambios en la zona.
box IN A 192.168.1.21 Retry: En caso de error en la transferencia cada
ftp IN CNAME box.example.com. cuanto se debe volver a intentar.
Expire: Caducidad de la información de la zona
printer IN A 192.168.1.22 en el servidor secundario.
samsung IN CNAME printer.example.com. TTL: Tiempo que un registro es valido en el
servidor dns caché. Todos los registros pueden
hostx IN A 192.168.1.100
hosty IN A 192.168.1.101 llevar un TTL opcional. Si no lo llevan usan el
joan IN CNAME hosty.example.com. indicado en la zona.
hostz IN A 192.168.1.102
Se debe incrementar el número de serie cada vez que realicemos cambios en el archivo de zona. Si
se hacen varios cambios antes de reiniciar BIND9, simplemente se incrementa el número de serie de
una vez. Como número de serie se suele usar la última fecha de edición como el número de serie de
una zona, como por ejemplo 2015111001, es decir, el año, mes y día más un número de dos cifras
adicional.
Ahora, solo hay que agregar registros DNS al final del archivo de la zona.
Tened en cuenta que para cada cambio que realizáis en el archivo de zona, hay que reiniciar BIND
para que los cambios surtan efecto:
sudo /etc/init.d/bind9 restart

Diferencias entre zonas y dominios.

Tened en cuenta que las direcciones IP utilizadas en el ejemplo son direcciones IP privadas. Esto
implica que los equipos solo son accesibles desde la propia red local y que el servidor DNS este
situado también en la red local. Esta zona sería solo de uso local privado. Su utilidad consiste en
que los usuarios no tengan que trabajar con direcciones IP.
Si cambiamos las direcciones IP por públicas los equipos pasaran a poderse acceder desde el
exterior. Por supuesto esas direcciones nos las tienen que asignar (normalmente previo pago), no
podemos usar las que queramos. En este caso tendríamos una zona accesible desde el exterior.
En los dos casos tendremos un solo archivo de zona (falta ver la zona inversa, pero como veremos
también se refiere a la misma zona). Este seria el caso más sencillo: una zona, un dominio.

9
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Como las empresas (excepto las grandes) no suelen tener muchas direcciones IP públicas. Entonces
no les compensa tener un servidor DNS propio y contratan alguna empresa especializada que les
ofrezca este servicio. El servidor DNS de esta empresa tendrá entonces varios archivos de zona, uno
por cada dominio de empresa que les haya contratado. En este caso, solo se complica en que
tenemos varios archivos, es decir varias zonas, cada una con su dominio.
Las empresas que proporcionan este tipo de servicio, también ofrecen servicios a particulares y
pequeñas empresas que contratan subdominios dentro del suyo. Por ejemplo, no-ip ofrece varias
direcciones donde crear tu propio dominio. Por ejemplo, juan.no-ip.com. Otros usuarios tendrán
también su dominio (jose.no-ip.com, maria.no-ip.com, …) No les compensa tener un archivo de
zona por cada uno de estos dominios, por lo que se agrupan en el dominio superior (no.ip.com). Se
dice entonces que tenemos una zona que contiene varios dominios.
Se puede dar el caso contrario. Algunas empresas son tan grandes que un solo archivo de zona se
hace demasiado extenso y difícil de tratar. La solución es dividir el dominio en varias zonas,
normalmente delegando el trabajo en varios administradores cada uno de los cuales tendría su
propio servidor que administrar. Tenemos en este caso un dominio dividido en varias zonas.

Archivo de zona inversa o reverse zone.

La operación más habitual con el DNS es obtener la dirección IP correspondiente a un nombre de
nodo. Sin embargo, a veces queremos hacer la operación opuesta: encontrar el nombre a partir de la
dirección IP. Esto se conoce como resolución inversa, y la usan diversas aplicaciones para
comprobación de identidad del cliente. Realizar una búsqueda exhaustiva en el espacio de nombres
del servidor DNS no es eficiente. En su lugar, se utilizan las llamadas reverse zones.
Para declarar una zona inversa hay que añadir el siguiente texto a /etc/bind/named.conf.local:
/etc/bind/named.conf.local
[...]

zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.192";
};
[...]

Fijaos en que en la reverse zone las direcciones IP se escriben al revés. Además se les añade siempre
.in-addr.arpa. Para crear la zona se debe indicar solo la parte de la dirección correspondiente a la
red. En nuestro caso es una red de clase C, por lo que se ponen los tres primeros números, escritos
en orden inverso. Si la dirección fuese de clase B como 172.16.0.0, la zona se declararía como:
zone "16.172.in-addr.arpa" {

Y si fuese de clase A, como por ejemplo, 10.0.0.0 se declararía como:

zone "10.in-addr.arpa" {

Ahora nos faltaría editar el archivo /etc/bind/db.192:

10
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

/etc/bind/db.192
;
; BIND reverse data file for local loopback interface
;
datos de la zona 1.168.192.in-addr.arpa ( @ = 1.168.192.in-addr.arpa. )
;
$TTL 604800
@ IN SOA ns.example.com. hostmaster.example.com. (
2015111002 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.example.com.
@ IN NS ns2.example.com.

10 IN PTR ns.example.com.
11 IN PTR ns2.example.com.
12 IN PTR mail.example.com.

; also list other computers

21 IN PTR box.example.com.

22 IN PTR printer.example.com.
100 IN PTR hostx.example.com.
101 IN PTR hosty.example.com.
102 IN PTR hostz.example.com.

En la zona inversa solo se añaden los registros NS (igual que en la zona directa) y un registro PTR
por cada archivo A. Los registros MX se pueden añadir, pero solo se suelen poner en la zona
directa, y los CNAME no se añaden.
En los registros PTR se indica la dirección IP escrita al revés, pero para abreviar solo se suele
indicar la parte del host. Por ejemplo el registro para la dirección 192.168.1.100 se puede escribir:
100.1.168.192 IN PTR hostx.example.com.

Pero es más cómodo simplemente poner:

100 IN PTR hostx.example.com.

Tened en cuenta que si la dirección fuera 172.16.1.100 el registro abreviado, al ser de clase B,
quedaría:
100.1 IN PTR hostx.example.com.

Y si usamos la dirección de clase A 10.2.1.100 sería:

2.1.100 IN PTR hostx.example.com.

11
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

PRÁCTICA 2
Vamos a modificar el servidor DNS que hemos creado en la práctica anterior para que
también sea el servidor primario de su zona. Cada grupo tendrá un dominio propio y tendrá
que crear su archivo de zona correspondiente. Se entregará una captura de pantalla en el que
se vean las modificaciones o comprobaciones de cada paso.
Paso 1:
Modifica el archivo /etc/bind/named.conf.local para que incluya la nueva zona y un enlace al
fichero de la zona.
Paso 2:
Crea el archivo de zona desde cero o copiando uno de los existentes. El archivo de zona
incluirá como mínimo un registro SOA, un NS, tres A y dos CNAME. Podéis crear registros A
para máquinas virtuales y para las reales. Uno de los registros A debe apuntar al equipo del
profesor (10.2.1.254).
En cuanto a los tiempos de SOA, el de actualización sea de solo 10 minutos, 2 de reintento y
30 minutos el de expiración. El TTL que sea de 1 hora. No son tiempos habituales pero nos
servirán en la siguiente práctica para comprobar que el servidor secundario se actualiza
correctamente.
Paso 3:
Comprueba que la zona creada es correcta antes de reiniciar el servicio. Puedes hacerlo
(cambiando el nombre del dominio y del archivo) con el comando:
$ named-checkzone example.com /etc/bind/db.example.com
Paso 4:
Crea la zona inversa correspondiente a la que acabas de crear.
Paso 5:
Comprueba la zona inversa con el comando named-checkzone y el nombre de la zona inversa
y su archivo.
Paso 6:
Reinicia el servicio y comprueba su estado.
Paso 7:
Desde otro equipo (con el dns configurado con la IP de nuestro servidor) hay ping a los
nombres que has configurado y comprueba que realmente esta resolviendo.
Si tienen alguno de los equipos instalado Apache comprueba que se puede acceder desde el
navegador añadiendo el nombre que le hemos asignado.

El registro SVR.
Antes de ver la configuración del servidor secundario vamos a ver un ejemplo de como añadir
varios equipos para realizar un solo servicio. Esta configuración se suele utilizar para servicios que
tienen un gran volumen de peticiones y requieren una alta disponibilidad. En esa clase de servicios
no se utiliza un solo servidor, sino que se utilizan dos o más servidores. El formato del registro es:
_service._proto.name. TTL class SRV priority weight port target.

Donde:
• service: es el nombre del servicio.

12
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

• proto: El protocolo de transporte del servicio que se va a usar. Suele ser TPS o UDP
• name: El nombre del dominio, acabado en punto
• TTL: El time to live para este registro. Si no se indica se usa el del registro SOA.
• class: Siempre es IN
• priority: La prioridad del host destino, un número más bajo indica mayor prioridad.
• weight: el peso para los registros de la misma prioridad, un peso mayor significa mayor
probabilidad de que se elija ese host.
• port: el puerto TCP o UDP donde se encuentra el servicio. No es obligatorio usar el puerto
estándar.
• target: el nombre del host que proporciona el servicio, acabado en punto.
Veamos un ejemplo. Supongamos que tenemos varios equipos para proporcionar un servicio de
transferencia de archivos (ftp). Como un solo equipo no da abasto para proporcionar el servicio con
la calidad que queremos hemos añadido cuatro nuevos equipo, dejando el viejo como reserva y
copia de seguridad.
Los clientes accederán a la misma dirección files.example.com, pero serán redirigidos por el
servidor DNS a cada uno de los cinco posibles servidores dependiendo en primer lugar de la
prioridad y en segundo del peso asignado.
/etc/bind/db.example.com
[...]
ftp.tcp.files.example.com. IN SRV 10 60 5060 bigbox.example.com.
ftp.tcp.files.example.com. IN SRV 10 20 5060 smallbox1.example.com.
ftp.tcp.files.example.com. IN SRV 10 10 5060 smallbox2.example.com.
ftp.tcp.files.example.com. IN SRV 10 10 5066 smallbox2.example.com.
ftp.tcp.files.example.com. IN SRV 20 0 5060 backupbox.example.com.

[...]

Los primeros cuatro registros comparten una prioridad de 10, por lo que se usará el valor del campo
de peso para seleccionar el servidor (combinación de host y puerto) que será usado por el cliente
para ponerse en contacto. La suma de todos los cuatro valores es 100, por lo que se utilizará
bigbox.example.com 60% del tiempo. Los smallbox1 y smallbox2 serán utilizados por el 20% de
las solicitudes de cada uno, con la mitad de las solicitudes que se envían a smallbox2 (es decir, 10%
de las solicitudes totales) de ir al puerto 5060 y la otra mitad al puerto 5066. Si BigBox no estuviera
disponible, las dos máquinas restantes compartirían la carga por igual, cada una el 50% del tiempo.
Si los cuatro servidores con prioridad 10 no están disponibles, se seleccionará el registro con el
siguiente valor de prioridad más baja, que es backupbox.example.com. Esto podría ser una máquina
en otra ubicación física, lo que nos protegería probablemente de cualquier cosa que pudiera
provocar que los tres primeros anfitriones no estén disponibles.
El balanceo de carga proporcionado por los registros SRV está inherentemente limitado, ya que la
información es esencialmente estática. La carga actual de los servidores no es tenido en cuenta.
Por supuesto se tendrían que añadir registros A o CNAME para cada uno de los nombres que se
indican (bigbox, smallbox1, smallbox2 y backupbox)

13
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

Imagen 8: Red usada en el ejemplo del registro SVR. El porcentaje indicado en

cada línea indica el % de probabilidad de usar cada servidor.

Configuración del Servidor Maestro Secundario.

Una vez que el servidor primario ase ha configurado, necesitaremos configurar un servidor
secundario para mantener la disponibilidad del dominio si el primario no está disponible.
En primer lugar debemos de permitir las transferencias de zona en nuestro servidor primario. Esto
se hace añadiendo la opción allow-transfer en la definición de la zona (directa e inversa) que hemos
creado en /etc/bind/named.conf.local:
/etc/bind/named.conf.local
[...]
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
};

[...]

zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
};

[...]

Nota: hay que reemplazar 192.168.1.11 con la ip real del servidor secundario.
Ademas, por coherencia, se deberían incluir un registro NS y uno A en la zona directa y uno NS y
uno PTR en la zona inversa para el servidor secundario. En nuestro ejemplo ha están añadidos.

14
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

El siguiente paso sería instalar bind9 en el equipo que queremos que funcione como secundario.
Este paso ya debería estar completo ya que hemos instalado varios servidores con bind9.
Después hay que editar el archivo /etc/bind/named.conf.local y añadir las siguientes declaraciones
para las zonas directa e inversa:
/etc/bind/named.conf.local
[...]
zone "example.com" {
type slave;
file "/var/cache/bind/db.example.com";
masters { 192.168.1.10; };
};

[...]

zone "1.168.192.in-addr.arpa" {
type slave;
file "/var/cache/bind/db.192";
masters { 192.168.1.10; };
};

[...]
Nota: reemplazar la dirección 192.168.1.10 del ejemplo con la dirección ip real del servidor
primario. Los archivos de la zona tienen que estar en /var/cache/bind debido a que AppArmor (el
módulo de seguridad de Linux) solo permite accesos de escritura por parte del servicio dns es esa
carpeta. Ahí es también donde se guardan los datos recibidos desde otros servidores si estamos
actuando como servidores caché.

PRÁCTICA 3
En esta práctica añadiremos un servidor secundario a nuestra zona. Recuerda hacer una
captura de pantalla de cada paso.
Paso 1:
Modifica el archivo /etc/bind/named.conf.local en el servidor primario para que incluya la
opción allow-transfer a nuestro servidor secundario.
Añade el servidor secundario en los archivos de zona directa e inversa, añadiendo registros
NS y A, y registros NS y PTR respectivamente.
Reinicia el servicio.
Paso 2:
En el servidor secundario, añade al archivo /etc/bind/named.conf.local las declaraciones
necesarias para que funcione como servidor secundario.
Reinicia el servicio.
Paso 3:
Comprueba que se han copiado los archivos de zona correctamente.
Paso 4:
Modifica los archivos de zona para que incluyan un registro A y uno PTR al equipo
backup.example.com con dirección 10.2.1.253. No te olvides de cambiar el número de serie
de los archivos.
Paso 5:
Espera el tiempo de actualización y comprueba que se han actualizado los archivos en el
servidor secundario.

15
INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS JUAN ANTONIO DONET

DNS Dinámico.
Los servidores DNS que se han descrito en los apartados anteriores suelen trabajar con direcciones
IP estáticas, es decir, direcciones que no cambian nunca o casi nunca. Las direcciones que nos
suelen proporcionar los ISP suelen ser dinámicas. Para adaptarse a este tipo de direcciones existen
los DNS dinámicos. Estos constan de un servidor como los anteriores, con los tiempos de
actualización y de TTL más corto, y un programa en cada uno de los equipos que administran que
informará al servidor de cambios en la dirección IP de ese cliente.
Por ejemplo, si se quiere tener una página web o cualquier otro servicio instalado en un equipo de
nuestra casa, tendremos2 que contratar un servicio de DNS dinámico (la mayoría ofrecen el servicio
básico gratis). Instalaremos un programa que informará cada cierto tiempo comprueba la dirección
IP pública de nuestro router y en caso de cambios informa al servidor DNS de nuestra nueva
dirección IP.

2 Se necesitará además para que el servicio funcione tener redirigidos los puertos en el router. La mayoría de DNS
dinámicos disponen de manuales de como realizar esta redirección. Nosotros lo probaremos más adelante en otra
práctica.

16