Dns-enunciado

Ejercicio práctico sobre DNS: ENUNCIADO

OBJETIVOS

Con este escenario se pretende ilustrar el funcionamiento del DNS (Servicio de Nombres de Dominio).

El DNS es un servicio que proporciona la correspondencia entre la dirección IP de una máquina y su nombre de dominio, en redes de comunicación de gran tamaño. Cuando una máquina realiza la consulta sobre alguna correspondencia se lleva a cabo una secuencia de paquetes entre los servidores de nombres cuyo estudio es el principal objetivo de la creación de este escenario.

DESCRIPCIÓN DEL ESCENARIO

Las máquinas de la red forman una jerarquía de servidores de nombres como se indica en la Figura 1, que muestra las autoridades de cada uno, así como sus direcciones IPV4 e IPV6. El recuadro naranja contiene una pareja de servidores maestro/esclavo, como se verá más adelante.

Figura 1: Jerarquía de servidores DNS

El escenario está compuesto de una sola red. Adicionalmente disponemos de conexión con Internet a través de nuestro host, que forma parte de dicha red. (Ver Figura 2).

Figura 2: Topología física del escenario de DNS

Puede encontrar toda la información de jerarquía y autoridad de los servidores de nombres en el Apéndice I.

Si ha leído la sección dns: Antes de empezar podrá pasar a estudiar este escenario.

NOTAS

• Si decide resolver un apartado por separado (y no de manera secuencial como se aconseja, en principio), inicie la simulación del archivo dns.xml:

root@host# sudo su (para trabajar como root)
root@host:/home/usuario# cd /vnml/dns
root@host:/home/usuario/vnuml/dns# vnumlparser.pl -t dns.xml -v -u root

y ejecute este comando para todos los apartados anteriores al que desee estudiar:

root@host:/home/usuario/vnuml/dns# vnumlparser.pl -x aptdo1@dns.xml -v
root@host:/home/usuario/vnuml/dns# vnumlparser.pl -x aptdo2@dns.xml -v
...

A continuación puede proceder como se indica en el enunciado del apartado correspondiente.

Adicionalmente puede utilizar este comando para parar el servicio DNS en todos los servidores de nombres y poder así comenzar a ejecutar los apartados de nuevo:

root@host:/home/usuario/vnuml/dns# vnumlparser.pl -x stop@dns.xml -v

• A partir de ahora se sustituirá root@host:/home/usuario/vnuml/dns# por root@host# con el fin de no recargar el enunciado.

• Ignore las líneas informativas que resultan de la ejecución de cada apartado, no son relevantes para la resolución de esta práctica.

• Puede observar el tráfico que atraviesa la red de los clientes con Ethereal en modo gráfico directamente y en tiempo real con:

root@host# ethereal -i red1

Y dentro de Ethereal:

> Capture > Interfaces 

Aparecerá una lista de interfaces, de entre los cuales el interfaz "red1" será el utilizado a lo largo de esta práctica:

Figura 3: Interfaces del escenariosido

> red1 > Prepare (red1) > Capture File: fichero.cap > Start

Gracias a esta nueva interfaz, puede evitarse guardar las capturas en ficheros de las máquinas virtuales y su posterior copia remota.

Apartado 1: Estudio de la jerarquía de nombres.

El objetivo de este apartado es, conocida la jerarquía de nombres del escenario (ver figura Escenario dns.xml: Jerarquía), observar el tráfico producido por varias consultas DNS y la secuencia de paquetes entre los distintos servidores implicados.

• Inicie la simulación del archivo dns.xml:

root@host# sudo su (para trabajar como root)
root@host# cd /vnml/dns
root@host# vnumlparser.pl -t dns.xml -v -u root

• Regístrese en cada máquina virtual:

# login: root
# password: xxxx

Figura 4: Ventanas de las máquinas virtuales

• Escriba el siguiente comando en su PC:

root@host# vnumlparser.pl -x aptdo1@dns.xml -v

En este momento queda configurada la jerarquía de los servidores de nombres que se representaba anteriormente.

