Nslookup Dig

Departamento de Electrnica
Facultad de Ingeniera
Seminario de Redes
TRABAJO PRACTICO N 2
DIG y NSLOOKUP
Grupo: NMNK
Responsable a cargo:
Integrantes:
Guzmn Pegazzano, Ma. Azul
E-mail: deimos_azul@yahoo.com
Padrn: 77902
E-mail: gonzalojosa@hotmail.com
Padrn: 77799
Josa Scorza, Gonzalo
Rodrguez Palacios, Agustina
E-mail: apalaci@fi.uba.ar
Padrn: 77677
Seminario de Redes de Computadoras.
Grupo NMNK
Introduccin.
El objetivo de este trabajo prctico es utilizar las herramientas dig y nslookup
para poder analizar las distintas caractersticas del sistema DNS.
Los protocolos a utilizar sern 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 prcticos, se utilizara UDP.
DNS
HEADER
HEADER
UDP
HEADER IP
DNS utiliza lo que se llama delegacin de autoridad esto es, ninguna entidad
maneja todas las etiquetas del rbol jerrquico 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 mltiples 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 raz de los servidores. Todos los servidores primarios
deben saber la direccin IP del servidor raz para poder contactarlo.
Para cada dominio existe un servidor autoritativo. Este servidor es quien conoce
toda la informacin correspondiente a este dominio. En caso de que se realice una
consulta sobre algn 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 informacin, y por lo tanto deba obtenerla del
servidor que posee autoridad sobre ese dominio, generando as una
respuesta autoritativa. En este caso la informacin quedar almacenada en
su cach; con lo cual, las siguientes consultas sobre este dominio sern no
autoritativas.
- Que tenga almacenada la informacin 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 informacin; en ese caso har las consultas necesarias
a otros servidores para poder resolver la pregunta. En el otro caso, el servidor enva al
Grupo NMNK
host una lista con las direcciones de servidores de nombre a quienes se debe consultar
por ese dominio.
Las respuestas autoritativas son siempre recursivas.
Grupo NMNK
El formato de un mensaje DNS es el siguiente:
IDENTIFICACION
FLAGS
NUMERO DE PREGUNTA
NUMERO DE RESPUESTAS RRs
NUMERO DE AUTORIDAD 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
direccin de internet.
El campo tipo de pregunta toma diferente valor de acuerdo al tipo de pregunta
que se este realizando:
Nombre
A
NS
CNAME
PTR
HINFO
MX
Valor
1
2
5
12
13
15
Descripcion
IP address
Name server
Canonical name
Pointer record
Host info
Mail exchange record
Los ltimos tres campos del mensaje DNS (respuesta, autoridad e informacin
adicional), comparten un formato comun llamado Resource Record, RR.
Grupo NMNK
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 nmero de segundos que el RR puede ser cacheado por el
cliente. El valor tpico 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 nmero 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 informacin
Persona a cargo: direccin de mail de la persona responsable por el servidor de
nombre
Numero de Serie: Nmero de versin del archivo de datos. El mismo debe
incrementarse al realizarse una actualizacin.
Refresh time: Es el tiempo (en seg.) que espera un servidor secundario antes de
chequear con el servidor primario si necesita una actualizacin.
Retry time: Es el tiempo (en seg.) que un servidor secundario debe esperar antes
de reintentar una zone transfer ante una actualizacin fallida.
Expire time: Es el tiempo lmite mximo que el servidor secundario contina
reintentando realizar el zone transfer.
Minimum time: Es el tiempo mnimo por default para ser usado en los TTL de
los RR.
Slo puede haber un registro SOA por zona.
Grupo NMNK
NSLOOKUP
Uno de los comando utilizados en este trabajo prctico 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 informacin 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 ningn argumento (se utiliza el servidor de nombre seteado

por default)
cuando el primer argumento es un guin ( - ) y el segundo argumento es el nombre
del host o la direccin IP de un servidor de nombre.
El modo no-interactivo se utiliza cuando el nombre o la direccin IP del host a

ser buscado es el primer argumento. El segundo argumento opcional especifica el
nombre o la direccin del servidor de nombre.
DIG.
Otro de los comandos utilizados es el DIG, el cual est reemplazando al anterior
ya que posee ms 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 tambin, para obtener

informacin 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 lnea de una lista de preguntas.
El modo mas comn de utilizar este comando es el siguiente:
dig @server domain query-type query-class
donde:
server : puede ser tanto el nombre o la direccin 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 direccin IP por el cual se solicita
informacin.
query-type: especifica el tipo de registro que se solicita.
Grupo NMNK
query-class: es la clase de red por la que se pregunta
Grupo NMNK
Maqueta.
Para el desarrollo de las pruebas se utilizar la siguiente maqueta. Dependiendo
del escenario en cuestin, se utilizar una parte de la maqueta en especial, la cual ser
especificada en el escenario correspondiente, es decir, la siguiente es la maqueta ms
general utilizndose ciertos sectores de la misma en cada caso.
FI.UBA
SERVER
PC
L14
ETH. A:192.168.1.0 / 24
.2
PC2
.3
PC3
.1
PC1
MDM
INTERNET
200.10.122.10
DNS
Server
Descripcin de los equipos utilizados.

PC1: Windows XP. Ethereal.
PC2: Windows 98. Ethereal.
PC3: Linux Red Hat 7.2
PCL14: Linux.
Grupo NMNK
Escenario I. DNS sobre UDP

