Seminario de Redes TRABAJO PRACTICO Nº 2. DIG y NSLOOKUP. deimos_azul@yahoo.com Padrón: gonzalojosa@hotmail.

Transcripción

1 Departamento de Electrónica Facultad de Ingeniería Seminario de Redes TRABAJO PRACTICO Nº 2 DIG y NSLOOKUP Grupo: NMNK Responsable a cargo: Integrantes: Guzmán Pegazzano, Ma. Azul deimos_azul@yahoo.com Padrón: Josa Scorza, Gonzalo gonzalojosa@hotmail.com Padrón: Rodríguez Palacios, Agustina apalaci@fi.uba.ar Padrón: 77677

2 Introducción. El objetivo de este trabajo práctico es utilizar las herramientas dig y nslookup para poder analizar las distintas características del sistema DNS. Los protocolos a utilizar serán IP, ICMP y UDP. Los comandos dig y nslookup se basan en el sistema DNS (Domain Name System). Este sistema se utiliza para obtener una direccion IP a partir del nombre del host y visceversa, y para proveer la informacion de una ruta. Los mensajes DNS viajan sobre UDP salvo cuando se realiza lo que se llama un zone transfer que lo hacen sobre TCP. Para nuestros fines prácticos, se utilizara UDP. HEADER IP HEADER UDP DNS HEADER DNS utiliza lo que se llama delegación de autoridad esto es, ninguna entidad maneja todas las etiquetas del árbol jerárquico de DNS sino que una entidad se encarga de una zona especifica del árbol (top-level domains) delegando otras responsabilidades hacia otras zonas. Una vez que la responsabilidad ha sido delegada, es responsabilidad del administrador de esa zona proveer múltiples servidores de nombre para esa zona. Un servidor de nombre puede ser autoritativo para una o varias zonas. La persona responsable de la zona provee un servidor de nombre primario y uno o mas servidores de nombre secundarios para esa zona; siendo primarios y secundarios independientes entre ellos. No todos los servidores conocen como contactar a otro servidor de nombre, pero si saben como contactar a la raíz de los servidores. Todos los servidores primarios deben saber la dirección IP del servidor raíz para poder contactarlo. Para cada dominio existe un servidor autoritativo. Este servidor es quien conoce toda la información correspondiente a este dominio. En caso de que se realice una consulta sobre algún host perteneciente a su dominio, será él quien responda, generando así una respuesta del tipo autoritativa. En caso de que se le realice una consulta sobre un host que no pertenezca a su dominio, pueden ocurrir dos situaciones: - Que no tenga disponible la información, y por lo tanto deba obtenerla del servidor que posee autoridad sobre ese dominio, generando así una respuesta autoritativa. En este caso la información quedará almacenada en su caché; con lo cual, las siguientes consultas sobre este dominio serán no autoritativas. - Que tenga almacenada la información en el caché generando así una respuesta no autoritativa. La respuesta no autoritativa puede ser recursiva o iterativa. En el caso de ser recursiva, el servidor al cual se ha realizado la consulta se encarga de devolver la respuesta aunque él no posea esa información; en ese caso hará las consultas necesarias a otros servidores para poder resolver la pregunta. En el otro caso, el servidor envía al 2

3 host una lista con las direcciones de servidores de nombre a quienes se debe consultar por ese dominio. Las respuestas autoritativas son siempre recursivas. 3

4 El formato de un mensaje DNS es el siguiente: IDENTIFICACION NUMERO DE PREGUNTA NUMERO DE AUTORIDAD RRs FLAGS NUMERO DE RESPUESTAS RRs NUMERO DE RRs ADICIONALES PREGUNTAS RESPUESTAS AUTORIDAD INFORMACION ADICIONAL El formato del campo PREGUNTAS es el siguiente: NOMBRE DE LAS PREGUNTAS TIPO DE PREGUNTA. CLASE DE PREGUNTA El campo nombre de preguntas es el nombre por el cual se esta preguntando. El campo clase de pregunta casi siempre está en 1 indicando que se refiere a una dirección de internet. El campo tipo de pregunta toma diferente valor de acuerdo al tipo de pregunta que se este realizando: Nombre Valor Descripcion A 1 IP address NS 2 Name server CNAME 5 Canonical name PTR 12 Pointer record HINFO 13 Host info MX 15 Mail exchange record Los últimos tres campos del mensaje DNS (respuesta, autoridad e información adicional), comparten un formato comun llamado Resource Record, RR. 4

