1.

DNS (Bind & IOS)

Versión 1.1, febrero 2017

Alumno (apellidos, nombre (DNI): Alberto Ahijado Dochado (70821406J)
Alumno (apellidos, nombre (DNI): Diego Gomez Gonzalez (70822272M)
Fecha: 27/03/2017
Duración estimada de la práctica: 1 sesión de 2h.

1.1. Entorno de trabajo

 Software de emulación de redes: GNS3 (Analizador de red: wireshark)
 Cisco IOS
 Servidor DNS en Lunix virtualizado (DebianAlumno): Bind9
 Órdenes de diagnóstico para interrogar al DNS: dig/host

1.2. Objetivos
 Aprender a configurar servidores DNS: Bind e IOS
o Tipos de registros: SOA, NS, A, etc.
 Entender el funcionamiento de los servidores DNS en la jerarquía de servidores:
 Como resuelven las preguntas (mensajes intercambiados entre los intervinientes
(cliente-resolver y los diferentes DNSs de la jerarquía)
 Como se gestionan las cachés

1
2

1.3. Escenario de trabajo

Para la realización de los siguientes ejercicios se trabajará sobre un escenario prediseñado en
GNS3 llamado dns.tar.gz. Descomprimir este fichero en el directorio GNS3/projects del
UbuntuRedes. Se generará un directorio dns con los archivos del escenario. Abrirlo con GNS3 y
se mostrará lo siquiente.
Árbol de dominios: El escenario de red definido en dns está formado por 4 routers y 9 máquinas
(ver Figura 1). Representan la jerarquía de servidores DNS de Internet existentes entre los
dominios usal.es y cisco.com:
 Dominio raíz donde se encuentra la máquina dnsraiz.
 Dominio .es donde se encuentran los routers r1 y r2 y los equipos dnses y pces. Por lo
tanto, su nombre completo es r1.es, r2.es, dnses.es y pces.es respectivamente.
 Dominio usal.es donde se encuentran las máquinas dnsusal, portal y roble. Por lo tanto,
su nombre completo es dnsusal.usal.es, portal.usal.es (también www.usal.es) y
roble.usal.es (también diaweb.usal.es) respectivamente.
 Dominio .com donde se encuentran los routers r3 y r4 y la máquina dnscom. Por lo tanto,
su nombre completo es r3.com, r4.com y dnscom.com respectivamente.
 Dominio cisco.com donde se encuentran las máquinas www1 y www2. El router R4
actuará como DNS de este dominio. Por lo tanto, su nombre completo es r4.cisco.com,
www1.cisco.com, www2.cisco.com (ambos denominados www.cisco.com)
respectivamente.

Figura 1: Escenario DNS

 3

Todos los equipos están ya configurados excepto el DNS del router R4 (dnscisco) que será el
responsable del dominio cisco.com.

1.4. El servidor DNS

Servidores DNS. Como servidor de DNS en los equipos Debian utilizaremos bind9. En las
máquinas virtualizadas con QEmu (denominadas por defecto como Debian-X) ya se dispone de
un servidor DNS instalado, pero en caso de necesitar instalarlo en un entorno diferente, la orden
para Debian es:
apt-get install bind9
Los equipos denominados Debian en GNS3 virtualizan la máquina “Debian Alumno” siendo su
usuario y clave las ya conocidas root/labii.
Arranca las máquinas del escenario de una en una (esta operación puede tardar unos minutos).
Accede a su consola desde la interfaz de GNS3 o bien con la orden consolas lanzada desde un
terminal que abre en una sola ventana todas las consolas. Si se desea cambiar el nombre de la
ventana para pasar más fácilmente de una a otra, usar la orden nombre-ventana. Por ejemplo
en el equipo dnsusal: nombre-ventana dnsusal.
Los ficheros de configuración se encuentran en la ruta /etc/bind. En las siguientes máquinas se
ha configurado bind9 para que funcione como servidor de DNS como sigue:
 dnsraiz: Servidor de nombres raíz (archivos /bind/named.conf.options,
/bind/named.conf.local, /bind/db.root, /bind/db.raiz y /bind/db.0.193).
 dnscom: Servidor de nombres del dominio com (archivos /bind/named.conf.options,
/bind/named.conf.local, /bind/db.root, /bind/db.com, /bind/db.0.30 y
/bind/db.1.30).
 dnses: Servidor de nombres del dominio es (archivos /bind/named.conf.options,
/bind/named.conf.local, /bind/db.root, /bind/db.es, /bind/db.0.20 y /bind/db.20).
 dnsusal: Servidor de nombres del dominio usal.es (archivos
/bind/named.conf.options, /bind/named.conf.local, /bind/db.root, /bind/db.es.usal
, /bind/db.0.1.20, /bind/db.0.2.20).
Configuración de la resolución de nombres en las máquinas: Todas las máquinas del escenario,
si necesitan una operación de resolución de nombres, primero consultarán su fichero local
/etc/hosts y si no encuentran la respuesta, consultarán a su servidor de DNS.

a) Revisa el fichero resolv.conf de los equipos Debian ( ) e incluye en el informe el

servidor DNS asignado.
DNS RAIZ:

Indica que el dominio que sirve es el raiz “.”, y que es él su propio servidor dns.
4

DNS COM:

Indica que el dominio que sirve es el “com”, y que es él su propio servidor dns.

DNS ES:

Indica que el dominio que sirve es el “es” y que es él su propio servidor dns.

DNS USAL:

Indica que el dominio que sirve es el “usal.es” y que es él su propio servidor dns.

b) Consulta en los routers esta misma información. ¿Qué orden has utilizado?
Orden utilizada: show ip name-server, y muestra las Ips de los servidores de
nombres que tienen asignados cada router.

R1:

R2:
 5

R3:

R4:
Vemos que R4 no tiene ningún DNS asignado.

c) Consulta en los VPCS esta misma información. ¿Qué orden has utilizado?
Orden utilizada: show ip