Objetivo:
El objetivo de este escenario es observar que DNS utiliza generalmente como
base el protocolo de capa de aplicacin UDP.
Desarrollo:
Para lograr el objetivo se enviar un ping desde la PC 3 hacia www.yahoo.com
y se capturar el trfico resultante. Como hemos visto en el TP 1, el comando ping
necesita de la direccin IP consultada para enviar el datagrama IP, con lo cual primero
deber realizar una consulta DNS acerca de la direccin 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 efmero cualquiera en la PC origen y el puerto 53 en el destino.
Ejecucin:
A partir del ping enviado se obtuvo la siguiente salida:
[Gonza@localhost Gonza]$ ping www.yahoo.com
PING www.yahoo.akadns.net (216.109.118.77) from 192.168.0.2 : 56(84) bytes of data.
64 bytes from p14.www.dcn.yahoo.com (216.109.118.77): icmp_seq=1 ttl=51 time=328
ms
ms
ms
ms
ms
--- www.yahoo.akadns.net ping statistics --5 packets transmitted, 5 received, 0% loss, time 4035ms
rtt min/avg/max/mdev = 314.770/319.434/328.691/4.919 ms
[Gonza@localhost Gonza]$
Grupo NMNK
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 efmero 1048.
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 nmero 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
Grupo NMNK
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 direccin IP asociada al nombre dado. Esto se realiza utilizando la
siguiente lnea de comando:
dig @200.10.122.10 www.yahoo.com -t A
Ejecucin:
Se gener el comando dig con la opcin t A a www.yahoo.com, 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 informacin obtenida fue la siguiente:
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.yahoo.com -t a
; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.yahoo.com -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:
;www.yahoo.com.
IN
;; ANSWER SECTION:
www.yahoo.com.
1780
www.yahoo.akadns.net. 20
;; AUTHORITY SECTION:
akadns.net.
89836 IN
akadns.net.
89836 IN
akadns.net.
89836 IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
CNAME www.yahoo.akadns.net.
A
216.109.118.78
A
216.109.118.64
A
216.109.118.66
A
216.109.118.71
A
216.109.118.69
A
216.109.118.74
A
216.109.118.77
A
216.109.118.67
NS
NS
NS
zc.akadns.net.
zf.akadns.net.
zh.akadns.net.
11

akadns.net.
akadns.net.
akadns.net.
akadns.net.
akadns.net.
akadns.net.
89836
89836
89836
89836
89836
89836
;; ADDITIONAL SECTION:
zc.akadns.net.
56918
zf.akadns.net.
10745
zh.akadns.net.
58181
ns1-159.akam.net. 46244
use2.akam.net.
1827
usw5.akam.net.
40954
use4.akam.net.
39773
asia3.akam.net.
40641
a-93.akadns.net.
3891
;;
;;
;;
;;
Grupo NMNK
IN
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
NS
ns1-159.akam.net.
use2.akam.net.
usw5.akam.net.
use4.akam.net.
asia3.akam.net.
a-93.akadns.net.
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
A
A
A
A
63.241.199.50
63.215.198.79
63.208.48.42
193.108.91.159
63.209.170.136
63.241.73.214
80.67.67.182
193.108.154.9
193.108.91.93
Query time: 175 msec

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 11:55:26 2003
MSG SIZE rcvd: 511
Conclusiones:
Por lo que observamos, en el paquete de la respuesta se copia tambin la
pregunta. Al consultar por la direccin IP, se obtuvo en primer lugar el CNAME
asociado ya que en este caso www.yahoo.com es un alias de www.yahoo.akadns.net.
Luego s, la direccin que se obtuvo fue la de este ltimo nombre. Vemos tambin que
hay varias direcciones IP asociadas a l, las cuales suponemos que corresponden a
distintos servidores que responden bajo el mismo nombre.
12
Grupo NMNK
Escenario III. Consulta DNS sobre registro tipo MX.

Objetivo:
consulta sobre un registro tipo MX. Se analizarn tanto el formato de la consulta como
de la respuesta.
Desarrollo:
desea obtener la direccin del servidor de mail asociado con el dominio consultado.
Esto se realiza utilizando la siguiente lnea de comando:
dig @200.10.122.10 www.hotmail.com -t MX
Ejecucin:
La consulta se realiz a Hotmail ya que posee varios servidores de mail
asociados por brindar un servicio de estas caractersticas. El resultado obtenido fue el
siguiente:
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.hotmail.com -t mx
; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.hotmail.com -t mx
;; Got answer:
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 18
;www.hotmail.com.
;; ANSWER SECTION:
www.hotmail.com.
www.hotmail.com.
www.hotmail.com.
www.hotmail.com.
IN
3600
3600
3600
3600
hotmail.com.
3600
hotmail.com.
3600
hotmail.com.
3600
hotmail.com.
3600
mx4.hotmail.com.
3600
mx4.hotmail.com.
3600
mx4.hotmail.com.
3600
mx1.hotmail.com.
3600
mx1.hotmail.com.
3600
mx1.hotmail.com.
3600
MX
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
MX
MX
MX
MX
NS
NS
NS
NS
A
A
A
A
A
A
5
5
5
5
mx4.hotmail.com.
mx1.hotmail.com.
mx2.hotmail.com.
mx3.hotmail.com.
ns1.hotmail.com.
ns2.hotmail.com.
ns3.hotmail.com.
ns4.hotmail.com.
65.54.254.151
65.54.253.230
65.54.167.230
65.54.254.129
65.54.252.99
65.54.166.99
13

mx1.hotmail.com.
mx2.hotmail.com.
mx2.hotmail.com.
mx2.hotmail.com.
mx3.hotmail.com.
mx3.hotmail.com.
mx3.hotmail.com.
mx3.hotmail.com.
ns1.hotmail.com.
ns2.hotmail.com.
ns3.hotmail.com.
ns4.hotmail.com.
;;
;;
;;
;;
3600
3600
3600
3600
3600
3600
3600
3600
3600
3600
3600
3600
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
Grupo NMNK
A
A
A
A
A
A
A
A
A
A
A
A
64.4.50.99
65.54.254.145
65.54.252.230
65.54.166.230
65.54.254.140
65.54.253.99
65.54.167.5
64.4.50.239
216.200.206.140
216.200.206.139
209.185.130.68
64.4.29.24

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 11:56:53 2003
MSG SIZE rcvd: 473
Conclusiones:
A partir del anlisis de los paquetes, observamos que existe ms de un servidor
de mail asociado con igual nmero de prioridad. Esperbamos obtener varios MX
asociados pero con distinto nmero de preference. Como informacin adicional se
obtuvieron las direcciones IP asociadas a los mismos, junto con los servidores de
nombre que responden a ese dominio.
14
Grupo NMNK
Escenario IV. Consulta DNS sobre registro tipo PTR.