5 El formato de las tramas de mensaje de respuesta de un RR es el siguiente: NOMBRE DE DOMINIO TIPO CLASE TIEMPO DE VIDA LONGITUD DE DATOS DEL REGISTRO DATOS DEL REGISTRO El campo de nombre de dominio corresponde al nombre con el cual se corresponden los datos de registro. El tipo especifica el codigo asociado al RR. La clase es en general 1 indicando datos de Internet. El campo TTL es el número de segundos que el RR puede ser cacheado por el cliente. El valor típico es de 2 segundos. La longitud de datos del registro especifica la cantidad de datos del registro. El formato de este campo depende del tipo de registro. Otro de los campos que figuran en el formato de mensaje DNS es el de autoridad. En él se copia un número variable de RR, en particular el registro SOA. SOA Este registro está compuesto por los siguientes campos: Nombre: Nombre de la zona. Origen: Nombre del host en el cual se encuentra la información Persona a cargo: dirección de mail de la persona responsable por el servidor de nombre Numero de Serie: Número de versión del archivo de datos. El mismo debe incrementarse al realizarse una actualización. Refresh time: Es el tiempo (en seg.) que espera un servidor secundario antes de chequear con el servidor primario si necesita una actualización. Retry time: Es el tiempo (en seg.) que un servidor secundario debe esperar antes de reintentar una zone transfer ante una actualización fallida. Expire time: Es el tiempo límite máximo que el servidor secundario continúa reintentando realizar el zone transfer. Minimum time: Es el tiempo mínimo por default para ser usado en los TTL de los RR. Sólo puede haber un registro SOA por zona. 5

6 NSLOOKUP Uno de los comando utilizados en este trabajo práctico es el NSLOOKUP. Este comando se utiliza para preguntar a servidores de nombre de Internet acerca de direcciones y nombres asociados a diferentes hosts. Este comando posee dos modos: interactivo y no-interactivo. El modo interactivo permite al usuario preguntar a servidores de nombres por informacion sobre varios hosts y dominios o imprimir una lista de hosts en un dominio dado. El modo no-interactivo se utiliza para imprimir solamente el nombre y la información solicitada sobre un host o un dominio. La sintaxis de este comando es la siguiente: nslookup [ -option... ] [ host-to-find - [ server ]] El modo interactivo se utiliza en los siguientes casos: - cuando no se especifica ningún argumento (se utiliza el servidor de nombre seteado por default) - cuando el primer argumento es un guión ( - ) y el segundo argumento es el nombre del host o la dirección IP de un servidor de nombre. El modo no-interactivo se utiliza cuando el nombre o la dirección IP del host a ser buscado es el primer argumento. El segundo argumento opcional especifica el nombre o la dirección del servidor de nombre. DIG. Otro de los comandos utilizados es el DIG, el cual está reemplazando al anterior ya que posee más opciones de consulta. Este comando tiene la siguiente sintaxis: dig [@server] domain [<query-type>] [<query-class>] [+<query-option>] [-<dig-option>] [%comment] El comando DIG (domain information groper) se utiliza también, para obtener información de un sistema de servidores de nombres. Este comando posee dos modos: modo interactivo simple (para una sola pregunta) y modo de procesamiento (batch mode) el cual realiza una consulta por cada línea de una lista de preguntas. El modo mas común de utilizar este comando es el siguiente: donde: domain query-type query-class server : puede ser tanto el nombre o la dirección IP del servidor a consultar. Si este campo se omite, el comando dig utilizará el servidor de nombre que tiene seteado por default el host. domain: es el nombre de dominio o dirección IP por el cual se solicita información. query-type: especifica el tipo de registro que se solicita. 6