• En el desarrollo de esta práctica se va a utilizar la herramienta de diagnóstico de DNS "DIG", para realizar las consultas DNS. Obviamente podrían utilizarse otras herramientas como "Nslookup" o "Host". Puede aprender parte del funcionamiento básico de DIG en la sección Preguntas frecuentes: Dig.

• Para el análisis del tráfico generado por las distintas consultas se aprovechará la interfaz "red1", que representaría al switch que forma la LAN formada por las máquinas virtuales y el host. La captura en dicho interfaz puede tomarse mediante el uso de Ethereal (Ver Preguntas frecuentes: Ethereal). De esta forma se podrá observar todo el tráfico generado en la red independientemente de la máquina que lo origine.

• En la jerarquía DNS del escenario son múltiples las posibles consultas para su análisis. A pesar de que en esta práctica trabajaremos sólo con algunos ejemplos, se recomienda un estudio personal más en profundidad. Se pondrá un ejemplo para cada uno de los tipos de consultas a fin de dar una simple guía que será muy útil completar con otras combinaciones. Las propuestas son las siguientes:

NOTA: Las consultas que se presentan a continuación se realizan desde el host hacia la red, a pesar de que podríamos consultar desde cualquier otra máquina de las que pertenecen a la red. Se indican los comandos que sería necesario escribir en un Terminal del host.

• Consulta directa:

• IPV4: Registro A

root@host# dig @10.1.1.3 -t A h3.sd1.d2.alfa (ó dig @10.1.1.3 h3.sd1.d2.alfa)

• Se pregunta al servidor 10.1.1.3 por el registro de tipo A correspondiente a h3.sd1.d2.alfa.

• Analice la secuencia de paquetes obtenida. ¿Qué servidor consulta la máquina 10.1.1.3 en primer lugar y por qué? ¿Qué tipo de consulta realiza el cliente DNS del host? ¿Y el servidor de nombres 10.1.1.3? Describa la secuencia completa de consultas: servidores consultados y orden de consulta. (La captura de tráfico ha sido recogida en el fichero red1_1_1.cap).

• Los servidores de nombres disponen de un mecanismo de caché que almacena todas las consultas realizadas anteriormente. ¿Qué ocurriría, por tanto, si realizara la consulta por segunda vez, en cuanto al tráfico y al resultado devuelto por la herramienta DIG? (Ver captura red1_1_2.cap)

• IPV6: Registro AAAA

root@host# dig @10.1.1.9 -t AAAA h2.d1.alfa

• Se pregunta al servidor 10.1.1.9 por el registro de tipo AAAA correspondiente a h2.d1.alfa

• Analice la secuencia de paquetes obtenida. ¿Qué servidor consulta la máquina 10.1.1.9 en primer lugar y por qué? ¿Qué tipo de consulta realiza el cliente DNS del host? ¿Y el servidor de nombres 10.1.1.9? Describa la secuencia completa de consultas: servidores consultados y orden de consulta. (La captura de tráfico ha sido recogida en el fichero red1_1_3.cap).

• ¿Qué ocurriría si realizara la consulta por segunda vez, en cuanto al tráfico y al resultado devuelto por la herramienta DIG? (Ver captura red1_1_4.cap)

• IPV4/IPV6: Registros A y AAAA

root@norte# dig @10.1.1.6 -t ANY h2.alfa

• Se pregunta al servidor 10.1.1.6 por los registros de tipo A y AAAA correspondiente a h2.alfa.

• Analice la secuencia de paquetes obtenida. ¿Qué servidor consulta la máquina 10.1.1.6 en primer lugar y por qué? ¿Qué tipo de consulta realiza el cliente DNS del host? ¿Y el servidor de nombres 10.1.1.6? Describa la secuencia completa de consultas: servidores consultados y orden de consulta. (La captura de tráfico ha sido recogida en el fichero red1_1_5.cap).

• ¿Qué ocurriría si realizara la consulta por segunda vez, en cuanto al tráfico y al resultado devuelto por la herramienta DIG? (Ver captura red1_1_6.cap)

• Consulta inversa:

• IPV4: Registro PTR