Objetivo:
consulta sobre un registro tipo PTR. Se analizarn tanto el formato de la consulta como
de la respuesta.
Desarrollo:
desea obtener el nombre asociado a la direccin IP dada (-x [direccin IP]). Del
escenario 2 se obtiene la direccin IP asociada al nombre www.yahoo.com. Esta ser
utilizada para realizar la consulta PTR esperando obtener el mismo nombre. Esto se
realiza utilizando la siguiente lnea de comando:
dig @200.10.122.10 -x 216.109.118.64 -t PTR
Ejecucin:
La traza obtenida fue la siguiente:
[Gonza@localhost Gonza]$ dig @200.10.122.10 -x 216.109.118.64 -t ptr
; <<>> DiG 9.2.0 <<>> @200.10.122.10 -x 216.109.118.64 -t ptr
;; Got answer:
;64.118.109.216.in-addr.arpa. IN
PTR
;; ANSWER SECTION:
64.118.109.216.in-addr.arpa. 1200 IN
PTR
p1.www.dcn.yahoo.com.
118.109.216.in-addr.arpa.
NS
NS
NS
NS
NS
ns1.yahoo.com.
ns2.yahoo.com.
ns3.yahoo.com.
ns4.yahoo.com.
ns5.yahoo.com.
172800
172800
172800
172800
172800
ns1.yahoo.com.
172800
ns2.yahoo.com.
172800
ns3.yahoo.com.
172800
ns4.yahoo.com.
172800
ns5.yahoo.com.
172800
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
66.218.71.63
66.163.169.170
217.12.4.104
63.250.206.138
216.109.116.17
;; Query time: 373 msec

15
Grupo NMNK
;; SERVER: 200.10.122.10#53(200.10.122.10)
;; WHEN: Thu Oct 23 11:58:12 2003
;; 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 www.yahoo.akadns.net, y FQDN p1.www.dcn.yahoo.com.
Verificamos que las direcciones IP correspondientes a estos nombres coinciden, por lo
tanto hay consistencia en la resolucin de nombres.
Conclusiones:
Analizando este escenario encontramos que el nombre asociado a la direccin
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 www.yahoo.akadns.net
se le asocia la direccin IP 216.109.118.64 , mientras que en este caso, a esa direccin
se le asocia el nombre p1.www.dcn.yahoo.com. Podemos concluir que a una misma
direccin IP se le pueden asociar distintos nombres; debiendo existir consistencia entre
las consultas A, y los registros PTR. Este punto se analizar con ms detalle en el
escenario 7.
16
Grupo NMNK
Escenario V. Consulta DNS sobre registro tipo CNAME.

Objetivo:
consulta sobre un registro tipo CNAME.
Desarrollo:
desea obtener los alias asociados al nombre www.yahoo.com.
dig @200.10.122.10 www.yahoo.com -t CNAME
Ejecucin:
La traza resultante es:
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.yahoo.com -t cname
; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.yahoo.com -t cname
;; Got answer:
;www.yahoo.com.
;; ANSWER SECTION:
www.yahoo.com.
IN
1562
IN
CNAME
CNAME www.yahoo.akadns.net.
yahoo.com.
102684
yahoo.com.
102684
yahoo.com.
102684
yahoo.com.
102684
yahoo.com.
102684
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
ns1.yahoo.com.
ns2.yahoo.com.
ns3.yahoo.com.
ns4.yahoo.com.
ns5.yahoo.com.
ns1.yahoo.com.
22312
ns2.yahoo.com.
9729
ns3.yahoo.com.
14926
ns4.yahoo.com.
3785
ns5.yahoo.com.
13543
IN
IN
IN
IN
IN
A
A
A
A
A
66.218.71.63
66.163.169.170
217.12.4.104
63.250.206.138
216.109.116.17
;; SERVER: 200.10.122.10#53(200.10.122.10)
Conclusin:
Obtuvimos el CNAME asociado al nombre www.yahoo.com, el cual concuerda
con el obtenido en el escenario 2.
17
Grupo NMNK
Escenario VI. Consulta DNS sobre el registro SOA.

Objetivo:
consulta sobre el registro SOA. Se analizarn tanto el formato de la consulta como de la
respuesta.
Desarrollo:
desea obtener el registro SOA asociado al servidor consultado.
dig @200.10.122.10 dns1.advance.com.ar -t SOA
Ejecucin:
Los resultados a esta lnea de comando fue:
[Gonza@localhost Gonza]$ dig @200.10.122.10 dns1.advance.com.ar -t soa
; <<>> DiG 9.2.0 <<>> @200.10.122.10 dns1.advance.com.ar -t soa
;; Got answer:
;dns1.advance.com.ar.
IN
SOA
advance.com.ar.
3600 IN
SOA
2003101403 43200 3600 86400 3600
;;
;;
;;
;;
dns1.advance.com.ar. dominios.advance.com.ar.

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:00:15 2003
MSG SIZE rcvd: 82
18
Grupo NMNK
Conclusiones:
Segn lo comentado en la introduccin se observaron los diferentes campos del
registro:
Nombre: dominios.advance.com.ar.
Origen: dns1.advance.com.ar.
Nmero de Serie: 2003101403,
Refresh Time: 43200,
Retry Time: 3600,
Expire Time: 86400,
TTL minimo: 3600.
Lo que se observa es que no aparece la direccin de mail de la persona a cargo

del servidor.
19
Grupo NMNK
Escenario VII. Variedad de nombres asociados a una direccin IP .