7 query-class: es la clase de red por la que se pregunta 7

8 Maqueta. Para el desarrollo de las pruebas se utilizará la siguiente maqueta. Dependiendo del escenario en cuestión, se utilizará una parte de la maqueta en especial, la cual será especificada en el escenario correspondiente, es decir, la siguiente es la maqueta más general utilizándose ciertos sectores de la misma en cada caso. FI.UBA SERVER ETH. A: / PC2 PC3 PC1 INTERNET + PC L14 MDM DNS Server Descripción de los equipos utilizados. PC1: Windows XP. Ethereal. PC2: Windows 98. Ethereal. PC3: Linux Red Hat 7.2 PCL14: Linux. 8

9 Escenario I. DNS sobre UDP Objetivo: El objetivo de este escenario es observar que DNS utiliza generalmente como base el protocolo de capa de aplicación UDP. Desarrollo: Para lograr el objetivo se enviará un ping desde la PC 3 hacia y se capturará el tráfico resultante. Como hemos visto en el TP 1, el comando ping necesita de la dirección IP consultada para enviar el datagrama IP, con lo cual primero deberá realizar una consulta DNS acerca de la dirección IP asociada a este nombre. Esta consulta es la que se espera capturar y analizar. La consulta DNS viajará sobre un segmento UDP siendo los puertos del mismo un puerto efímero cualquiera en la PC origen y el puerto 53 en el destino. Ejecución: A partir del ping enviado se obtuvo la siguiente salida: [Gonza@localhost Gonza]$ ping PING ( ) from : 56(84) bytes of data. 64 bytes from p14. ( ): icmp_seq=1 ttl=51 time=328 ms 64 bytes from p14. ( ): icmp_seq=2 ttl=51 time=314 ms 64 bytes from p14. ( ): icmp_seq=3 ttl=51 time=316 ms 64 bytes from p14. ( ): icmp_seq=4 ttl=51 time=317 ms 64 bytes from p14. ( ): icmp_seq=5 ttl=51 time=319 ms ping statistics packets transmitted, 5 received, 0% loss, time 4035ms rtt min/avg/max/mdev = / / /4.919 ms [Gonza@localhost Gonza]$ 9

10 La traza perteneciente a la consulta DNS es la siguiente: Podemos observar que el mensaje DNS viaja en la parte de datos de un segmento UDP. El puerto destino es el 53 correspondiente al sistema DNS; en tanto el puerto origen es el puerto efímero Conclusiones: Pudimos verificar que el sistema DNS utiliza como medio de transporte el protocolo UDP siempre que el mensaje DNS no sea demasiado extenso. El puerto asociado es el número 53. No pudimos verificar el uso del protocolo TCP como medio de transporte ya que nuestras consultas no generaron respuestas lo suficientemente extensas. Tampoco podemos realizar un zone transfer, en donde siempre se utiliza TCP. 10

11 Escenario II. Consulta DNS sobre registro tipo A. Objetivo: El objetivo de este escenario es observar la respuesta que se obtiene ante una consulta sobre un registro tipo A. Se analizará tanto el formato de la consulta como el de la respuesta. Desarrollo: Para generar esta consulta se utilizará el comando DIG especificando que se desea obtener la dirección IP asociada al nombre dado. Esto se realiza utilizando la siguiente línea de comando: -t A Ejecución: Se generó el comando dig con la opción t A a la cual especifica el tipo de RR por el cual se desea consultar a ese dominio. En este caso t A indica que se consulta por un RR tipo A. La información obtenida fue la siguiente: [Gonza@localhost Gonza]$ -t a ; <<>> DiG t a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6587 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 9, ADDITIONAL: 9 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME IN A IN A IN A IN A IN A IN A IN A IN A ;; AUTHORITY SECTION: akadns.net IN NS zc.akadns.net. akadns.net IN NS zf.akadns.net. akadns.net IN NS zh.akadns.net. 11