root@host# dig @10.1.1.11 -x 10.1.1.13

• Se pregunta al servidor 10.1.1.11 por el registro de tipo PTR correspondiente a 10.1.1.13

• Analice la secuencia de paquetes obtenida. ¿Qué servidor consulta la máquina 10.1.1.11 en primer lugar y por qué? ¿Qué tipo de consulta realiza el cliente DNS del host? ¿Y el servidor de nombres 10.1.1.11? Describa la secuencia completa de consultas: servidores consultados y orden de consulta. (La captura de tráfico ha sido recogida en el fichero red1_1_7.cap).

• ¿Qué ocurriría si realizara la consulta por segunda vez, en cuanto al tráfico y al resultado devuelto por la herramienta DIG? (Ver captura red1_1_8.cap)

• IPV6: Registro PTR

root@host# dig @10.1.1.3 -t PTR 1.0.0.0.0.0.0.0.0.0.0.0.d.0.0.0.1.0.0.0.2.0.0.0.8.b.d.0.2.0.0.2.ip6.arpa

• Se pregunta al servidor 10.1.1.3 por el registro de tipo PTR correspondiente a la dirección IPV6 2001:db8:2:1:d::1

• Analice la secuencia de paquetes obtenida. ¿Qué servidor consulta la máquina 10.1.1.3 en primer lugar y por qué?¿Qué tipo de consulta realiza el cliente DNS del host? ¿Y el servidor de nombres 10.1.1.3? Describa la secuencia completa de consultas: servidores consultados y orden de consulta. (La captura de tráfico ha sido recogida en el fichero red1_1_9.cap).

• ¿Qué ocurriría si realizara la consulta por segunda vez, en cuanto al tráfico y al resultado devuelto por la herramienta DIG? (Ver captura red1_1_10.cap)

NOTA: Con DIG puede hacer también una consulta sobre los servidores de nombres con autoridad sobre un subdominio, por ejemplo:

 root@host# dig @10.1.1.1 alfa. ns

Apartado 2: Comando "rndc flush".

El objetivo de este apartado será observar el efecto, mediante el análisis del tráfico capturado en la red tras una posterior petición a la máquina en que se realice, del comando "rndc flush" ejecutado en una máquina virtual.

La última consulta que realizó en el apartado anterior se hizo sobre el servidor 10.1.1.3 (máquina virtual "beta" del escenario). Para ilustrar el efecto utilizaremos dicha máquina, por tanto escribimos en beta:

beta# rndc flush

En este momento repetirá la última consulta tal y como la había realizado, desde el host:

root@host# dig @10.1.1.3 -t PTR 1.0.0.0.0.0.0.0.0.0.0.0.d.0.0.0.1.0.0.0.2.0.0.0.8.b.d.0.2.0.0.2.ip6.arpa

Observando el tráfico obtenido en el analizador de protocolos, ¿cuál es el efecto del comando ejecutado? (La captura de tráfico puede observarse en red1_2.cap).

NOTA: Puede consultar otras opciones del comando rndc escribiendo:

# man rndc

Pruebe las opciones que considere oportunas sobre el escenario general.

Apartado 3: Servidor maestro/Servidor esclavo.

En este apartado se estudiará el funcionamiento de un servidor esclavo y su utilidad en caso de caída del maestro.

Para el dominio "alfa" se han configurado dos máquinas con autoridad sobre él: alfa y alfa2. En ellas se ubican el servidor de nombres primario y secundario respectivamente.

Hasta este momento el servidor de nombres esclavo no ha sido iniciado, por lo que deberá hacerlo en este momento, capturando simultáneamente en la interfaz del maestro con la subred, con los comandos:

alfa# tethereal -i eth1 -S -w fichero1.cap
root@host# vnumlparser.pl -x aptdo3A@dns.xml -v

Puede recuperar el archivo de la captura desde su PC con:

root@host# scp alfa:fichero1.cap .

y visualizarlo:

root@host# ethereal fichero1.cap