Objetivo:
En este escenario deseamos hacer notar que existen varios sitios web asociados a
una misma direccin IP.
Desarrollo:
Se realizarn 3 pedidos de registros A asociados a los nombres
www.zonazeta.com.ar, www.siligom.com.ar, www.lmgsm.com.ar. A continuacin se
realizar una consulta tipo PTR acerca de la direccin IP obtenida.
Las lneas de comando a utilizar en este caso son:
dig @200.10.122.10 www.zonazeta.com.ar -t A
dig @200.10.122.10 www.siligom.com.ar -t A
dig @200.10.122.10 www.lmgsm.com.ar -t A
dig @200.10.122.10 12.207.16.200.in-addr.arpa.com -t PTR
Ejecucin:
Como siempre, continuamos observando:
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.zonazeta.com.ar -t a
; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.zonazeta.com.ar -t a
;; Got answer:
;www.zonazeta.com.ar.
IN
;; ANSWER SECTION:
www.zonazeta.com.ar. 41524 IN
CNAME zonazeta.com.ar.
zonazeta.com.ar.
41524 IN
A
200.16.207.12
zonazeta.com.ar.
12724 IN
zonazeta.com.ar.
12724 IN
ns1.granitecanyon.com. 89482 IN
;;
;;
;;
;;
NS
NS
ns1.granitecanyon.com.
A
A
205.166.226.38
65.102.83.43

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:01:21 2003
MSG SIZE rcvd: 152
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.siligom.com.ar -t a
20
Grupo NMNK
; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.siligom.com.ar -t a

;; Got answer:
;www.siligom.com.ar.
IN
;; ANSWER SECTION:
www.siligom.com.ar.
84725 IN
CNAME siligom.com.ar.
siligom.com.ar.
4328 IN
A
200.16.207.12
siligom.com.ar.
12725 IN
siligom.com.ar.
12725 IN
siligom.com.ar.
12725 IN
NS
NS
NS
ns1.siligom.com.
ns1.siligom.com.
89502 IN
A
200.16.207.12
A
205.166.226.38
A
65.102.83.43
;;
;;
;;
;;

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:01:30 2003
MSG SIZE rcvd: 193
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.lmgsm.com.ar -t a

; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.lmgsm.com.ar -t a
;; Got answer:
;www.lmgsm.com.ar.
IN
;; ANSWER SECTION:
www.lmgsm.com.ar.
84732 IN
CNAME lmgsm.com.ar.
lmgsm.com.ar.
84732 IN
A
200.16.207.12
lmgsm.com.ar.
12732 IN
lmgsm.com.ar.
12732 IN
lmgsm.com.ar.
12732 IN
NS
NS
NS
ns1.siligom.com.
A
65.102.83.43
ns1.siligom.com.
89492 IN
A
200.16.207.12
A
205.166.226.38
;;
;;
;;
;;

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:01:40 2003
MSG SIZE rcvd: 191
21
Grupo NMNK
[Gonza@localhost Gonza]$ dig @200.10.122.10 -x 200.16.207.12 -t ptr

; <<>> DiG 9.2.0 <<>> @200.10.122.10 -x 200.16.207.12 -t ptr
;; Got answer:
;12.207.16.200.in-addr.arpa.
IN
PTR
;; ANSWER SECTION:
12.207.16.200.in-addr.arpa. 84737 IN
12.207.16.200.in-addr.arpa. 84737 IN
12.207.16.200.in-addr.arpa. 84737 IN
207.16.200.in-addr.arpa. 84737 IN
PTR
PTR
PTR
NS
dns1.maqueta.advance.com.ar. 3600 IN
;;
;;
;;
;;
ns1.siligom.com.
www.siligom.com.ar.
dns1.maqueta.advance.com.ar.
dns1.maqueta.advance.com.ar.
200.16.207.12

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:01:58 2003
MSG SIZE rcvd: 170
Conclusiones:
A distintos nombres se asocia una misma direccin 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 relacin unvoca entre
nombre y direccin IP.
22
Grupo NMNK
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 opcin +trace, la cual proporciona informacin sobre todos los servidores
asociados con cada nivel de dominio de fi.uba.ar. La opcin +trace genera que la
consulta sea iterativa.
La lnea de comando es la siguiente:
dig @200.10.122.10 +trace www.fi.uba.ar
Ejecucin:
La traza obtenida fue la siguiente:
[Gonza@localhost Gonza]$ dig @200.10.122.10 +trace www.fi.uba.ar
; <<>> DiG 9.2.0 <<>> @200.10.122.10 +trace www.fi.uba.ar
.
434587 IN
NS
J.ROOT-SERVERS.NET.
.
434587 IN
NS
K.ROOT-SERVERS.NET.
.
434587 IN
NS
L.ROOT-SERVERS.NET.
.
434587 IN
NS
M.ROOT-SERVERS.NET.
.
434587 IN
NS
I.ROOT-SERVERS.NET.
.
434587 IN
NS
E.ROOT-SERVERS.NET.
.
434587 IN
NS
D.ROOT-SERVERS.NET.
.
434587 IN
NS
A.ROOT-SERVERS.NET.
.
434587 IN
NS
H.ROOT-SERVERS.NET.
.
434587 IN
NS
C.ROOT-SERVERS.NET.
.
434587 IN
NS
G.ROOT-SERVERS.NET.
.
434587 IN
NS
F.ROOT-SERVERS.NET.
.
434587 IN
NS
B.ROOT-SERVERS.NET.
;; Received 436 bytes from 200.10.122.10#53(200.10.122.10) in 157 ms
ar.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
;; Received 357
uba.ar.
uba.ar.
uba.ar.
172800 IN
NS
ATHEA.ar.
172800 IN
NS
CTINA.ar.
172800 IN
NS
MERAPI.SWITCH.CH.
172800 IN
NS
NS.RIPE.NET.
172800 IN
NS
NS.UU.NET.
172800 IN
NS
UUCP-GW-1.PA.DEC.COM.
172800 IN
NS
172800 IN
NS
NS1.RETINA.ar.
bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 321 ms
86400 IN
86400 IN
86400 IN
NS
NS
NS
ns2.uba.ar.
intersysmty3.intersys.com.mx.
ns1.uba.ar.
23
Grupo NMNK
;; Received 141 bytes from 200.16.97.17#53(CTINA.ar) in 431 ms