12 akadns.net IN NS ns1-159.akam.net. akadns.net IN NS use2.akam.net. akadns.net IN NS usw5.akam.net. akadns.net IN NS use4.akam.net. akadns.net IN NS asia3.akam.net. akadns.net IN NS a-93.akadns.net. ;; ADDITIONAL SECTION: zc.akadns.net IN A zf.akadns.net IN A zh.akadns.net IN A ns1-159.akam.net IN A use2.akam.net IN A usw5.akam.net IN A use4.akam.net IN A asia3.akam.net IN A a-93.akadns.net IN A ;; Query time: 175 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 11:55: ;; MSG SIZE rcvd: 511 [Gonza@localhost Gonza]$ Conclusiones: Por lo que observamos, en el paquete de la respuesta se copia también la pregunta. Al consultar por la dirección IP, se obtuvo en primer lugar el CNAME asociado ya que en este caso es un alias de Luego sí, la dirección que se obtuvo fue la de este último nombre. Vemos también que hay varias direcciones IP asociadas a él, las cuales suponemos que corresponden a distintos servidores que responden bajo el mismo nombre. 12

13 Escenario III. Consulta DNS sobre registro tipo MX. Objetivo: El objetivo de este escenario es observar la respuesta que se obtiene ante una consulta sobre un registro tipo MX. Se analizarán tanto el formato de la consulta como de la respuesta. Desarrollo: Para generar esta consulta se utilizará el comando DIG especificando que se desea obtener la dirección del servidor de mail asociado con el dominio consultado. Esto se realiza utilizando la siguiente línea de comando: Ejecución: -t MX La consulta se realizó a Hotmail ya que posee varios servidores de mail asociados por brindar un servicio de estas características. El resultado obtenido fue el siguiente: [Gonza@localhost Gonza]$ -t mx ; <<>> DiG t mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 18 ;; QUESTION SECTION: ; IN MX ;; ANSWER SECTION: IN MX 5 mx4.hotmail.com IN MX 5 mx1.hotmail.com IN MX 5 mx2.hotmail.com IN MX 5 mx3.hotmail.com. ;; AUTHORITY SECTION: hotmail.com IN NS ns1.hotmail.com. hotmail.com IN NS ns2.hotmail.com. hotmail.com IN NS ns3.hotmail.com. hotmail.com IN NS ns4.hotmail.com. ;; ADDITIONAL SECTION: mx4.hotmail.com IN A mx4.hotmail.com IN A mx4.hotmail.com IN A mx1.hotmail.com IN A mx1.hotmail.com IN A mx1.hotmail.com IN A

14 mx1.hotmail.com IN A mx2.hotmail.com IN A mx2.hotmail.com IN A mx2.hotmail.com IN A mx3.hotmail.com IN A mx3.hotmail.com IN A mx3.hotmail.com IN A mx3.hotmail.com IN A ns1.hotmail.com IN A ns2.hotmail.com IN A ns3.hotmail.com IN A ns4.hotmail.com IN A ;; Query time: 411 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 11:56: ;; MSG SIZE rcvd: 473 Conclusiones: A partir del análisis de los paquetes, observamos que existe más de un servidor de mail asociado con igual número de prioridad. Esperábamos obtener varios MX asociados pero con distinto número de preference. Como información adicional se obtuvieron las direcciones IP asociadas a los mismos, junto con los servidores de nombre que responden a ese dominio. 14