www2:

www1:

Los equipos www1 y ww2 tienen asignado como dns R4.

6

Roble:

Portal:

Los equipos roble y portal, tiene asignados como dns dnsusal.

Pces:

El equipos pces, tiene aisgnado como dns el dnses.

Revisión del escenario configurado

d) Revisa y comenta brevemente los ficheros de configuración de todos los servidores
de DNS del escenario (dnsraiz, dnscom, dnses y dnsusal).
- Los ficheros /etc/bind/named.conf.local, son ficheros de configuración para
incluir dominios locales.
- En los ficheros /etc/bind/db.root, tenemos las direcciones Ip de los servidores
del dominio raíz.
 7

- Los ficheros /etc/bind/db.*, contienen los mapas de dominio, resolución directa

e inversa.
- Los ficheros /etc/bind/named.conf.options, contiene opciones genéricos del
servidor dns que estamos configurando.
-
DNSraiz
/bind/named.conf.options

/bind/named.conf.local
8

/bind/db.root

/bind/db.raiz

/bind/db.0.193
 9

DNScom
/bind/named.conf.options

/bind/named.conf.local

/bind/db.root
10

/bind/db.com

/bind/db.0.30

/bind/db.1.30
 11

DNSes
/bind/named.conf.options

/bind/named.conf.local

/bind/db.root
12

/bind/db.es

/bind/db.0.20

/bind/db.20
 13

DNSusal
/bind/named.conf.options

/bind/named.conf.local

/bind/db.root
14

/bind/db.es.usal

/bind/db.0.1.20

/bind/db.0.2.20
Este fichero no existe.