www.fi.uba.ar.
86400 IN
A
157.92.49.193
fi.uba.ar.
86400 IN
NS
ns1.fi.uba.ar.
fi.uba.ar.
86400 IN
NS
ns1.uba.ar.
fi.uba.ar.
86400 IN
NS
ns2.uba.ar.
fi.uba.ar.
86400 IN
NS
ns4.fi.uba.ar.
;; Received 183 bytes from 157.92.4.1#53(ns2.uba.ar) in 159 ms
Conclusiones:
Al haber seleccionado la opcin +trace se logran ver (en orden jerrquico) 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 opcin +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 quera obtener informacin.
24
Grupo NMNK
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 efectuarn 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 lnea de comando es la siguiente:
dig @200.10.122.10 www.discoverychannelconcurso.com
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.
Ejecucin:
La traza obtenida es la siguiente:
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.discoverychannelconcurso.com
; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.discoverychannelconcurso.com
;; Got answer:
;www.discoverychannelconcurso.com. IN A
;; ANSWER SECTION:
www.discoverychannelconcurso.com. 3600 IN CNAME discoverychannelconcurso.com.
discoverychannelconcurso.com. 3600 IN A
64.251.16.55
discoverychannelconcurso.com.
3600
3600
3600
3600
auth01.ns.discovery.com. 3600
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
NS
NS
NS
NS
auth01.ns.discovery.com.
63.240.215.16
63.240.215.17
198.147.11.9
198.147.16.9
25

;;
;;
;;
;;
Grupo NMNK

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:04:25 2003
MSG SIZE rcvd: 241
[Gonza@localhost Gonza]$ dig @200.10.122.10 www.discoverychannelconcurso.com

; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.discoverychannelconcurso.com
;; Got answer:
;www.discoverychannelconcurso.com. IN A
;; ANSWER SECTION:
www.discoverychannelconcurso.com. 3594 IN CNAME discoverychannelconcurso.com.
discoverychannelconcurso.com. 3594 IN A
64.251.16.55
93085
93085
93085
93085
;;
;;
;;
;;
IN
IN
IN
IN
IN
IN
IN
IN
NS
NS
NS
NS
A
A
A
A
198.147.16.9
198.147.11.9
63.240.215.17
63.240.215.16

SERVER: 200.10.122.10#53(200.10.122.10)
WHEN: Thu Oct 23 12:04:31 2003
MSG SIZE rcvd: 241
Conclusiones:
Cuando se realiz la primer consulta, la respuesta tena seteado el bit AA
(Authoritative Answer); lo cual indica que la misma es del tipo autoritativa. En la
segunda consulta, el bit AA viene con un valor igual a 0, con lo cual la respuesta ya no
es ms autoritativa. Esto se debe a que inicialmente, el servidor consultado no conoca
la direccin IP del host, con lo cual ste tuvo que pedirle la informacin al un servidor
de nombres de ese dominio. Como se explic anteriormente esto genera una respuesta
autoritativa. Una vez que el servidor consultado conoce la direccin IP, la misma queda
almacenada en su cach; razn por la cual la segunda respuesta es no autoritativa.
26
Grupo NMNK
Escenario X. Respuestas Recursivas e Iterativas.

Objetivos:
El objetivo de este escenario es observar el tipo de respuesta recursiva e iterativa
y la informacin que brinda cada una.
Desarrollo:
Para lograr este objetivo se setear el bit RD en 0 en las consultas DNS a travs
del comando dig con la opcin +norecursive, con el fin que la respuesta sea iterativa. La
informacin recibida en este caso ser una lista de servidores a los cuales se les debe
hacer la consulta sobre el dominio solicitado.
Para el caso de querer obtener una respuesta recursiva se le agregar al comando
dig la opcin +recursive (o sin opcin ya que por default el comando dig espera
respuestas recursivas).
Otro bit a analizar ser el RA, el cual es seteado en 1 en la respuesta en caso de
que el servidor soporte recursividad. Para ello haremos una consulta al servidor raz,
que por lo general no otorga una respuesta recursiva, esperando obtener que el bit RA
est seteado en 0.
dig @200.10.122.10 +norecursive www.nationalgeographic.com
dig @200.10.122.10 +recursive www.nationalgeographic.com
Ejecucin:
Se generaron dos consultas:
1) con la opcin +norecursive, la cual exige una respuesta iterativa;
2) con la opcin +recursive la cual exige una respuesta recursiva.
[Gonza@localhost Gonza]$ dig +norecursive www.nationalgeographic.com
; <<>> DiG 9.2.0 <<>> +norecursive www.nationalgeographic.com
;; Got answer:
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;www.nationalgeographic.com.
IN
com.
164815
com.
164815
com.
164815
com.
164815
com.
164815
com.
164815
com.
164815
com.
164815
com.
164815
NS
NS
NS
NS
NS
NS
NS
NS
NS
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
K.GTLD-SERVERS.NET.
L.GTLD-SERVERS.NET.
M.GTLD-SERVERS.NET.
A.GTLD-SERVERS.NET.
B.GTLD-SERVERS.NET.
C.GTLD-SERVERS.NET.
D.GTLD-SERVERS.NET.
E.GTLD-SERVERS.NET.
F.GTLD-SERVERS.NET.
27

com.
com.
com.
com.
;;
;;
;;
;;
164815
164815
164815
164815
IN
IN
IN
IN
Grupo NMNK
NS
NS
NS
NS
G.GTLD-SERVERS.NET.
H.GTLD-SERVERS.NET.
I.GTLD-SERVERS.NET.
J.GTLD-SERVERS.NET.

SERVER: 192.168.0.1#53(192.168.0.1)
WHEN: Thu Oct 23 12:08:15 2003
MSG SIZE rcvd: 268
[Gonza@localhost Gonza]$ dig +recursive www.nationalgeographic.com

; <<>> DiG 9.2.0 <<>> +recursive www.nationalgeographic.com
;; Got answer:
;www.nationalgeographic.com.
IN
;; ANSWER SECTION:
www.nationalgeographic.com. 14285 IN
www.nationalgeographic.com. 14285 IN
nationalgeographic.com. 82182 IN
nationalgeographic.com. 82182 IN
ns1.nationalgeographic.com. 82182 IN
ns2.nationalgeographic.com. 82182 IN
;;
;;
;;
;;
A
A
NS
NS
A
A
207.24.89.160
207.24.89.170
ns1.nationalgeographic.com.
ns2.nationalgeographic.com.
207.24.89.10
207.24.89.20