15 Escenario IV. Consulta DNS sobre registro tipo PTR. Objetivo: El objetivo de este escenario es observar la respuesta que se obtiene ante una consulta sobre un registro tipo PTR. Se analizarán tanto el formato de la consulta como de la respuesta. Desarrollo: Para generar esta consulta se utilizará el comando DIG especificando que se desea obtener el nombre asociado a la dirección IP dada (-x [dirección IP]). Del escenario 2 se obtiene la dirección IP asociada al nombre Esta será utilizada para realizar la consulta PTR esperando obtener el mismo nombre. Esto se realiza utilizando la siguiente línea de comando: -x t PTR Ejecución: La traza obtenida fue la siguiente: [Gonza@localhost Gonza]$ -x t ptr ; <<>> DiG x t ptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ; in-addr.arpa. IN PTR ;; ANSWER SECTION: in-addr.arpa IN PTR p1. ;; AUTHORITY SECTION: in-addr.arpa IN NS ns1.yahoo.com in-addr.arpa IN NS ns2.yahoo.com in-addr.arpa IN NS ns3.yahoo.com in-addr.arpa IN NS ns4.yahoo.com in-addr.arpa IN NS ns5.yahoo.com. ;; ADDITIONAL SECTION: ns1.yahoo.com IN A ns2.yahoo.com IN A ns3.yahoo.com IN A ns4.yahoo.com IN A ns5.yahoo.com IN A ;; Query time: 373 msec 15

16 ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 11:58: ;; MSG SIZE rcvd: 249 A partir de este escenario, y del escenario 2 se observa lo siguiente: FQDN IP IP FQDN FQDN IP Siendo FQDN y FQDN p1. Verificamos que las direcciones IP correspondientes a estos nombres coinciden, por lo tanto hay consistencia en la resolución de nombres. Conclusiones: Analizando este escenario encontramos que el nombre asociado a la dirección brindada no corresponde con el nombre obtenido en el segundo escenario. En el escenario 2 (en donde se consulto por el registro A), al nombre se le asocia la dirección IP , mientras que en este caso, a esa dirección se le asocia el nombre p1. Podemos concluir que a una misma dirección IP se le pueden asociar distintos nombres; debiendo existir consistencia entre las consultas A, y los registros PTR. Este punto se analizará con más detalle en el escenario 7. 16

17 Escenario V. Consulta DNS sobre registro tipo CNAME. Objetivo: El objetivo de este escenario es observar la respuesta que se obtiene ante una consulta sobre un registro tipo CNAME. Desarrollo: Para generar esta consulta se utilizará el comando DIG especificando que se desea obtener los alias asociados al nombre Esto se realiza utilizando la siguiente línea de comando: Ejecución: -t CNAME La traza resultante es: Gonza]$ -t cname ; <<>> DiG t cname ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ; IN CNAME ;; ANSWER SECTION: IN CNAME ;; AUTHORITY SECTION: yahoo.com IN NS ns1.yahoo.com. yahoo.com IN NS ns2.yahoo.com. yahoo.com IN NS ns3.yahoo.com. yahoo.com IN NS ns4.yahoo.com. yahoo.com IN NS ns5.yahoo.com. ;; ADDITIONAL SECTION: ns1.yahoo.com IN A ns2.yahoo.com IN A ns3.yahoo.com IN A ns4.yahoo.com IN A ns5.yahoo.com IN A ;; SERVER: #53( ) Conclusión: Obtuvimos el CNAME asociado al nombre el cual concuerda con el obtenido en el escenario 2. 17

18 Escenario VI. Consulta DNS sobre el registro SOA. Objetivo: El objetivo de este escenario es observar la respuesta que se obtiene ante una consulta sobre el registro SOA. Se analizarán tanto el formato de la consulta como de la respuesta. Desarrollo: Para generar esta consulta se utilizará el comando DIG especificando que se desea obtener el registro SOA asociado al servidor consultado. Esto se realiza utilizando la siguiente línea de comando: dns1.advance.com.ar -t SOA Ejecución: Los resultados a esta línea de comando fue: [Gonza@localhost Gonza]$ dns1.advance.com.ar -t soa ; <<>> DiG dns1.advance.com.ar -t soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;dns1.advance.com.ar. IN SOA ;; AUTHORITY SECTION: advance.com.ar IN SOA dns1.advance.com.ar. dominios.advance.com.ar ;; Query time: 139 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 12:00: ;; MSG SIZE rcvd: 82 18