Resolución de nombres: Arranca las máquinas del escenario de una en una y accede a su consola
(esta operación puede tardar unos minutos). Se puede acceder desde la interfaz de GNS3 o bien
con la orden consolas lanzada desde un terminal que abre en una sola ventana todas las
consolas. Por medio de las órdenes para preguntar al DNS host y dig, así como de wireshark,
realiza los siguientes apartados:
Servidor DNS en IOS
e) Los siguientes pasos permitirán observar si los routers de Cisco habilitan o no un
servidor DNS, configurar R4 como servidor DNS del dominio cisco.com y verificar su
fucionamiento:
 Én el router R4 realiza un ping a www.usal.es ¿Qué ha ocurrido? ¿por qué?

Ocurre lo siguiente:
 15

No se lleva acabo porque R4 no tiene configurado el DNS, y no se puede hacer

la resolución de nombres.
 Asigna a R4 un servidor de nombre (en nuestro caso dnscom – 30.0.0.10) y el
dominio cisco.com. Incluye las órdenes utilizadas.

Las ordenes utilizadas son las siguientes:

Y como comprobación para ver que todo ha ido bien hacemos lo siguiente:

 Realiza de nuevo un ping a www.usal.es

¿Qué ha ocurrido?

Que ahora si que ha podido resolver la petición de Dns.

¿Por qué?
Porque ahora R4 si tiene asignado un DNS.

¿Hay alguna entrada nueva en la cache de resolución de nombres?

Si
16

¿Qué orden has utilizado para consultarla?

show hosts

¿Cuanto tiempo permanecerán en la cache?

Permanecera unos 30 segundos.

¿Donde se configura este tiempo?

En este caso en dnsusal, que es el servidor dns que sirve este dominio.

 Configurar R4 como responsable del dominio cisco.com. Hemos de seguir los

siguientes pasos:
 Habilitar DNS server
 Añadir los recursos: SOA, NS y A
 Añadir un balanceo de tráfico para www.cisco.com entre www1 y
www2
 Escribe las órdenes utilizadas

De esta manera, al hacer ping a www.cisco.com unas veces lo resolverá www1 y

otras www2 (balanceo)
 17

 Comprueba tu configuración desde los equipos www1 y www2 resolviendo

nombres en del dominio .com y usal.es. ¿Qué órdenes has utilizado? Muestra y
comenta las salidas obtenidas. Consulta la caché del DNS de R4. ¿Qué orden has
utilizado? ¿Justifica las entradas encontradas?
Hemos hecho ping a www2.cisco.com y a www1.cisco.com y la respuesta ha
sido correcta. Igualmente hemos hecho ping a roble.usal.es y la respuesta
también ha sido correcta. Usando show hosts la caché de R4 aparece como en
la anterior imagen. Se puede ver que están registrados los equipos

f) Antes de comenzar este apartado aseguraté que las cachés de todos los DNS
estén vacías. Puedes borrar la caché de un servidor de DNS reiniciando el
servidor con la orden: service bind9 restart o bien con las órdenes
rndc flush
rndc reload
Desde la máquina roble (del dominio usal.es) ejecuta ping www.cisco.com. Realiza
las capturas del tráfico que consideres necesarias para obtener los mensajes de DNS
que se generan entre todas las máquinas del escenario. Explica apoyándote en las
capturas realizadas el proceso de obtención de respuestas en un sistema de DNS.
18

Presta especial atención al campo Recursion desired que especifica el tipo de

pregunta realizada: recursiva (activado) o iterativa (desactivado). Observa también
en las capturas realizadas el valor del campo TTL (Time To Live) del mensaje de DNS
de la respuesta obtenida en roble (no confundir con el campo TTL de la cabecera de
los datagramas IP). ¿Qué significa este valor y de donde se obtiene? Ten en cuenta
que la primera vez que realices el ejercicio todas las cachés de los servidores DNS
estarán vacías. Recuerda que, si realizas más de una consulta a un servidor de DNS,
éste almacena información en su caché. Para consultarla puedes utilizar las ordenes
rndc dumpdb -cache
cat /var/cache/bind/named_dump.db
Basta con capturar trafico en el Router 1