SERVER: 192.168.0.1#53(192.168.0.1)
WHEN: Thu Oct 23 12:08:27 2003
MSG SIZE rcvd: 144
Conclusin:
En la primer consulta, se obtuvo como respuesta una lista de servidores de
nombre a los cuales se deber consultar por el dominio solicitado. Se puede ver que en
este caso el bit RD tiene valor 0 (no aparece en la seccin de los flags seteados).
En la segunda consulta, como se haba seteado el bit RD, la respuesta que se
obtiene muestra directamente la direccin del dominio consultado. Se puede ver que la
respuesta tiene seteada el bit RA, el cual indica que este servidor soporta recursividad.
28
Grupo NMNK
Escenario XI. Balanceo de carga.

Objetivo:
Se pretende observar que cuando existe uno o ms servidores de nombre
asociados a un dominio, estos responden en forma alternada sobre las consultas que se
realicen sobre los hosts del dominio.
Desarrollo:
Se realizarn sucesivas consultas al dominio www.fi.uba.ar con el comando dig
y la opcin +trace, para analizar de que manera responden los servidores de este
dominio.
dig @200.10.122.10 +trace www.fi.uba.ar
Ejecucin:
Los resultados para esta captura son los siguientes:
.
434595 IN
NS
L.ROOT-SERVERS.NET.
.
434595 IN
NS
M.ROOT-SERVERS.NET.
.
434595 IN
NS
I.ROOT-SERVERS.NET.
.
434595 IN
NS
E.ROOT-SERVERS.NET.
.
434595 IN
NS
D.ROOT-SERVERS.NET.
.
434595 IN
NS
A.ROOT-SERVERS.NET.
.
434595 IN
NS
H.ROOT-SERVERS.NET.
.
434595 IN
NS
C.ROOT-SERVERS.NET.
.
434595 IN
NS
G.ROOT-SERVERS.NET.
.
434595 IN
NS
F.ROOT-SERVERS.NET.
.
434595 IN
NS
B.ROOT-SERVERS.NET.
.
434595 IN
NS
J.ROOT-SERVERS.NET.
.
434595 IN
NS
K.ROOT-SERVERS.NET.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
;; Received 357
172800 IN
NS
ATHEA.ar.
172800 IN
NS
CTINA.ar.
172800 IN
NS
MERAPI.SWITCH.CH.
172800 IN
NS
NS.RIPE.NET.
172800 IN
NS
NS.UU.NET.
172800 IN
NS
172800 IN
NS
172800 IN
NS
NS1.RETINA.ar.
bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 513 ms
uba.ar.
86400 IN
NS
ns2.uba.ar.
uba.ar.
86400 IN
NS
uba.ar.
86400 IN
NS
ns1.uba.ar.
;; Received 141 bytes from 200.16.98.2#53(ATHEA.ar) in 192 ms
29

www.fi.uba.ar.
fi.uba.ar.
fi.uba.ar.
fi.uba.ar.
fi.uba.ar.
;; Received 183
Grupo NMNK
86400 IN
A
157.92.49.193
86400 IN
NS
ns1.fi.uba.ar.
86400 IN
NS
ns1.uba.ar.
86400 IN
NS
ns2.uba.ar.
86400 IN
NS
ns4.fi.uba.ar.
bytes from 157.92.4.1#53(ns2.uba.ar) in 191 ms

.
434590 IN
NS
B.ROOT-SERVERS.NET.
.
434590 IN
NS
J.ROOT-SERVERS.NET.
.
434590 IN
NS
K.ROOT-SERVERS.NET.
.
434590 IN
NS
L.ROOT-SERVERS.NET.
.
434590 IN
NS
M.ROOT-SERVERS.NET.
.
434590 IN
NS
I.ROOT-SERVERS.NET.
.
434590 IN
NS
E.ROOT-SERVERS.NET.
.
434590 IN
NS
D.ROOT-SERVERS.NET.
.
434590 IN
NS
A.ROOT-SERVERS.NET.
.
434590 IN
NS
H.ROOT-SERVERS.NET.
.
434590 IN
NS
C.ROOT-SERVERS.NET.
.
434590 IN
NS
G.ROOT-SERVERS.NET.
.
434590 IN
NS
F.ROOT-SERVERS.NET.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
;; Received 357
172800 IN
NS
ATHEA.ar.
172800 IN
NS
CTINA.ar.
172800 IN
NS
MERAPI.SWITCH.CH.
172800 IN
NS
NS.RIPE.NET.
172800 IN
NS
NS.UU.NET.
172800 IN
NS
172800 IN
NS
172800 IN
NS
NS1.RETINA.ar.
bytes from 128.9.0.107#53(B.ROOT-SERVERS.NET) in 386 ms
uba.ar.
86400 IN
NS
uba.ar.
86400 IN
NS
ns1.uba.ar.
uba.ar.
86400 IN
NS
ns2.uba.ar.
;; Received 141 bytes from 200.16.98.2#53(ATHEA.ar) in 212 ms
dig: Couldn't find server 'intersysmty3.intersys.com.mx': Name or service not known
.
434587 IN
NS
J.ROOT-SERVERS.NET.
.
434587 IN
NS
K.ROOT-SERVERS.NET.
.
434587 IN
NS
L.ROOT-SERVERS.NET.
.
434587 IN
NS
M.ROOT-SERVERS.NET.
.
434587 IN
NS
I.ROOT-SERVERS.NET.
.
434587 IN
NS
E.ROOT-SERVERS.NET.
.
434587 IN
NS
D.ROOT-SERVERS.NET.
.
434587 IN
NS
A.ROOT-SERVERS.NET.
.
434587 IN
NS
H.ROOT-SERVERS.NET.
.
434587 IN
NS
C.ROOT-SERVERS.NET.
.
434587 IN
NS
G.ROOT-SERVERS.NET.
.
434587 IN
NS
F.ROOT-SERVERS.NET.
30
Grupo NMNK
.
434587 IN
NS
B.ROOT-SERVERS.NET.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
;; Received 357
172800 IN
NS
ATHEA.ar.
172800 IN
NS
CTINA.ar.
172800 IN
NS
MERAPI.SWITCH.CH.
172800 IN
NS
NS.RIPE.NET.
172800 IN
NS
NS.UU.NET.
172800 IN
NS
172800 IN
NS
172800 IN
NS
NS1.RETINA.ar.
bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 321 ms
uba.ar.
86400 IN
NS
ns1.uba.ar.
uba.ar.
86400 IN
NS
uba.ar.
86400 IN
NS
ns2.uba.ar.
;; Received 141 bytes from 200.16.97.17#53(CTINA.ar) in 431 ms
www.fi.uba.ar.
fi.uba.ar.
fi.uba.ar.
fi.uba.ar.
fi.uba.ar.
;; Received 183
86400 IN
A
157.92.49.193
86400 IN
NS
ns1.fi.uba.ar.
86400 IN
NS
ns1.uba.ar.
86400 IN
NS
ns2.uba.ar.
86400 IN
NS
ns4.fi.uba.ar.
bytes from 157.92.1.1#53(ns1.uba.ar) in 159 ms
Conclusiones:
Cuando se realiza una consulta sobre un host que pertenece a un dominio que
posee ms de un servidor de nombre asociado, las consultas sern respondidas en forma
alternada por cada uno de ellos. Esto se puede ver en las lneas que estn resaltadas en
negro. Concluimos entonces, que al hacer varias consultas, se realiza una suerte de
balanceo de carga con el fin de no sobrecargar a los servidores.
31
Grupo NMNK
Escenario XII. Chequeo de zona.