19 Conclusiones: Según lo comentado en la introducción se observaron los diferentes campos del registro: Nombre: dominios.advance.com.ar. Origen: dns1.advance.com.ar. Número de Serie: , Refresh Time: 43200, Retry Time: 3600, Expire Time: 86400, TTL minimo: Lo que se observa es que no aparece la dirección de mail de la persona a cargo del servidor. 19

20 Escenario VII. Variedad de nombres asociados a una dirección IP. Objetivo: En este escenario deseamos hacer notar que existen varios sitios web asociados a una misma dirección IP. Desarrollo: Se realizarán 3 pedidos de registros A asociados a los nombres A continuación se realizará una consulta tipo PTR acerca de la dirección IP obtenida. Las líneas de comando a utilizar en este caso son: Ejecución: -t A -t A -t A in-addr.arpa.com -t PTR Como siempre, continuamos observando: [Gonza@localhost Gonza]$ -t a ; <<>> DiG t a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME zonazeta.com.ar. zonazeta.com.ar IN A ;; AUTHORITY SECTION: zonazeta.com.ar IN NS ns1.granitecanyon.com. zonazeta.com.ar IN NS ns2.granitecanyon.com. ;; ADDITIONAL SECTION: ns1.granitecanyon.com IN A ns2.granitecanyon.com IN A ;; Query time: 169 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 12:01: ;; MSG SIZE rcvd: 152 [Gonza@localhost Gonza]$ -t a 20

21 ; <<>> DiG t a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME siligom.com.ar. siligom.com.ar IN A ;; AUTHORITY SECTION: siligom.com.ar IN NS ns1.siligom.com. siligom.com.ar IN NS ns1.granitecanyon.com. siligom.com.ar IN NS ns2.granitecanyon.com. ;; ADDITIONAL SECTION: ns1.siligom.com IN A ns1.granitecanyon.com IN A ns2.granitecanyon.com IN A ;; Query time: 147 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 12:01: ;; MSG SIZE rcvd: 193 [Gonza@localhost Gonza]$ -t a ; <<>> DiG t a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME lmgsm.com.ar. lmgsm.com.ar IN A ;; AUTHORITY SECTION: lmgsm.com.ar IN NS ns2.granitecanyon.com. lmgsm.com.ar IN NS ns1.siligom.com. lmgsm.com.ar IN NS ns1.granitecanyon.com. ;; ADDITIONAL SECTION: ns2.granitecanyon.com IN A ns1.siligom.com IN A ns1.granitecanyon.com IN A ;; Query time: 346 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 12:01: ;; MSG SIZE rcvd:

22 Gonza]$ -x t ptr ; <<>> DiG x t ptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ; in-addr.arpa. IN PTR ;; ANSWER SECTION: in-addr.arpa IN PTR ns1.siligom.com in-addr.arpa IN PTR in-addr.arpa IN PTR dns1.maqueta.advance.com.ar. ;; AUTHORITY SECTION: in-addr.arpa IN NS dns1.maqueta.advance.com.ar. ;; ADDITIONAL SECTION: dns1.maqueta.advance.com.ar IN A ;; Query time: 172 msec ;; SERVER: #53( ) ;; WHEN: Thu Oct 23 12:01: ;; MSG SIZE rcvd: 170 Conclusiones: A distintos nombres se asocia una misma dirección IP. Cuando preguntamos por el registro PTR asociado a dicha IP, no aparecen todos los nombres que fueron consultados en un primer momento sino solo aquellos que generó el registro correspondiente. De esto se puede concluir que no existe una relación unívoca entre nombre y dirección IP. 22

