Universidad Rey Juan Carlos Curso 2008/2009 Resumen Estos ejercicios estan orientados a entender el funcionamiento de DNS y HTTP. 1. Introduccion: escenario DNS-HTTP-lab Para la realizacion de los siguientes ejercicios es necesario descomprimir el chero DNS-HTTP-lab.tgz en la cuenta de usuario de la siguiente forma: usuario@alphaXX:~$ tar xzvf DNS-HTTP-lab.tgz Al descomprimir este chero se generara un directorio DNS-HTTP-lab con los archivos de conguracion de esta practica necesarios para NetGUI. Al arrancar NetGUI, debes abrir el escenario denido dentro del directorio DNS-HTTP-lab (en el men u Archivo->Abrir, seleccionar en la caja Nombre de archivo el directorio DNS-HTTP-lab recien creado). 2. DNS 2.1. Introduccion a la practica de DNS 2.1.1.
Arbol de dominios El escenario denido en DNS-lab esta formado por 4 routers y 7 maquinas. Dentro de este escenario existen los siguientes dominios (vease la gura 1): Dominio raz donde se encuentra la maquina dnsroot. 1 Dominio raz Dominio com Dominio net Dominio emp1.com Dominio emp2.net Figura 1:
Arbol de dominios Dominio com: donde se encuentran los routers r1 y r2 y la maquina dnscom. Por tanto, el nombre completo para ellos es: r1.com, r2.com y dnscom.com respectivamente. Dominio emp1.com: donde se encuentran las maquinas pc1 y dnsemp1. Por tanto, el nombre completo para ellas es: pc1.emp1.com y dnsemp1.emp1.com respectivamente. Dominio net: donde se encuentran los routers r3 y r4 y la maquina dnsnet. Por tanto, el nombre completo para ellos es: r3.net, r4.net y dnsnet.net respectivamente. Dominio emp2.net: donde se encuentran las maquinas pc2 y dnsemp2. Por tanto, el nombre completo para ellas es: pc2.emp2.net y dnsemp2.emp2.net respectivamente. 2 2.1.2. Servidores de DNS El programa que vamos a utilizar como servidor de DNS es bind. Los cheros de conguracion de bind que vamos a utilizar son: named.conf: chero que especica la conguracion general del servidor de DNS: dominios para los que ese servidor es maestro, esclavo, etc y nombres de los cheros que contienen los mapas de dominio de ese servidor. db.root: chero que contiene la direccion IP del servidor de DNS del dominio raz. En el caso del servidor de DNS raz este chero es el que contiene el mapa de dominio raz, .. db.*: mapas de dominio. En las siguientes maquinas se ha congurado bind para que funcionen como servidores de DNS: dnsroot: Servidor de nombres raz (archivos /bind/named.conf y /bind/db.root). dnscom: Servidor de nombres del dominio com (archivos /bind/named.conf, /bind/db.root y /bind/db.com). dnsemp1: Servidor de nombres del dominio emp1.com (archivos /bind/named.conf, /bind/db.root y /bind/db.com.emp1). dnsnet: Servidor de nombres del dominio net (archivos /bind/named.conf, /bind/db.root y /bind/db.net). dnsemp2: Servidor de nombres del dominio emp2.net (archivos /bind/named.conf, /bind/db.root y /bind/db.net.emp2). 2.1.3. Conguracion de resolucion de nombres en las maquinas Todas las maquinas del escenario, si necesitan una operacion de resolu- cion de nombres, primero consultaran su chero local /etc/hosts y si no encuentran la respuesta, consultaran su servidor de DNS. Las maquinas pc1 y dnsemp1 tienen congurado como servidor de DNS a dnsemp1. Las maquinas pc2 y dnsemp2 tienen congurado como servidor de DNS a dnsemp2. La maquina dnscom y los routers r1 y r2 tienen congurado como servidor de DNS a dnscom. La maquina dnsnet y los routers r3 y r4 tienen congurado como servidor de DNS a dnsnet. Esta conguracion puede consultarse en el chero resolv.conf de cada maquina y router. 3 2.1.4. Programa host Utilizaremos el programa host para la realizacion de los ejercicios. Este programa es una herramienta que permite realizar consultas a un servidor de DNS. Usaremos este programa de la siguiente forma: host <nombreDeMaquina> El programa host devolvera la direccion IP asociada a <nombreDeMaquina> (resultado de haber consultado primero en el chero /etc/hosts o de haber enviado un mensaje de solicitud de resolucion al servidor de DNS que tenga congurado la maquina donde se ejecuta el programa). 2.1.5. Realizacion de capturas de traco Las capturas de traco que se realizaran en las maquinas virtuales se ob- tendran ejecutando el siguiente comando en en la/s maquina/s que consideres necesario: tcpdump -s 0 -i <interfazDeRed> -w <nombreDeFichero> Donde la opcion -s 0 indica que han de capturarse los mensajes comple- tos, si no, tcpdump solo capturara el principio de cada mensaje. La opcion -i se utiliza para especicar la interfaz de red donde se quiere realizar la captura (eth0, eth1, etc). Finalmente, la opcion -w se utiliza para guardar los mensajes captura- dos en un chero. Lo mejor es guardar la captura en un chero fuera de la maquina virtual, es decir, en tu directorio de usuario, ya que utilizaremos el programa wireshark para visualizar los mensajes capturados y este progra- ma se encuentra instalado fuera de las maquinas virtuales. Para ello, deberas indicar que el chero ha de almacenarse en el directorio /hosthome. El di- rectorio /hosthome en una maquina virtual se corresponde con tu directorio de usuario en la maquina real. Por ejemplo, podras realizar una captura de la siguiente forma: tcpdump -s 0 -i eth0 -w /hosthome/dns1.cap Para interrumpir la captura puedes hacerlo utilizando Ctrl+C. El programa wireshark instalado en las maquinas reales te permite visua- lizar un chero de captura de forma graca. Para ello, deberas arrancar esta aplicacion en la maquina real y cargar el chero dns1.cap que se encuentra en tu directorio de usuario. 4 2.2. Resolucion de nombres Arranca las maquinas del escenario denido en DNS-lab de una en una y responde a las siguientes preguntas: 1. Imagina que ocurrira si la maquina pc1 ejecuta host pc2.emp2.net. Cuantos mensajes de DNS se generaran y entre que maquinas? Es importante que consideres que es la primera consulta que se realiza en ese escenario (las caches de los servidores de DNS estan vacas). 2. Ejecuta la instruccion anterior en pc1, realizando las capturas de traco que consideres necesarias para ver todos los mensajes de DNS genera- dos 1 . Al menos deberas realizar una captura en la red 12.0.0.0/24 ya que es ah donde se encuentra conectado pc1, que es la maquina que va a enviar el primer mensaje de consulta. La captura en la red 12.0.0.0/24 la podras obtener ejecutando tcpdump en cualquiera de las maquinas que estan conectadas directamente a esta red, por ejemplo, podras realizar la captura en la interfaz eth1 de r1. Observa en la captura como el mensaje de consulta que enva pc1 tiene activado el ag Recursion desired para que la consulta sea recursiva y los mensajes de consulta que enva dnsemp1 no tienen activado el ag Recursion desired para que la consulta se realice de forma iterativa. Observa en la/s captura/s el valor TTL (Time To Live) de la respuesta obtenida en pc1. Para cada uno de los mensajes de respuesta que observes, explica que lnea/s de cada uno de los mapas de dominio (db.*) proporcio- nan la informacion que viaja en dichos mensajes. 3. Supon que ocurrira si despues de haber realizado la consulta anterior, en pc1 se solicita de nuevo la resolucion de pc2.emp2.net. Cuantos mensajes de DNS se generaran y entre que maquinas? Por que? 4. Ejecuta la resolucion anterior en pc1, realizando las capturas de traco que consideres necesarias para ver todos los mensajes de DNS genera- dos. Explica el valor TTL (Time To Live) de la respuesta obtenida en pc1. Comparalo con el valor obtenido en el apartado 2. 1 Recuerda que si realizas mas de una consulta a un servidor de DNS, este almacena informacion en su cache. Para borrar la cache de un determinado servidor de DNS puedes ejecutar en dicho servidor el comando: /etc/init.d/bind restart. Este comando reiniciara el servidor de DNS, borrando su cache. 5 5. Imagina que ocurrira si despues de haber realizado las consultas an- teriores, en pc1 se solicita la resolucion de r4.net. Cuantos mensajes de DNS se generaran y entre que maquinas? 6. Ejecuta la resolucion anterior en pc1, realizando las capturas de traco que consideres necesarias para ver todos los mensajes de DNS genera- dos. 7. Imagina que ocurrira si en pc1 se solicita la resolucion del nombre pc200.emp1.com. Cuantos mensajes de DNS se generaran y entre que maquinas? 8. Ejecuta la resolucion anterior en pc1, realizando las capturas de traco que consideres necesarias para ver todos los mensajes de DNS genera- dos. 2.3. Servidor esclavo Modica la conguracion de dnsnet para que se convierta en un servidor secundario del dominio emp2.net. Para ello, en la maquina dnsnet mueve el chero /etc/bind/named.conf2 a /etc/bind/named.conf. Deberas rei- niciar el servidor de DNS de dnsnet ejecutando la siguiente instruccion en esta maquina: /etc/init.d/bind restart 1. Crees que las resoluciones que realice pc1 se veran beneciadas por este cambio? Explica por que. 2. Realiza los siguientes cambios en el mapa db.net.emp2 del servidor maestro: Modica el registro A para que asocie el nombre pc200.emp2.net a la direccion IP 14.0.0.200. No hace falta que crees este nuevo pc en el dibujo. Modica el ultimo valor del n umero de serie dentro del registro SOA, para indicar que el chero se ha actualizado. Reinicia solo los siguientes servidores: el servidor de DNS maestro del dominio emp2.net (para que cargue el nuevo mapa) y el servidor de DNS de dnsemp1 (para que borre la cache de este servidor). Realiza la resolucion de pc200.emp2.net desde pc1 y tambien desde pc2. Explica el resultado. 6 Que crees que ocurrira si se reinicia el servidor de DNS de dnsnet? Compruebalo. 2.4. Servidor forward Vamos a congurar dnsemp1 para que funcione como un servidor que realiza las consultas en modo recursivo en vez de iterativo. Por tanto, todas las consultas que reciba dnsemp1 seran reenviadas a otro servidor de DNS diferente, en nuestro caso el servidor dnsnet. En la maquina dnsemp1 mueve el chero named.conf2 a named.conf y reinicia el servidor de DNS. Que crees que ocurrira si pc1 solicita la resolucion de pc2.emp2.net? Realiza las capturas que consideres necesarias para obtener todo el traco generado de dicha resolucion y comprueba tus suposiciones 2 . 3. HTTP 3.1. Conexiones HTTP no persistentes Para ver el funcionamiento de las conexiones HTTP no persistentes vamos a descargar en pc1 la pagina web index.html que se encuentra alojada en el directorio /var/www/ de pc2. Antes de realizar la transferencia, responde a las siguientes preguntas: Cuantas conexiones TCP crees que se estableceran para que pc1 se descargue la pagina index.html de pc2? Por que? Arranca el programa tcpdump, por ejemplo en la interfaz eth0 de r1, para capturar todos los paquetes relacionados con esta transferencia. Inicia el servidor de web en la maquina pc2, para ello utilizaremos la aplicacion apache. Para arrancar el servidor de web utilizaremos el siguiente comando en pc2: /etc/init.d/apache start 2 No consideres los mensajes de peticion y respuesta de resoluciones inversas que obser- ves, registros PTR. 7 Este servidor esta sirviendo las paginas que se encuentran en el directorio /var/www/ de la maquina pc2. A continuacion utilizaremos el programa wget desde pc1 para acceder a las paginas del servidor de web en pc2. Este programa no es un navegador de web, es una herramienta para descargar paginas web de un servidor, por ejemplo se utiliza para descargar un sitio web completo. Para ejecutar wget utilizaremos el siguiente comando en pc1: wget -r http://pc2.emp2.net/index.html Este comando se conectara a la maquina pc2.emp2.net y al puerto 80 y descargara la pagina index.html. Comprueba que se ha descargado la informacion en pc1 y se ha almacenado en el directorio pc2.emp2.net. Carga en Wireshark la captura que has realizado. Observaras que Wireshark interpreta algunos de los paquetes capturados como traco HTTP. Cuando un mensaje HTTP ocupa mas de un segmento TCP Wireshark muestra el siguiente mensaje: [TCP segment of a reassembled PDU] Cuando Wireshark interpreta que se ha recibido todo el mensaje HTTP, como resultado de haber recibido previamente un conjunto de segmentos TCP segment of a reassembled PDU, Wireshark concatena todos estos seg- mentos para mostrar el mensaje HTTP completo. Observando la captura de traco que has realizado: Cuantas conexiones TCP se han establecido entre pc1 y pc2 al reali- zarse la descarga con wget? Por que? 3.2. Conexiones HTTP persistentes Vamos a realizar la misma transferencia que en el apartado anterior, pero congurando el servidor de web para que utilice conexiones HTTP persisten- tes. Antes de realizar la transferencia, responde a las siguientes preguntas: Cuantas conexiones TCP crees que se estableceran si pc1 realiza la misma descarga que en el apartado anterior pero ahora utilizando cone- xiones HTTP persistentes? 8 Para congurar el servidor de web de pc2 para que utilice conexiones HTTP persistentes, primero, interrumpe la ejecucion del servidor con el si- guiente comando en pc2: /etc/init.d/apache stop Copia el chero /etc/apache/httpd2.conf en /etc/apache/httpd.conf, y reinicia el servidor de web de pc2: /etc/init.d/apache start En pc1 borra los cheros descargados en el apartado anterior para ver como se descargan otra vez. Arranca de nuevo tcpdump para capturar todos los paquetes relacionados con la descarga que vas a realizar a continuacion. Realiza la descarga desde pc1 ejecutando de nuevo el siguiente comando: wget -r http://pc2.emp2.net/index.html Observando la captura de traco que has realizado: Cuantas conexiones TCP se han establecido entre pc1 y pc2 al reali- zarse la descarga con wget? Por que? Puedes apreciar si se ha ahorrado tiempo de descarga con respecto a la descarga con conexiones HTTP no persistentes? 3.3. Proxy HTTP En este apartado vamos a arrancar un proxy HTTP con cache en la maquina r1 y vamos a realizar la misma descarga que en los apartados ante- riores: pc1 va a descargar la pagina index.html de pc2, pero en esta ocasion a traves del proxy HTTP con cache que arrancaremos en r1. Antes de realizar la descarga: Cuantas conexiones TCP crees que se van a necesitar para realizar la descarga descrita? Supon que se utilizan conexiones HTTP no persis- tentes. Si se vuelve a repetir la descarga desde pc1, cuantas conexiones TCP crees que se van a necesitar para realizar la descarga descrita? Supon que se utilizan conexiones HTTP no persistentes. 9 Arranca todos los procesos tcpdump que consideres necesarios para cap- turar todo el traco HTTP de la descarga que vamos a realizar usando el proxy HTTP de r1. Dado que tienes el servidor de web en pc2 arrancado del apartado anterior, no es necesario que lo reinicies. Para arrancar el proxy HTTP en la maquina r1 vamos a utilizar de nuevo la aplicacion apache que puede funcionar como servidor HTTP y como ser- vidor de proxy. Se han modicado los cheros de conguracion de apache en r1 para que funcione como proxy HTTP. Utiliza el siguiente comando para arrancar el proxy HTTP en r1: /etc/init.d/apache start El proxy HTTP esta esperando recibir conexiones en el puerto 8080. El directorio en el que almacena la cache Apache es /var/cache/apache. Para que wget utilice el proxy HTTP congurado en r1, es necesario edi- tar el chero de conguracion .wgetrc de pc1 para que la lnea http_proxy no aparezca comentada. Para editar este chero puedes utilizar el editor mcedit. En pc1 borra los cheros descargados en el apartado anterior para ver como se descargan otra vez. A continuacion, realiza la descarga desde pc1: wget -r http://pc2.emp2.net/index.html Observando la/s captura/s de traco que hayas realizado: Cuantas conexiones TCP se han establecido para realizar la descarga descrita? Explcalas. Arranca todos los procesos tcpdump que consideres necesarios para cap- turar todo el traco HTTP de una nueva descarga entre pc1 y pc2 que vamos a realizar usando el proxy HTTP de r1. Repite la descarga anterior, para que pc1 obtenga de nuevo la pagina index.html de pc2. Observando la/s captura/s de traco que hayas realizado: Cuantas conexiones TCP se han establecido para realizar la descarga descrita? Explcalas. Que implicacion tiene el uso de la cache de r1 en los mensajes HTTP que se intercambian? 10