Objetivo:
El objetivo de este escenario es observar cmo se realiza el chequeo de una zona
utilizando las herramientas que provee el sitio www.nic.fr .
Desarrollo:
Para realizar este escenario utilizamos la pgina www.nic.fr consultando por los
dominios de uba.ar y fi.uba.ar.
Ejecucin:
Verificacin de la zona para el dominio uba.ar:
List of servers checked the zone:
ns1.uba.ar (157.92.1.1)
ns2.uba.ar (157.92.4.1)
intersysmty3.intersys.com.mx ()
List of existing information for the domain

This domain already exists, the name servers are:
ns1.uba.ar
ns2.uba.ar
intersysmty3.intersys.com.mx
Getting the root name server list

This list is used to check that each name server has the correct list of root name servers,and
that their address are correct.
Server ns1.uba.ar (157.92.1.1)
Checking TCP connection
Checking zone on this server
Checking the NS list
Checking the root name server list
Checking SOA record of in-addr.arpa
Checking SOA record of ar
Checking inverse mapping of 157.92.1.1
The address 157.92.1.1 has the name(s): ns1.uba.ar
Checking the IP address of the other name servers
Unable to get the Address record for intersysmty3.intersys.com.mx (Name Error)

32
Grupo NMNK
The server ns2.uba.ar is non recursive

The address 157.92.4.1 has the name(s): ns2.uba.ar, correo.uba.ar
Checking inetnum record in the RIPE database
The inetnum record is the same as ns1.uba.ar
Checking route record in the RIPE database
The route record is the same as ns1.uba.ar
Unable to get the Address record for intersysmty3.intersys.com.mx (Name Error)

Server intersysmty3.intersys.com.mx ()
The address of the server is unknown...

One of the previous servers references the name intersysmty3.intersys.com.mx as an
authoritative server (a NS record) but does not know its address. (does not have a A record for
intersysmty3.intersys.com.mx).
Checking the SOA record
SERIAL
2003102302
PRIMARY
ns1.uba.ar
CONTACT
hostmaster.ccc.uba.ar
REFRESH
1200 (20 minutes)
The refresh period should be at least 6 hours.
RETRY
1200 (20 minutes)
The retry period must be lower than the refresh period.
The retry period should be at least 1 hour.
EXPIRE
1296000 (15 jours)
TTL
7200 (2 heures)
The TTL period must be at least 24 hours.
Checking MX records
MX list for uba.ar
scooby.uba.ar, poids 20
spock.uba.ar, poids 30
relay2.uba.ar, poids 10
No wildcard MX for the domain
33
Grupo NMNK
Checking E-mail addresses

Checking E-Mail address hostmaster@ccc.uba.ar
MX records to spock.uba.ar relay2.uba.ar scooby.uba.ar (sorted)
Domain ccc.uba.ar Host spock.uba.ar
Connecting...
<-- 220 Servidor ESMTP C.C.C. de la U.B.A.
->> HELO beta.nic.fr
<-- 250 spock.uba.ar Hello alpha.nic.fr [192.134.4.16], pleased to meet you
->> VRFY hostmaster@ccc.uba.ar
<-- 252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
Checking anti-relay rules
->> MAIL FROM:<zonecheck@nic.fr>
<-- 250 2.1.0 <zonecheck@nic.fr>... Sender ok
->> RCPT TO:<zonecheck@afnic.asso.fr>
<-- 550 5.7.1 <zonecheck@afnic.asso.fr>... Relaying denied
Checking E-Mail address postmaster@uba.ar
MX records to relay2.uba.ar scooby.uba.ar spock.uba.ar (sorted)
Domain uba.ar Host relay2.uba.ar
Connecting...
<-- 220 relay2.uba.ar ESMTP
<-- 250 relay2.uba.ar
->> VRFY postmaster@uba.ar
<-- 252 send some mail, i'll try my best
<-- 250 ok
<-- 553 sorry, that domain isn't allowed to be relayed thru this MTA (#5.7.1)
Zone contents
Number of records : 0
Count by record type:
Conclusion
All name servers seem to be on the same net
5 error(s)
3 warning(s)
The domain uba.ar can not be installed
Verificacin de la zona para el dominio fi.uba.ar:

List of servers checked the zone:
ns1.fi.uba.ar (157.92.49.2)
ns1.uba.ar (157.92.1.1)
ns2.uba.ar (157.92.4.1)
ns4.fi.uba.ar (157.92.49.3)
34
Grupo NMNK
List of existing information for the domain

This domain already exists, the name servers are:
ns4.fi.uba.ar
ns1.fi.uba.ar
ns1.uba.ar
ns2.uba.ar
Getting the root name server list