Explicacion del tráfico DNS generado:

Siguiendo el siguiente esquema proporcionado en teoría y adaptado a nuestro caso:
 19

El resolver en nuestro caso (el equipo roble), hace una consulta a su servidor de
dns local (dnsusal) preguntando por la dirección de www.cisco.com, busca si le
puede resolver, y como no puede pregunta a su dns raíz(dnsraiz), este no le puede
resolver tampoco pero le da la dirección de un servidor encargado del dominio
.com (dnscom). Este le dice que mire en R4 que es el que sirve el dominio
cisco.com. Finalmente R4 devuelve la dirección al DNS local (dnsusal) y el resolver
obtiene la dirección IP de www.cisco.com.

Vemos que tiene la recursión activada, esto también se prodria deducir de los
mensajes obtenidos en la captura de trafico realizada.
20

El time to live, es el tiempo de vida que le queda en la cache de roble.

 21

Cache de dnsusal:

En ella podemos ver que están cacheadas las direcciones de los equipos que han
sido necesarios para resolver los dominios por los que hemos preguntado
(www.cisco.com por ejemplo que hemos explicado arriba).
22

g) Desde la máquina roble (del dominio usal.es), ejecuta de nuevo ping

www.cisco.com. ¿Qué mensajes DNS se han generado esta vez? ¿Por qué? Explica
el valor del campo TTL del mensaje de DNS de la respuesta obtenida en roble y
compáralo con el de la pregunta anterior.

En esta captura se puede ver que roble pregunta a dnsusal (que como hemos dicho
anteriormente es el servidor dns local) por el dominio www.cisco.com. Como este servidor ya lo
tiene cacheado no pregunta al dnsraiz sino que pregunta directamente a R4 (30.0.0.2) que es el
responsable de ese dominio y este proporciona la dirección.
a) Desde la máquina dnsusal (del dominio usal.es) consulta la caché del DNS. A
continuación, ejecuta las órdenes (recuerda lanzar wireshark en el lugar adecuado
para capturar el tráfico generado):
dig r4.com > www1.log
dig r4.com > www2.log
dig dnscom.com > r4_1.log
dig dnscom.com > r4_2.log
Vuelve a consultar la cache de nuevo.
La orden dig permite obtener entre otros detalles de la resolución de nombre el
tiempo de respuesta. ¿Qué mensajes DNS se han generado? ¿Por qué? Muestra y
analiza cada mensaje con la ayuda de wireshark y los ficheros log obtenidos
(incluyelos en el informe). ¿Ha mejorado el tiempo de respuesta entre la primera
pregunta y su repetición? ¿Por qué?

Vemos que a pesar de hacer dos resoluciones de nombres a r4.com y otras dos a
dnscom.com, solo nos aparece tráfico de la primera de cada una, y esto se debe a
que dnsusal lo tiene cacheado la segunda vez que lo hacemos. Hemos repetido estas
órdenes y no obtenemos tráfico DNS, lo que efectivamente quiere decir que no tiene
que preguntar a ningún otro servidor
 23

Fichero www1.log

Fichero www2.log

Vemos que el tiempo de respuesta mejora en la segunda consulta, eso se debe a

que dnsusal lo tiene cacheado.
24

Fichero r4_1.log:

Fichero r4_2.log:

Vemos que como sucedia anteriormente el tiempo de respuesta mejora en la

segunda consulta, eso se debe a que dnsusal lo tiene cacheado.

Servidores DNS locales. Se desea instalar un servidor DNS privado con un dominio ficticio,
por ejemplo “redes.usal.es”, para nombrar a los equipos del laboratorio. Todos los PCs de
nuestra red pertenecerán a dicho dominio. El nombre completo de los PCs terminará con
“redes.usal.es”, por ejemplo: pc1.redes.usal.es. El diagrama resultante del montaje se
aproximará al de la Figura 2.
 25

Figura 2: Dominio redes.usal.es