23 Escenario VIII. Servidores Autoritativos y No Autoritativos. Objetivo: En este escenario se desean observar los servidores que responden sobre un dominio dado. Desarrollo: Para conocer la lista de servidores del dominio fi.uba.ar se utilizará el comando dig con la opción +trace, la cual proporciona información sobre todos los servidores asociados con cada nivel de dominio de fi.uba.ar. La opción +trace genera que la consulta sea iterativa. La línea de comando es la siguiente: Ejecución: La traza obtenida fue la siguiente: +trace [Gonza@localhost Gonza]$ +trace ; <<>> DiG trace ;; global options: printcmd IN NS J.ROOT-SERVERS.NET IN NS K.ROOT-SERVERS.NET IN NS L.ROOT-SERVERS.NET IN NS M.ROOT-SERVERS.NET IN NS I.ROOT-SERVERS.NET IN NS E.ROOT-SERVERS.NET IN NS D.ROOT-SERVERS.NET IN NS A.ROOT-SERVERS.NET IN NS H.ROOT-SERVERS.NET IN NS C.ROOT-SERVERS.NET IN NS G.ROOT-SERVERS.NET IN NS F.ROOT-SERVERS.NET IN NS B.ROOT-SERVERS.NET. ;; Received 436 bytes from #53( ) in 157 ms ar IN NS ATHEA.ar. ar IN NS CTINA.ar. ar IN NS MERAPI.SWITCH.CH. ar IN NS NS.RIPE.NET. ar IN NS NS.UU.NET. ar IN NS UUCP-GW-1.PA.DEC.COM. ar IN NS UUCP-GW-2.PA.DEC.COM. ar IN NS NS1.RETINA.ar. ;; Received 357 bytes from #53(J.ROOT-SERVERS.NET) in 321 ms uba.ar IN NS ns2.uba.ar. uba.ar IN NS intersysmty3.intersys.com.mx. uba.ar IN NS ns1.uba.ar. 23

24 ;; Received 141 bytes from #53(CTINA.ar) in 431 ms IN A fi.uba.ar IN NS ns1.fi.uba.ar. fi.uba.ar IN NS ns1.uba.ar. fi.uba.ar IN NS ns2.uba.ar. fi.uba.ar IN NS ns4.fi.uba.ar. ;; Received 183 bytes from #53(ns2.uba.ar) in 159 ms [Gonza@localhost Gonza]$ Conclusiones: Al haber seleccionado la opción +trace se logran ver (en orden jerárquico) las listas de servidores que responden a los distintos dominios que intervienen en la consulta. Lo que no es posible determinar es cual de todos los servidores es el autoritativo sobre cada dominio. La ventaja de usar la opción +trace es que el resolver de la PC es quien realiza la iteratividad de las consultas, mostrando todas las consultas que se efectuaron hasta llegar al dominio del cual se quería obtener información. 24

25 Escenario IX. Respuestas Autoritativas y No Autoritativas. Objetivo: En este escenario se desean observar las respuestas autoritativas y no autoritativas. Desarrollo: Para realizar este escenario se efectuarán sucesivas consultas sobre un mismo dominio (cuyos RRs, en principio, no deben estar almacenado en el caché) y se analizará en que casos la respuesta es autoritativa y en cuales no. La línea de comando es la siguiente: Nos daremos cuenta si la respuesta fue autoritativa si en ella aparece seteado el bit AA que significa autoritative answer. En caso contrario la respuesta será no autoritativa y este bit será igual a 0. Ejecución: La traza obtenida es la siguiente: [Gonza@localhost Gonza]$ ; <<>> DiG ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME discoverychannelconcurso.com. discoverychannelconcurso.com IN A ;; AUTHORITY SECTION: discoverychannelconcurso.com IN NS discoverychannelconcurso.com IN NS discoverychannelconcurso.com IN NS discoverychannelconcurso.com IN NS auth01.ns.discovery.com. auth02.ns.discovery.com. auth03.ns.discovery.com. auth04.ns.discovery.com. ;; ADDITIONAL SECTION: auth01.ns.discovery.com IN A auth02.ns.discovery.com IN A auth03.ns.discovery.com IN A auth04.ns.discovery.com IN A