Deberá observar la secuencia de paquetes entre el servidor de nombres esclavo (10.1.1.12/2001:db8::c) y maestro (10.1.1.2/2001:db8::2). ¿Cuál es el objetivo de dicho intercambio de paquetes? (Puede encontrar la captura correspondiente al arranque del servidor esclavo en red1_3_1.cap)

• Ahora comprobaremos que ambas máquinas pueden dar una respuesta sin acudir a otro servidor de nombres cuando se realiza en ellos una consulta sobre una máquina bajo el dominio "alfa", por ejemplo h1.alfa. Para ello, desde su host escriba (capturando simultáneamente el tráfico con el Analizador de Protocolos):

root@host# dig @10.1.1.2 -t A h1.alfa (que realiza la consulta en la máquina alfa)

root@host# dig @10.1.1.12 -t A h1.alfa (que realiza la consulta en la máquina alfa2)

En ambos casos el resultado obtenido es el mismo, pero será la máquina a la que se le pregunte la que conteste con la dirección IP requerida. Con esto hemos comprobado que ambos tienen la información del dominio y autoridad sobre el mismo. (Puede encontrar la captura correspondiente a ambas peticiones en red1_3_2.cap).

• Si recuerda el funcionamiento servidor/esclavo de DNS, sabrá que toda modificación en un archivo de zona del servidor maestro se hará también efectiva en el servidor esclavo de manera transparente para los usuarios del servicio.

Previamente capture los paquetes que atraviesen el interfaz del esclavo como lo hizo anteriormente, durante unos minutos, sin ejecutar ninguna petición:

alfa2# tethereal -i eth1 -S -w fichero2.cap

root@host# scp alfa2:fichero2.cap .

NOTA: Ya conoce la orden que recupera el fichero desde su PC.

¿Cuál es la utilidad de los paquetes que envía el esclavo al maestro y las respuestas de este? (Puede encontrar la captura correspondiente en red1_3_3.cap)

Comience a capturar de nuevo en el maestro. Con el siguiente comando se realizará la secuencia necesaria para añadir en el servidor maestro un cuarto host bajo el dominio "alfa": h4.alfa (con dirección IPV4 10.13.0.4 e IPV6 2001:db8:13::4):

root@host# vnumlparser.pl -x aptdo3B@dns.xml -v

Deje pasar unos minutos hasta observar en alfa tráfico procedente de alfa2. Para comprobar que el cambio ha sido efectivo en ambos, ejecute (capturando también en la interfaz del host con el escenario "red1"):

root@host# dig @10.1.1.2 -t A h4.alfa (que realiza la consulta en la máquina alfa)

root@host# dig @10.1.1.12 -t A h4.alfa (que realiza la consulta en la máquina alfa2)

Ambos deben responder sin acudir a otro servidor de nombres. La actualización de la zona en alfa2 ha sido, por tanto, automática. También puede observar el contenido del fichero de la zona "alfa" con un editor de textos:

alfa/alfa2# vi /etc/bind/db.alfa

(Puede encontrar la captura correspondiente a ambas peticiones en red1_3_4.cap y la correspondiente al interfaz del esclavo en red1_3_5.cap)

¿Qué ha observado en el esclavo?

• Por último analizaremos el caso en que el servidor maestro dejara de funcionar.

Realice desde el host la misma consulta sobre una máquina bajo el dominio alfa en varias ocasiones. No olvide ejecutar previamente en la máquina virtual Root el comando "rndc flush". Repita, por ejemplo, la siguiente consulta:

root@host# dig @10.1.1.1 -t A h1.d2.alfa

¿Qué servidor con autoridad sobre "alfa" es consultado por el servidor de nombres raíz? (Ver captura red1_3_6.cap)

Ahora pare el servicio DNS en la máquina alfa:

alfa# killall named

Y realice la misma consulta en varias ocasiones sin olvidar ejecutar cada vez previamente en la máquina virtual Root el comando "rndc flush":

root@host# dig @10.1.1.1 -t A h1.d2.alfa

¿Qué ocurre en este caso con la consulta del servidor raíz a cerca del dominio "alfa"? (Puede comprobarlo en la captura red1_3_7.cap, donde se muestran los dos casos de consultas).