Se pide:
h) Añadir al esquema de red los elementos necesarios (router, hub y máquinas) y
configurarlos para que puedan comunicarse en la red. Asignar direcciones IP de la
subred 20.3.0.0/16. Incluir el fichero de configuración /etc/network/interfaces del
equipo dnsredes, y las órdenes de configuración en PC1 y R5. Recuerda que para dar
conectividad total a esta nueva subred tendremos que modificar adecuadamente
las tablas de rutas de nuestro escenario. Indica que cambios y donde los has
realizado. Antes de continuar comprueba que has configurado correctamente todos
los elementos. ¿Qué pruebas has realizado?
NOTA:

 Para configurar dnsredes consultar la sintaxis de las órdenes en el anexo de

órdenes de redes en Linux disponible en Diaweb (Material práctico
Resumen de Órdenes). Especialmente: /etc/network/interfaces,
/etc/resolv.conf y las relacionadas con bind.
 Para configurar PC1 y los routers consultar las órdenes IOS en el manual de
Órdenes IOS disponible en Diaweb (Material práctico Resumen de Órdenes).
Dar ip a dnsredes:
26

Dar ip a pc1:

Dar ip a R5:

Dar ip a R1:

Modificando rutas:
R1:
Para añadir la ruta a la red 20.3.0.0:
 27

Y para añadir las rutas a las redes que tiene entrada directa:
- config t
- Interface “nombre interfaz”
- no shutdown

R5:
Para ir al resto del mundo:

Y para añadir las rutas a las redes que tiene entrada directa:
- config t
- Interface “nombre interfaz”
- no shutdown

Antes de seguir con la configuración del dns, realizamos unas pruebas intermedias
para ver que las rutas anteriormente introducidas son las correctas, para ello
realizamos una serie de pings desde la subred nueva añadida a diferentes host de la
red, y viceversa.
28

Configuracion del dnsredes:

- /etc/network/interfaces

i) Configurar un servidor DNS que sea maestro del dominio “redes.usal.es” en la

máquina dnsredes de tal forma que sea capaz de responder peticiones internas
tanto de forma directa como inversa.
i. En el fichero /etc/bind/named.conf.options deshabilitar las opciones de
seguridad. Cambiar:
dnssec-validation auto; por
// dnssec-validation auto;
dnssec-enable no;
dnssec-validation no;
ii. Añade en el archivo /etc/bind/named.conf.local la especificación de
maestro para el dominio en cuestión y para la resolución inversa como
sigue:
// Archivo para búsquedas directas
zone "redes.usal.es" {
type master;
file "/etc/bind/db.es.usal.redes";
};

// Archivo para búsquedas inversas

zone "0.3.20.in-addr.arpa" {
type master;
file "/etc/bind/db.0.3.20";
};
 29

iii. Crea el archivo de zona de resolución directa /etc/bind/db.es.usal.redes

como sigue:

$TTL 30; ttl de permanencia en las cachEs

@ IN SOA dnsredes.redes.usal.es. root.dnsredes.redes.usal.es. (
20170201; número de serie actualizar en cada cambio
; rediris recomienda poner la fecha
604800 ; Refresco 1 semana (servidores secundarios)
86400 ; Reintento tras 1 día
2419200 ; Expira después de 4 semanas
30) ; ttl de las respuestas negativas

IN NS dnsredes.redes.usal.es.
dnsredes IN A 20.3.0.10

r5 IN A 20.3.0.1
pc1 IN A 20.3.0.20
www IN CNAME pc1
correo IN CNAME pc1

iv. Crea el archivo de zona de resolución inversa /etc/bind/db.0.3.20 como

sigue:

$TTL 30; ttl de permanencia en las cachEs

@ IN SOA dnsredes.redes.usal.es. root.dnsredes.redes.usal.es. (
20170201; número de serie actualizar en cada cambio
; rediris recomienda poner la fecha
604800 ; Refresco 1 semana (servidores secundarios)
86400 ; Reintento tras 1 día
2419200 ; Expira después de 4 semanas
30) ; ttl de las respuestas negativas