This list is used to check that each name server has the correct list of root name servers,and
that their address are correct.
Server ns1.fi.uba.ar (157.92.49.2)
The name(s) harmachis.fi.uba.ar does not match the expected name harmachis.fi.uba.ar
This may happen if the machine has more than one address, but you should have one PTR
record per name registered for this adress.
The address 157.92.1.1 has the name(s): ns1.uba.ar
The inetnum record is the same as ns1.fi.uba.ar
The route record is the same as ns1.fi.uba.ar
The server ns2.uba.ar is non recursive
The address 157.92.4.1 has the name(s): ns2.uba.ar, correo.uba.ar
35
Grupo NMNK

Server ns4.fi.uba.ar (157.92.49.3)
The name(s) dns2.fi.uba.ar does not match the expected name dns2.fi.uba.ar
This may happen if the machine has more than one address, but you should have one PTR
record per name registered for this adress.
Checking the SOA record
SERIAL
2003102102
PRIMARY
ns1.fi.uba.ar
CONTACT
admin.fi.uba.ar
REFRESH
1200 (20 minutes)
The refresh period should be at least 6 hours.
RETRY
7200 (2 heures)
The retry period must be lower than the refresh period.
EXPIRE
3600000 (41 jours 16 heures)
TTL
86400 (24 heures)

Checking MX records
MX list for fi.uba.ar
usire.fi.uba.ar, poids 10
relay2.uba.ar, poids 20
No wildcard MX for the domain

Checking E-mail addresses
Checking E-Mail address admin@fi.uba.ar
MX records to usire.fi.uba.ar relay2.uba.ar (sorted)
Domain fi.uba.ar Host usire.fi.uba.ar
Connecting...
<-- 220 usire.fi.uba.ar ESMTP Sendmail 8.12.8/8.12.8; Tue, 28 Oct 2003 12:33:57 -0300
36
Grupo NMNK

<-- 250 usire.fi.uba.ar Hello alpha.nic.fr [192.134.4.16], pleased to meet you
->> VRFY admin@fi.uba.ar
Checking E-Mail address postmaster@fi.uba.ar
MX records to usire.fi.uba.ar relay2.uba.ar (sorted)
Domain fi.uba.ar Host usire.fi.uba.ar
Connecting...
<-- 220 usire.fi.uba.ar ESMTP Sendmail 8.12.8/8.12.8; Tue, 28 Oct 2003 12:33:59 -0300
<-- 250 usire.fi.uba.ar Hello alpha.nic.fr [192.134.4.16], pleased to meet you
->> VRFY postmaster@fi.uba.ar
Zone contents
Number of records : 0
Count by record type:
Conclusion

1 error(s)
3 warning(s)
The domain fi.uba.ar can not be installed
Conclusiones:
Con las herramientas de este sitio se logran ver todos los tipos de consulta que se
realizaron previamente mediante el comando dig. Este sitio tambin permite ver cual es
el servidor autoritativo (primario) de la zona, si los servidores soportan recursin, etc.
37

Nslookup Dig

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Nslookup Dig

Hochgeladen von

Copyright:

Verfügbare Formate

Departamento de Electrnica

Guzmn Pegazzano, Ma. Azul

Josa Scorza, Gonzalo

Rodrguez Palacios, Agustina

Seminario de Redes de Computadoras.

Seminario de Redes de Computadoras.

Seminario de Redes de Computadoras.

El formato de un mensaje DNS es el siguiente:

NUMERO DE RESPUESTAS RRs

NUMERO DE AUTORIDAD RRs

NUMERO DE RRs ADICIONALES

El formato del campo PREGUNTAS es el siguiente:

El campo nombre de preguntas es el nombre por el cual se esta preguntando.

Seminario de Redes de Computadoras.

El formato de las tramas de mensaje de respuesta de un RR es el siguiente:

LONGITUD DE DATOS DEL REGISTRO

El campo de nombre de dominio corresponde al nombre con el cual se

Nombre: Nombre de la zona.

Slo puede haber un registro SOA por zona.

Seminario de Redes de Computadoras.

cuando no se especifica ningn argumento (se utiliza el servidor de nombre seteado

El modo no-interactivo se utiliza cuando el nombre o la direccin IP del host a

El comando DIG (domain information groper) se utiliza tambin, para obtener

Seminario de Redes de Computadoras.

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

Seminario de Redes de Computadoras.

Descripcin de los equipos utilizados.

Seminario de Redes de Computadoras.

Escenario I. DNS sobre UDP

Seminario de Redes de Computadoras.

La traza perteneciente a la consulta DNS es la siguiente:

Podemos observar que el mensaje DNS viaja en la parte de datos de un

Seminario de Redes de Computadoras.

Escenario II. Consulta DNS sobre registro tipo A.

Seminario de Redes de Computadoras.

Query time: 175 msec

Seminario de Redes de Computadoras.

Escenario III. Consulta DNS sobre registro tipo MX.

Seminario de Redes de Computadoras.

Query time: 411 msec

Seminario de Redes de Computadoras.

Escenario IV. Consulta DNS sobre registro tipo PTR.

;; Query time: 373 msec

Seminario de Redes de Computadoras.

A partir de este escenario, y del escenario 2 se observa lo siguiente:

Seminario de Redes de Computadoras.

Escenario V. Consulta DNS sobre registro tipo CNAME.

Seminario de Redes de Computadoras.

Escenario VI. Consulta DNS sobre el registro SOA.

Query time: 139 msec

Seminario de Redes de Computadoras.

Lo que se observa es que no aparece la direccin de mail de la persona a cargo

Seminario de Redes de Computadoras.

Escenario VII. Variedad de nombres asociados a una direccin IP .

Query time: 169 msec

[Gonza@localhost Gonza]$ dig @200.10.122.10 www.siligom.com.ar -t a

Seminario de Redes de Computadoras.

; <<>> DiG 9.2.0 <<>> @200.10.122.10 www.siligom.com.ar -t a

Query time: 147 msec

[Gonza@localhost Gonza]$ dig @200.10.122.10 www.lmgsm.com.ar -t a

Query time: 346 msec

Seminario de Redes de Computadoras.

[Gonza@localhost Gonza]$ dig @200.10.122.10 -x 200.16.207.12 -t ptr