Apéndice I

En las siguientes tablas se muestra toda la información necesaria en cuanto a la configuración de la jerarquía y autoridades de los servidores de nombres:

	Root	alfa	beta	d1.alfa	d2.alfa	d1.beta
Name server:	ns.	ns.alfa.	ns.beta.	ns.d1.alfa.	ns.d2.alfa.	ns.d1.beta.
Name server IPV4:	10.1.1.1	10.1.1.2	10.1.1.3	10.1.1.4	10.1.1.5	10.1.1.6
Name server IPV6:	2001:db8::1	2001:db8::2	2001:db8::3	2001:db8::4	2001:db8::5	2001:db8::6
Authoritative for direct domains (IPV4/IPV6):	.	.alfa.	.beta.	.d1.alfa.	.d2.alfa.	.d1.beta.
Authoritative for inverse domains (IPV4):	0.0.0.0/0	10.0.0.0/8	20.0.0.0/8	10.1.0.0/16	10.2.0.0/16	20.1.0.0/16
Authoritative for inverse domains (IPV6):	::/0	2001:db8::/32	2002:db8::/32	2001:db8:1::/48	2001:db8:2::/48	2002:db8:1::/48
Prefixes used by local hosts (IPV4):	30.0.0.0/8	10.0.0.0/8	20.0.0.0/8	10.1.0.0/16	10.2.0.0/16	20.1.0.0/16
Prefixes used by local hosts (IPV6):	2003:db8::/32	2001:db8::/32	2002:db8::/32	2001:db8:1::/48	2001:db8:2::/48	2002:db8:1::/48
Example host locally registered:	h1. 30.0.0.1 2003:db8::1	h1.alfa. 10.13.0.1 2001:db8:d::1	h1.beta. 20.13.0.1 2002:db8:d::1	h1.d1.alfa. 10.1.13.1 2001:db8:1:d::1	h1.d2.alfa. 10.2.13.1 2001:db8:2:d::1	h1.d1.beta. 20.1.13.1 2002:db8:1:d::1

	d2.beta	sd1.d1.alfa	sd1.d2.alfa	sd2.d2.alfa	sd1.d2.beta
Name server:	ns.d2.beta.	ns.sd1.d1.alfa.	ns.sd1.d2.alfa.	ns.sd2.d2.alfa.	ns.sd1.d2.beta.
Name server IPV4:	10.1.1.7	10.1.1.8	10.1.1.9	10.1.1.10	10.1.1.11
Name server IPV6:	2001:db8::7	2001:db8::8	2001:db8::9	2001:db8::a	2001:db8::b
Authoritative for direct domains (IPV4/IPV6):	.d2.beta.	.sd1.d1.alfa.	.sd1.d2.alfa.	.sd2.d2.alfa.	.sd1.d2.beta.
Authoritative for inverse domains (IPV4):	20.2.0.0/16	10.1.1.0/24	10.2.1.0/24	10.2.2.0/24	20.2.1.0/24
Authoritative for inverse domains (IPV6):	2002:db8:2::/48	2001:db8:1:1::/56	2001:db8:2:1::/56	2001:db8:2:2::/56	2002:db8:2:1::/56
Prefixes used by local hosts (IPV4):	20.2.0.0/16	10.1.1.0/24	10.2.1.0/24	10.2.2.0/24	20.2.1.0/24
Prefixes used by local hosts (IPV6):	2002:db8:2::/48	2001:db8:1:1::/56	2001:db8:2:1::/56	2001:db8:2:2::/56	2002:db8:2:1::/56
Example host locally registered:	h1.d2.beta. 20.2.13.1 2002:db8:2:d::1	h1.sd1.d1.alfa. 10.1.1.13 2001:db8:1:1:d::1	h1.sd1.d2.alfa 10.2.1.13 2001:db8:2:1:d::1	h1.sd2.d2.alfa. 10.2.2.13 2001:db8:2:2:d::1	h1.sd1.d2.beta. 20.2.1.13 2002:db8:2:1:d::1