IN NS dnsredes.redes.usal.es.

1 IN PTR r5.redes.usal.es.
20 IN PTR pc1.redes.usal.es.
10 IN PTR dnsredes.redes.usal.es.

v. Una vez configurado el servidor DNS, debemos indicarle que él mismo es su

servidor DNS, lo cual se especifica en el archivo /etc/resolv.conf como sigue:
domain redes.usal.es
nameserver 127.0.0.1

En el resto de PCs de la red (pc1, pc2, etc.) indicaremos que el servidor DNS
es el que acabamos de instalar (p. ej.: 20.3.0.10).
30

Configuracion necesaria en R5:

vi. Configura adecuadamente nuestro servidor local para que alcance los DNS
raices. Incluye en el informe los ficheros de configuración.
Hacemos cambios en el fichero /etc/bind/db.root, quedanso asi:
 31

vii. Ante de poner en marcha el servidor verifica que los ficheros de

configuración son correctos con la orden: named-checkconf

viii. Por último pon en marcha nuestro servidor de nombres ejecutando la

siguiente orden: /etc/init.d/bind restart
Comprueba en el log del sistema si se ha arrancado correctamente.
Normalmente en /var/log/syslog (ejemplo: tail /var/log/syslog)

j) Desde pc1 intenta resolver el nombre dnsredes.redes.usal.es. Especifica la orden

que has utilizado y realiza las capturas de tráfico que consideres necesarias para
obtener los mensajes de DNS que se generan en todo el esquema.
Usamos la siguiente orden:

Capturamos el tráfico por la interfaz la f2/0 de R5:

Vemos que el mensaje va desde pc1 hasta su servidor dns, en este caso a dnsredes,
y este como es el responsable del dominio le devuelve la resolución sin necesidad
de generar mas trafico.
32

k) Desde dnsredes intenta resolver la dirección IP obtenida en el apartado anterior.

Especifica la orden que has utilizado y realiza las capturas de tráfico que consideres
necesarias para obtener los mensajes de DNS que se generan en todo el esquema.

Capturamos el tráfico por la interfaz la f2/0 de R5, y observamos que no aperecen

mensajes de DNS, puesto que estamos resolvieno la ip de él mismo y lo tiene en
local, entonces no tiene que preguntar a nadie y por eso no hay tráfico.

l) Desde la máquina dnsredes ejecuta las órdenes (recuerda lanzar wireshark en el

lugar adecuado para capturar el tráfico generado):
dig dnsredes.redes.usal.es (anota el tiempo de respuesta)
dig dnsredes.redes.usal.es (anota el tiempo de respuesta)
¿Qué mensajes DNS se han generado? ¿Por qué? Muestra y analiza cada mensaje
con la ayuda de wireshark. ¿Ha mejorado el tiempo de respuesta entre la primera
pregunta y su repetición? ¿Por qué?
En ambos intentos no hay mensajes DNS, por lo mismo que hemos indicado en el
apartado anterior.

1º Intento:

2ºIntento:

Tarda menos porque dnsredes lo tiene cacheado, como podemos ver a

continuación:
 33

m) Modifica los ficheros necesarios en los servidores de dns para que desde cualquier
equipo se puedan resolver nombres del dominio redes.usal.es (resolución directa e
inversa). Incluye los ficheros nuevos y modificados necesarios. Realiza y documenta
las pruebas necesarias para verificar el correcto funcionamiento.
En el dnsusal, en el fichero /etc/bind/db.usal.es, hemos añadido lo siguiente:

Para comprobar el correcto funcionamiento hacemos ping hacia la subred nueva,

desde las diferentes subredes de la red:
- Desde la red del dominio .es
34

- Desde la red del dominio cisco.com

- Desde la red del dominio usal.es