Lab DNS Pop Imap

LABORATORIO DE REDES TCP/IP
TRABAJO PRCTICO
PROTOCOLOS: DS, IMAP Y POP3

PROFESORES:
- Ing. Marcelo Utard
- Ing. Javier Bozzuto

ITEGRATES:
- Walter Luna
- Jos Zerda
- Julio Cabrera
- Ren Garay

Mircoles 3 de Diciembre del 2008

LABORATORIO DE REDES
2

PROTOCOLO DS

Introduccin

A continuacin recordaremos brevemente las estructuras que contiene el protocolo DNS
en su formato genrico, de consulta y respuestas.
El formato de la estructura de DNS es la siguiente:

Donde los campos mas destacados serian:
Total de preguntas: es un nmero que representa la cantidad de preguntas que
contiene el mensaje.
Total de respuestas: es un nmero que representa la cantidad de respuestas que
contiene el mensaje.
Total de registros Autoritarios: es un nmero que representa la cantidad de
servidores autoritarios que tienen relevancia en las respuestas
Total de registros adicionales: es un nmero que representa la cantidad de
direcciones de servidores que tienen relevancia en las respuestas.
Luego vienen las secciones de longitud variable que contienen las preguntas ,
respuestas, servidores autoritarios y direcciones pertinentes.

El query en DNS posee la siguiente estructura:

Donde la consulta posee el formato:
Nombre de consulta: es el nombre del dominio a partir del cual se debe obtener la
direccin IP

3

Tipo: existe una larga lista de tipos existentes y se detallan a continuacin:

Type Description References
0
1 A, IPv4 address. RFC 1035
2 NS, Authoritative name server. RFC 1035
3 MD, Mail destination. Obsolete use MX instead. RFC 1035
4 MF, Mail forwarder. Obsolete use MX instead. RFC 1035
5 CNAME, Canonical name for an alias. RFC 1035
6 SOA, Marks the start of a zone of authority. RFC 1035
7 MB, Mailbox domain name. RFC 1035
8 MG, Mail group member. RFC 1035
9 MR, Mail rename domain name. RFC 1035
10 NULL, Null resource record. RFC 1035
11 WKS, Well known service description. RFC 1035
12 PTR, Domain name pointer. RFC 1035
13 HINFO, Host information. RFC 1035
14 MINFO, Mailbox or mail list information. RFC 1035
15 MX, Mail exchange. RFC 1035
16 TXT, Text strings. RFC 1035
17 RP, Responsible Person. RFC 1183
18 AFSDB, AFS Data Base location. RFC 1183
19 X25, X.25 PSDN address. RFC 1183
20 ISDN, ISDN address. RFC 1183
21 RT, Route Through. RFC 1183
22 NSAP, NSAP address. NSAP style A record. RFC 1706
23 NSAP-PTR. RFC 1348
24 SIG, Security signature.
RFC 2931, RFC
4034
25 KEY, Security key.
RFC 3445, RFC
4034
26 PX, X.400 mail mapping information. RFC 2163
27 GPOS, Geographical Position. RFC 1712
28 AAAA, IPv6 Address. RFC 3596
29 LOC, Location Information. RFC 1876
30 NXT, Next Domain (obsolete). RFC 2535
31 EID, Endpoint Identifier.
32 NIMLOC, Nimrod Locator.
4

NB, NetBIOS general Name Service. RFC 1002
33
SRV, Server Selection.
NBSTAT, NetBIOS NODE STATUS.
RFC 2052, RFC
2782
RFC 1002
34 ATMA, ATM Address.
35 NAPTR, Naming Authority Pointer. RFC 3403
36 KX, Key Exchanger. RFC 2230
37 CERT.
RFC 2538, RFC
4398
38 A6.
RFC 2874, RFC
3226
39 DNAME. RFC 2672
40 SINK.
41 OPT. RFC 2671
42 APL. RFC 3123
43 DS, Delegation Signer. RFC 3658
44 SSHFP, SSH Key Fingerprint. RFC 4255
45 IPSECKEY. RFC 4025
46 RRSIG. RFC 3755
47 NSEC.
RFC 3755, RFC
3845
48 DNSKEY. RFC 3755
49 DHCID, DHCP identifier. RFC 4701
50 NSEC3. RFC 5155
51 NSEC3PARAM. RFC 5155
52
53
54

55 HIP, Host Identity Protocol. RFC 5205
56
-
98

99 SPF, Sender Policy Framework. RFC 4408
100 UINFO.
101 UID.
102 GID.
103 UNSPEC.
104
-

5

248
249 TKEY. RFC 2930
250 TSIG, Transaction Signature.
RFC 2845, RFC
3645
251 IXFR, Incremental transfer. RFC 1995
252 AXFR, A request for a transfer of an entire zone. RFC 1035
253
MAILB, A request for mailbox-related records (MB, MG or
MR).
RFC 1035
254 MAILA, A request for mail agent RRs. Obsolete. RFC 1035
255 *. A request for all records. RFC 1035
256
-
32767

32768 DNSSEC Trust Authorities.
32769 DNSSEC Lookaside Validation.
RFC 4431, RFC
5074

Los ms destacados son:
Tipo A: hace referencia a una tpica consulta de conversin de nombre de
dominio en una direccin IPV4.
Tipo NS: Identifica el nombre de un servidor autoritativo.
Tipo AAAA: es igual al tipo A anteriormente descripto pero en IPV6
Tipo: CNAME: denota el nombre cannico de un alias.

Clase: hace referencia a algn tem de la siguiente lista:

Class Description References
0 Reserved.
1 IN, Internet. RFC 1035.
2
3 CH, Chaos. RFC 1035.
4 HS, Hesiod. RFC 1035.
5
-
253

254 None. RFC 2136.
255 Any (QCLASS only). RFC 1035.
256
-
65535

6

De esta ltima en la gran mayora de las veces se utiliza clase 1 de Internet.
Es importante mencionar como funciona el mecanismo de resolucin de la direccin IP.
Todo comienza por el resolver que se encuentra en la maquina cliente. Este enva la
consulta al DNS Server configurado en su lista (Si es que el dominio a resolver no se
encuentra previamente resuelto en su lista de cache). Las consultas suelen ser recursivas
cuando sea posible es decir que la respuesta a la misma deba ser entregada por el DNS
Server al que se le pregunta. Existe una excepcin en donde la consulta no puede ser
recursiva y es iterativa. Es decir que el DNS Server consultado responde con otra
direccin (hasta llegar al servidor autoritativo) en donde consultar para obtener la
respuesta. Este es el caso de los servidores denominados raz (Root Server). Existen 13 de
estos servidores en el mundo. La idea de tener diferentes tipos de servidores es poder
delegar trabajo y no tener un equipo centralizado que responda a las consultas de todo el
mundo. Tambin se busca tener mecanismos de redundancia frente a fallas de hardware y
cadas del sistema.

El formato de la respuesta posee la siguiente estructura:

Esta estructura, aparte de contener los dos campos descriptos en la seccin de query (tipo
y clase), adems agrega:
TTL: representa el tiempo cuya respuesta puede ser considerada como valida
expresado en segundos.
Longitud del dato: expresado en bytes
Data: es la respuesta a la interrogante cualquiera haya sido esta

7

Escenario 1

Planificacin

Maqueta

Dado que el tema a desarrollar en esta oportunidad es Sistema de nombre de dominios
(DNS en ingles), se realizo una maqueta como la que se detalla a continuacin:

Dado este escenario, se decide realizar un ping al muy conocido al site
www.yahoo.com, para que en el proceso de resolucin de dicho comando se ejecuten la
secuencia de instrucciones que esperamos obtener y detallaremos a continuacin.

Secuencia de eventos y resultados esperados

1. Se ejecuta el comando ping www.yahoo.com
Con el objeto de que la PC realice una operacin de resolucin de nombre
de dominio a IP, se decide utilizar este simple comando. Cabe aclara que
se consideran que las tablas ARP ya se encuentran llenas y que la
direccin al site elegido se ingresa por primera vez despus de mucho
tiempo

2. El comando necesita resolver la direccin del dominio a una direccin IP.
8

Este es el caso para el cual el protocolo DNS fue creado, poder convertir
un nombre fcil de recordar por un ser humano en una direccin IP,
necesaria para poder enviar datagramas

3. Genera la consulta a su servidor DNS asignado usando el protocolo DNS
(DNS Query)

4. La respuesta regresa con la direccin IP de dicho site (DNS Answer)

5. El comando ping enva los mensajes ICMP correspondientes.
Esta parte del anlisis escapa al alcance de este informe cuyo principal y
nico objetivo es el protocolo DNS

Ejecucin

La ejecucin de dicha planificacin fue llevada a cabo utilizando un sniffer de
paquetes instalado en la maquina que realizo el comando ping. Los resultados de dicha
captura se detallan a continuacin:

En el diagrama de flujo se pueden observar los siguientes eventos:
9

Evento 1: Se realiza una consulta DNS al servidor DNS numero 1(200.45.191.35).
Evento 2: Dado que no ha llegado la respuesta de dicho servidor, se realiza otra consulta
al servidor de DNS numero 2 (200.45.48.233). Esta ltima consulta se realiza un segundo
despus sin haber recibido respuesta alguna.
Evento 3: Se recibe una respuesta del servidor DNS nmero 1, consultado en el evento 1.
Evento 4: Con la resolucin de la direccin IP, el equipo envi el primer mensaje ICMP
(Echo request) para realizar el comando ping.
Evento 5: Se recibe la respuesta del servidor DNS nmero 2, consultado en el evento 2.
Esto es un evento no esperado en la planificacin de la prueba. Dado que no se
contemplaban dos consultas.
Evento 6: Secuencias de transmisin y recepcin de echo request y echo reply
respectivamente.

A continuacin procedemos a detallar algunas caractersticas y campos de estructuras que
merecen mencionarse en los eventos antes descriptos.

Evento 1:

Dado que en este evento la PC WALLAS necesita enviar una consulta de DNS,
evala la direccin de dicho servidor y al ver que esta no se encuentra en su red, la va a
enviar a su default Gateway. Esto se traduce a la siguiente tabla:

IP origen 192.168.1.100 IP de WALLAS
MAC origen 00:1A:73:EE:C3:80 MAC de WALLAS
IP destino 200.45.191.35 Servidor DNS 1
MAC destino 00:21:29:69:C5:AA MAC de router CISCO

Como se puede observar en la captura de la siguiente figura

10

Notar que el protocolo utilizado es UDP y que el puerto de salida es el 53.
Al tratarse de una consulta se setean los Flags correspondientes para tal fin.
Se pide una consulta de tipo recursiva.
La cantidad de preguntas es una y el resto de los campos de registros estn vacos.
La pregunta es de tipo A, es decir una tpica conversin de nombre de domino (en este
caso www.yahoo.com) a direccin IP. La clase es IN dado que el entorno es Ethernet.

Evento 2:

En este caso, la tabla de direcciones IP y MAC se puede resumir como se muestra a
continuacin:

IP origen 192.168.1.100 IP de WALLAS
MAC origen 00:1A:73:EE:C3:80 MAC de WALLAS
IP destino 200.45.48.233 Servidor DNS 2
MAC destino 00:21:29:69:C5:AA MAC de router CISCO

Nuevamente se corrobora dicha tabla con la captura que a continuacin se muestra.

Notar que esta consulta es exactamente igual a la anterior BIT a BIT exceptuando la
direccin IP destino de la misma.

11

Evento 3:

Este evento corresponde a la respuesta del servidor DNS nmero 1 por lo que la tabla de
direcciones queda:

IP origen 200.45.191.35 IP de Servidor DNS 1
MAC origen 00:21:29:69:C5:AA MAC de router CISCO
IP destino 192.168.1.100 IP de WALLAS
MAC destino 00:1A:73:EE:C3:80 MAC de WALLAS

Como se puede observar a continuacin, se encuentra la captura de dicha respuesta.

Notar que el puerto de origen en este caso es el bien conocido 53 al puerto efmero
54453. De los flags podemos ver que el servidor DNS 1 puede resolver consultas de
forma recursivas. En esta consulta hemos recibido tres respuestas, es decir que como
mnimo el pedido a recorrido tres DNS servers. En este viaje se paso del dominio
www.yahoo.com al alias: www.wa1.b.yahoo.com y de este ultimo alias se obtuvo el
siguiente alias: www-real.wa1.b.yahoo.com. Recin en la consulta siguiente, se paso de
www-real.wa1.b.yahoo.com a la direccin IP: 69.147.76.15. Es muy importante destacar
en dicho proceso de obtencin de la direccin IP, se obtuvieron un conjunto de servidores
autoritativos. Esta informacin es de gran utilidad para el cache DNS del servidor DNS y
se encuentra detallada en la seccin de registros autoritativos de al estructura del
12

protocolo DNS. En la ltima seccin de dicha estructura, se encuentran los registros de
informacin adicional que detallan las direcciones IP de los servidores autoritativos de la
seccin anterior.

Evento 4:

Con la resolucin de la direccin el comando ping se encuentra en condiciones de enviar
el mensaje ICMP Echo request. Notar que no fue necesario recibir la respuesta de la
segunda consulta al servidor DNS 2. Con recibir una respuesta en forma positiva, fue
suficiente requisito para cumplir el objetivo.

Evento 5:

La captura de dicho evento se detalla a continuacin:

Como era de esperar, la respuesta del servidor DNS numero 2 llega aunque ya no es
necesaria. En dicha respuesta se puede observar que tambin se han recibido tres
respuestas. Ah vemos que los alias informados (www.wa1.b.yahoo.com , www-
real.wa1.b.yahoo.com) son los mismos que se detallan en el evento 3. Por ultimo, como
es esperable, la direccin IP enviada como respuesta es la misma tambin. En el campo
13

de registros de servidores autoritativos, hemos recibido la lista de todos (13) los
servidores raz que existen actualmente en el mundo, y en el campo de registro
adicionales, se encuentran las direcciones IP de dichos servidores.

Conclusiones del primer escenario

Como conclusin, podemos decir que en trminos generales el resultado obtenido
se encuentra dentro de las expectativas. Es decir que la sucesin de paquetes DNS
concuerdan con lo descripto en la seccin de resultados esperados. Cabe mencionar un
par de eventos inesperados a la hora de la ejecucin. Uno de estos eventos fue el envo de
una segunda consulta al servidor DNS numero 2 al cabo de una segundo exacto. Este
evento no fue esperado por nosotros a la hora de la planificacin. Estimamos que es un
parmetro programable en alguna seccin de configuracin del sistema operativo
utilizado (Windows Vista en este caso). Otro evento que nos sorprendi, fue la recepcin
del listadlo de los trece servidores raz dentro de la respuesta de una de los servidores
DNS. Esto se debi al armado de la respuesta proveniente las diversas fuentes
consultadas por nuestro servidor DNS numero 2. Tambin nos ha sorprendido que un
dominio tan conocido y simple, deba ser resuelto luego de tantas consultas dado que
posee dos alias.
A pesar de lo escrito anteriormente, estamos complacidos con los resultados.

Escenario 2

Planificacin

Maqueta

La maqueta sobre la cual se desarrolla la segunda ejecucin, se encuentra
detallada a continuacin:

Se ha decidido armar una pequea red con servidor DNS incluido en ella. Se
ejecuta el comando ping desde una maquina y se monitorea la comunicacin que se
establece con dicho servidor DNS. La idea de este escenario es poder visualizar los
14

procesos de consulta/respuesta que se realizan entre los servidores DNS localizados en
Internet y el ubicado en nuestra red. Con el objeto de monitorear dichas comunicaciones,
se opta por colocar un HUB para que dichos paquetes sean visibles desde la maquina que
posee el sniffer wireshark.

Secuencia de eventos y resultados esperados

1. Se ejecuta el comando ping www.collazos.com.co con el objeto de que la
PC realice una operacin de resolucin de nombre de dominio a IP, a una
direccin inexistente.

2. El comando necesita resolver la direccin en su formato qdfn a una
direccin IP.

3. Genera la consulta a su servidor DNS asignado usando el protocolo DNS
(DNS Query). A dicho servidor DNS se le borro previamente el cache de
direcciones.

4. La respuesta regresa con el mensaje no such name (DNS Answer)

Ejecucin

La ejecucin de dicha planificacin fue llevada a cabo utilizando un sniffer de
paquetes instalado en la maquina que realizo el comando ping. Los resultados de dicha
captura se detallan a continuacin:

En el diagrama de flujo se pueden observar los siguientes eventos:
Evento 1: El equipo con direccin 192.168.112.128 realiza una consulta DNS al servidor
DNS direccin ip 192.168.112.129.
Evento 2: Nuestro servidor DNS, cuyo cach fue previamente borrado, realiza una
consulta no recursiva DNS hacia uno de los servidores root guardados en su
configuracin. En este caso particular la realiza hacia el servidor 192.112.36.4
(Columbus, Ohio, U.S.).
15

Evento 3: Se realiza la misma consulta a otro de los servidores Root que se tienen
guardado en la configuracin. Esta vez, se escoge el servidor 192.0.14.129 (Sistema
distribuido, usando anycast).
Evento 4: El servidor DNS root al que se consulto en el evento anterior (Evento 3) enva
los datos correspondientes a los servidores a los que se le puede realizar la consulta
pertinente. Recordemos que la consulta fue iterativa.
Evento 5: Con la informacin recibida, se realiza la misma consulta al servidor
157.253.99.15.
Evento 6: Nuestro servidor DNS recibe de parte del 157.253.99.15 (ubicado en colombia,
extensin .co), el mensaje No such name.
Evento 7: Nuestro servidor DNS enva al host 192.168.112.128 que realizo la consulta
inicial el mismo mensaje recibido anteriormente No such name.

A continuacin procedemos a detallar algunas caractersticas y campos de estructuras que
merecen mencionarse en los eventos antes descriptos.

Evento 1:

Dado que en este evento la PC Nicaraguita necesita enviar una consulta de DNS,
evala la direccin de dicho servidor, la encuentra en su propia red y le enva la consulta
DNS. Esto se traduce a la siguiente tabla:

IP origen 192.168.112.128 IP de Nicaragita
MAC origen 00:0C:29:C3:FA:60 MAC de Nicaragita
IP destino 192.168.112.129 Servidor DNS interno
MAC destino 00:0C:29:2F:2C:4F MAC del Servidor DNS Local

Como se puede observar en la captura de la siguiente figura

Notar que el protocolo utilizado es UDP y que el puerto de salida es el 53.
Al tratarse de una consulta se setean los Flags correspondientes para tal fin.
16

Se pide una consulta de tipo recursiva como se ve en el campo recursive desired.
La cantidad de preguntas es una y el resto de los campos de registros estn vacos.
La pregunta es de tipo A, es decir una tpica conversin de nombre de domino (en este
caso www.collazos.com.co) a direccin IP. La clase es IN dado que el entorno es
Ethernet.

Evento 2:

En este caso, la tabla de direcciones IP y MAC se puede resumir como se muestra a
continuacin:

IP origen 192.168.112.129 IP de DNS Local
MAC origen 00:0C:29:2F:2C:4F MAC de Nicaragita
IP destino 192.112.36.4 Servidor DNS Root G
MAC destino 00:50:56:F5:50:4D MAC del default geteway

Nuevamente se corrobora dicha tabla con la captura que a continuacin se muestra.

Esta consulta se realiza de forma No recursiva. Lo que se pretende es recibir de
este equipo DNS las direcciones de los servidores a los que se les pueda realizar la
consulta. El parmetro de Recursion Desired queda en 0. El tipo de consulta NS indica
que ser a un servidor autoritativo, el cual en ese caso es el Root Server G (Columbus).
Se puede ver que de forma igual al evento anterior los campos Authority, answer y
aaddtional RRS estarn en 0.

Es interesante observar que durante el flujo, nunca se recibe la respuesta de este
servidor. Asumimos que posiblemente se perdi el paquete en el camino y como
recordaremos, se esta usando UDP, ninguno de los miembros se entero que el paquete se
haba perdido. De cualquier forma, se enva exactamente la misma consulta a otro
servidor Root de su lista. (evento que sigue).
17

Evento 3:

En este evento se reenva la misma consulta pero esta vez hacia otro servidor raz,
en este caso al servidor K (192.0.14.129). Estimamos que esto se debe a que el protocolo
sobre el cual viajan estos mensajes es UDP y no existe manera de asegurar recepcin en
ninguno de los equipos, se realizan consultas mltiples y simultneas. Por lo que la tabla
de direcciones queda:

IP origen 192.168.112.129 IP de Servidor DNS local
MAC origen 00:0C:29:2F:2C:4F MAC del servidor DNS local
IP destino 193.0.14.129 IP de DNS Root K
MAC destino 00:50:56:F5:50:4D MAC de default geteway

Como se puede observar a continuacin, se encuentra la captura de dicha respuesta.

Esta consulta es exactamente igual a la anterior con la diferencia de que cambia la
direccin IP destino al que se le realizar la consulta. Esta vez se realiza al servidor raiz
K.

Evento 4:

Para este evento en el que se recibe la respuesta del servidor DNS raz K, la tabla
de direcciones quedar como sigue:

IP origen 193.0.14.129 IP de DNS Root K
MAC origen 00:50:56:F5:50:4D MAC de default Gateway
IP destino 192.168.112.129 IP del servidor DNS local
MAC destino 00:0C:29:2F:2C:4F MAC del servidor DNS local

18

A continuacin la pantalla de la captura:

En esta captura se observa que el servidor raz K no enva respuesta final sobre la
direccin correspondiente a la consulta pero si enva los datos de 5 servidores
autoritativos. Uno de los cuales estar siendo usado por nuestro servidor DNS local para
realzar la siguiente la misma consulta en el prximo evento. El campo Recursion
Available de los flags est en 0, comprueba el hecho de que los servidores raz solo
permiten o entregan consultas no Recursivas. Los servidores autoritativos que se reciben
como lugares de posible bsqueda, corresponden a dos ramas principales: 4 para la rama
.CO correspondiente a las pginas en Colombia y 1 ultimo para la rama EDU
correspondiente a todas las organizaciones relacionadas con la Educacin.

En el segmento de Additional records, se entregan las IP correspondientes a los
servidores Autoritativos entregados.

Evento 5:

En este evento se realiza la consulta a uno de los servidores autoritativos recibidos en el
evento anterior. Por lo que la tabla de direcciones queda como sigue:

IP origen 192.168.112.129 IP de Servidor DNS local
MAC origen 00:0C:29:2F:2C:4F MAC del servidor DNS local
IP destino 157.253.99.15 IP de NS, NS1.nic.co
MAC destino 00:50:56:F5:50:4D MAC de default geteway
19


En este evento se ve como se enva la misma consulta que ha estado haciendo
nuestro servidor DNS local pero esta vez a uno de los servidores autoritativos recibidos
en el evento anterior. En este caso fue escogido el primero recibido. La consulta
realizada es de tipo A, significando que es una consulta tpica. El campo Recursion
desired sigue estando en 0, representando que es una consulta no Recursiva como todas
las que hasta ahora ha realizado nuestro servidor local.

Evento 6:

En este evento se recibe la respuesta de parte del servidor Autoritativo al que se
consulto en el evento anterior. La tabla de direcciones queda como sigue:

IP origen 157.253.99.15 IP de NS, NS1.nic.co
MAC origen 00:50:56:F5:50:4D MAC de default Gateway
IP destino 192.168.112.129 IP del servidor DNS local
MAC destino 00:0C:29:2F:2C:4F MAC del servidor DNS local

20


En este evento se observa que finalmente se recibe una respuesta. Esta vez se
recibe un Reply code 0011 correspondiente al mensaje No such name. Este mensaje
indica que el nombre que estamos consultando (www.collazos.com.co), no existe.

De la captura podemos observar ciertos campos particulares; Se muestra que el campo
Authoritative esta vez esta en 1 indicando que la respuesta la enva un servidor de este
tipo. Como toda respuesta a cualquier consulta realizada, en el segmento Queries se
copia la consulta original realizada. Tambin se puede ver que en el segmento de
Authoritative nameservers, aparece un campo type que indica que el valor SOA. Esto
significa que esta representa el comienzo de una zona de autoridad.

Evento 7:

En este ultimo evento nuestro servidor local enva finalmente una respuesta al host que
realizo la consulta originalmente. Por lo que la tabla de direcciones queda como sigue:

IP origen 192.168.112.129 Servidor DNS interno
MAC origen 00:0C:29:2F:2C:4F MAC del Servidor DNS Local
IP destino 192.168.112.128 IP de Nicaragita
MAC destino 00:0C:29:C3:FA:60 MAC de Nicaragita

21


En este ultimo evento se enva la misma respuesta obtenida en el evento anterior
pero esta vez hacia la IP del equipo host que realizo la consulta inicial. Por lo que el host
recibir un mensaje de No such name.

Este mensaje ser traducido por el sistema operativo, en este caso el comando
ping, para ser mostrado al usuario de la forma siguiente: Ping request could not find host
www.collazos.com.co. Please check the name and try again. Indicando bsicamente que
no se encontr en nombre DNS buscado.

Conclusiones para el segundo Escenario.

Al igual que en el escenario 1, los resultados se sucedieron de la manera prevista.
Es decir que el resolver, al iniciar una consulta DNS de un dominio inexistente, debe
recibir un mensaje equivalente a dominio desconocido. Este mensaje corresponde al
cdigo del flag REPLY CODE 3 para el evento no such name. Hemos podido
comprobar utilizando esta topologa de red con el servidor DNS y el HUB las
comunicaciones y pedidos de un servidor DNS resolviendo la direccin de forma iterativa
que fue muy didctico y clarificador. Una de las cosas que nos ha sorprendido es que la
primer consulta al ROOT Server nunca fue respondida ni siquiera varios segundos
despus. Nosotros creemos esto se puede deber a que este protocolo viaja usando el
protocolo UDP y existe la probabilidad de que dicho mensaje se pierda tanto en el viaje
de ida como en el de vuelta. De ocurrir esto, no existe posibilidad alguna de deteccin de
no recepcin en ninguna de las dos partes. Es por eso que creemos que los DNS Server
envan varias consultas a la vez, para sobrellevar eventualidades como estas. Tambin se
pudo observar la divisin que existe en dominios de autoridad con servidores de
comienzo de zonas. Esto permite lograr una descentralizacin crucial para lograr un
sistema que intente disminuir la congestin de un equipo en particular y permite la
escalabilidad de la metodologa.
22

De igual forma se nos hace muy interesante mostrar cmo se va armando la
estructura del rbol DNS dentro del servidor. A continuacin mostramos la imagen de la
consola de configuracin de DNS de Windows server 2003:

Se puede ver como se han agregado el rbol de la raz CO, correspondiente a
Colombia. Esto debido a que la pagina que ocupamos para la prueba terminaba en CO.
Se puede ver que el servidor recibi dentro de su primera consulta las terminaciones
EDU y NIC. Luego de realizar la consulta a uno de los servidores en EDU este
entrego en la respuesta de la consulta la terminacin UNIANDES y al consultar a algn
servidor de esta ultima rama trmino la consulta.

23

PROTOCOLO IMAP Y POP3

PLAIFICACIO:
QUE SON PROTOCOLOS POP E IMAP, PARA QUE SIRVEN Y COMO
TRABAJAN EN LA CAPA DE RED

POP e IMAP son los dos protocolos de recepcin de correo electrnico ms utilizados,
que soportan la mayora de los servidores de correo electrnico y programas clientes
como Outlook Express o Mozilla Thunderbird. Tambin podemos referirnos a ellos con
sus nmeros de versin POP3 e IMAP4.
Existen varias diferencias, pero digamos que IMAP es ms novedoso y permite ms
funcionalidades.
Para mi, la diferencia fundamental es que, cuando nos conectamos por POP, se descargan
todos los mensajes al ordenador cliente y con IMAP no se descargan todos mensajes sino
slo los que el cliente solicite. Adems, lo normal cuando se accede a un correo con POP
es que los mensajes se borren del servidor segn se descargan, mientras que por IMAP al
visualizar un mensaje no se borra del servidor, a no ser que se elimine explcitamente.
Otras diferencias es que con POP slo se puede conectar un usuario para descargar el
correo electrnico y con IMAP se pueden conectar ms de un usuario a la misma cuenta.
En cuanto a lo ms recomendable, si POP o IMAP, eso depende del uso que des a tu
correo y el modo de conexin.
Con POP puedes descargar todos los mensajes en tu ordenador en un pequeo espacio de
tiempo y luego puedes verlos aunque no est conectado a Internet. Con POP puedes
escribir todas las respuestas sin estar conectado y luego volver a conectarte a Internet un
momento para enviar las respuestas.
Con IMAP tienes que estar conectado a Internet todo el tiempo que leas tu correo y
contestes los mensajes. Si pierdes la conexin a Internet no podrs acceder a tu correo
recibido, porque est almacenado en el servidor de correo y no en tu ordenador.
La parte buena de IMAP es que varias personas pueden estar conectadas a una misma
cuenta a la vez. Adems, si cambias de ordenador en cualquier momento, podrs acceder
a tus mensajes igualmente, porque por IMAP todos los mensajes estn disponibles desde
cualquier ordenador conectado a Internet.
Por lo tanto, con POP si descargas los mensajes, se guardarn en tu ordenador y tendrs
que tener tu ordenador para leer el correo antiguo. Si los miras por IMAP seguirn
almacenndose en el servidor hasta que los borres. Por eso IMAP puede ser una buena
idea si cambias de ordenador habitualmente.

ELECCI DEL PROTOCOLO A EMPLEAR (POP vs IMAP)

El primer paso para configurar nuestra cuenta de correo es decidir qu protocolo vamos a
querer utilizar. Tenemos dos posibles opciones: usar protocolo POP3 o IMAP. Vamos a
explicar brevemente ambos y ser cada usuario el que decida el ptimo para sus
necesidades.

24

POP3

La ventaja principal que tiene este protocolo es que carpetas, mensajes, etc. se guardan en
nuestro ordenador, con lo que nos permite leer el correo recibido sin estar conectado a la
red. Adems, al leer los mensajes y bajarlos a nuestro ordenador, liberamos espacio en
nuestro buzn del Host, con lo cual tenemos menos probabilidades que por descuido se
nos llene el buzn y no podamos recibir ms mensajes. Es el ms extendido
(prcticamente todos los programas de correo lo soportan) y es el ideal para conectarse
siempre desde un mismo ordenador.

IMAP

La principal diferencia que encontramos respecto al anterior protocolo es que tanto los
mensajes como las carpetas se guardan en el Host. Esto, que puede parecer un
inconveniente, es muy til para conectarse desde ordenadores compartidos, ya que los
mensajes no pueden ser ledos por terceras personas, al no quedarse en el PC, adems, si
no tenemos la posibidad de conectarnos siempre del mismo ordenador, conseguimos
siempre acceder a la totalidad de nuestros mensajes. Hay que tener la precaucin de ir
borrandolos de vez en cuando para no sobrepasar el lmite de capacidad de nuestro buzn.
En cuanto al soporte de este protocolo, aunque son pocos los programas de correo que lo
soportan por ahora, tenemos la suerte que los dos navegadores ms extendidos (Netscape
e Internet Explorer -Con Outlook Express u Outlook 98-) s que pueden trabajar con l.
El programa de correo que viene por defecto con el Internet Explorer es Outlook 97. Este
programa, como he mencionado anteriormente, no dispone de soporte para protocolo
IMAP, aunque s el Outlook Express (que se puede descargar desde internet) u Outlook
98. Adems, estos ltimos soportan el poder configurar varias cuentas de correo, cosa que
no puede hacer el Outlook 97.

POP (Post Office Protocol)
POP es un sencillo protocolo de descarga de mensajes de correo desde la estafeta. Es el
protocolo aconsejado cuando utilizas una conexin a Internet no permanente, sin tarifa
plana, o con un coste alto por minuto (por ejemplo conexin de un porttil mediante un
mvil). En estos casos el protocolo POP te permite conectar al servidor, descargar los
mensajes, cortar la conexin y procesar las copias locales de los mensajes.

POP fue diseado para ser fcil de implementar, pero tiene varias deficiencias en su
funcionamiento:
No maneja correctamente mltiples carpetas.
Fuerza la descarga completa de los mensajes. En vez de descargar al ordenador del
usuario slo la cabecera Asunto: para que decida si el mensaje debe ser borrado o ledo,
25

descarga el mensaje completo con todos sus archivos adjuntos y una vez descargado es
cuando el usuario puede procesarlo.
Por ltimo y lo ms importante O podremos procesar nuestro correo desde
diferentes puestos (trabajo, casa, viajes,), ya que descarga todos los mensajes desde la
cola de entrada de las estafetas hasta el primer ordenador desde el que establecemos la
conexin y por tanto, a partir de este momento, no ser visible desde ningn otro.
En algunos programas de correo de usuario, en opciones avanzadas, se nos permite
indicarle a la estafeta que no descargue el correo y que lo deje en el servidor. Esta
opcin est totalmente desaconsejada ya que los correos, realmente, no llegan a
buzonearse sino que quedan en las colas temporales de entrada de las estafetas, dejando
al programa de usuario la responsabilidad de interpretar cuando un correo ha sido ledo o
no; en la actualidad, con arquitecturas complejas de mensajera en las que las estafetas no
son nicas sino distribuidas entre varios servidores, provocar que en ciertas
circunstancias se genere una descarga repetitiva de mensajes por parte del programa de
correo de usuario.
IMAP (Internet Message Access Protocol)
Fue diseado para solucionar las carencias del protocolo POP, principalmente la
movilidad y el procesamiento de correo desde diferentes puestos.

Mediante este protocolo nuestro programa de correo electrnico conecta al servidor y
descarga exclusivamente las cabeceras de los mensajes. Los mensajes quedan
almacenados en el buzn del usuario dentro de la estafeta y, por tanto, pueden ser
procesados nuevamente desde cualquier otro ordenador o localizacin. Al descargar
solamente las cabeceras (y no todo el cuerpo del mensaje) podemos eliminar los mensajes
no deseados sin necesidad de descargar el mensaje en su totalidad; los mensajes solo son
transferidos cuando se seleccionan individualmente para leerlos.

Este protocolo, sin embargo, obliga a mantener abierta la conexin con la estafeta hasta
finalizar la consulta y por tanto no es aconsejable cuando disponemos de una conexin
con un alto coste por minuto y no permanente.

Lo ms interesante del protocolo IMAP es que al quedar los buzones y su contenido
situados fsicamente en las estafetas centrales y no en el PC del usuario, nos permite
acceder a los mensajes desde diferentes ordenadores, aunque previamente los hayamos
ledo desde otra mquina o programa. Es especialmente interesante en desplazamientos
fuera del entorno de trabajo pues los buzones y mensajes podrn leerse mediante el
servicio WEBMAIL durante el desplazamiento y posteriormente desde el cliente de
correo habitual en RedUGR.

26

EJECUCIO : creacin de cuentas IMAP o POP

1. Introduccin

Los servidores de correo de la Universidad de UBA le permiten enviar/recibir mensajes
de correo autenticados y cifrados. Para poder establecer este tipo de conexiones es
necesario realizar las siguientes pasos:
Crear una cuenta nueva o modificar las propiedades de una cuenta existente
Elegir el tipo de servidor entrante: POP3 seguro o IMAP seguro
Configurar el servidor saliente: SMTP seguro y autenticado
Las conexiones seguras necesitan utilizar certificados. Outlook ya dispone de los
certificados de la FNMT (utilizados por los servidores de la UJA), as que no necesitar
importarlos.
Esta gua muestra cmo configurar un Outlook manualmente, si quiere realizar una
configuracin automtica puede utilizar el programa Profiles del Servicio de Informtica.
Nota: En las pantallas que aparecen a continuacin se utiliza como ejemplo la direccin
de correo usuario@prueba.ar y la cuenta "usuario". Usted debera utilizar el suyo.
2. Crear una cuenta nueva POP o IMAP

Para crear una nueva cuenta de correo, siga las siguientes instrucciones:
Entre en Men Herramientas -> Cuentas de correo electrnico....
Pulse en Agregar una nueva cuenta de correo electrnico
Si elije el protocolo POP3 siga los pasos 2.1a, en caso contrario siga los pasos 2.1b.
Ms informacin: Diferentes entre POP3 e IMAP
27

2.1a Introduzca los siguientes datos para configurar una cuenta POP:
Tipo de servidor: POP3
Su nombre
Su direccin de correo
Nombre de usuario
Recordar contrasea: (opcin
desactivada)
Iniciar sesin utilizando Autenticacin
de contrasea de seguridad (SPA):
(opcin desactivada)
Servidor de correo entrante(pop3):
pop3.uba.ar
Servidor de correo saliente (smtp):
smtp.uba.ar

Pulse siguiente y finalizar.

2.1b Introduzca los siguientes datos para configurar una

28

cuenta IMAP:
Tipo de servidor: IMAP
Su nombre
Su direccin de correo
Nombre de usuario
Recordar contrasea: (opcinn
desactivada)
Iniciar sesinn utilizando
Autenticacinn de
contrasea de seguridad (SPA):
(opcinn desactivada)
Servidor de correo entrante(pop3):
imap.uba.ar
Servidor de correo saliente (smtp):
smtp.uba.ar

Pulse siguiente y finalizar.

29

3. Configuracin de conexiones seguras (recibir/enviar correo cifrado)

Entre en Men Herramientas -> Cuentas de correo electrnico....
Pulse en Ver o cambiar cuentas de correo electrnico existentes

En la solapa Opciones Avanzadas active:
Servidor de Salida (SMTP): 25 (tambin est disponible el puerto 587)
Usar el siguiente tipo de conexin cifrada: TLS
Servidor de entrada (POP3): 995
Este servidor precisa una conexin cifrada(SSL)
Si est configurando correo entrante (IMAP)
Servidor de entrada (IMAP): 993
Este servidor precisa una conexin cifrada(SSL)

Nota: enversiones antiguas de Outlook, hay que configurar el tipo de conexinn saliente
como SSL.

30

En la solapa Servidor de salida active:
Mi servidor de salida (SMTP) requiere autenticacin.

Nota: la autenticacin con el servidor de salida es obligatoria. Con ella el servidor le pedir la
clave de su cuenta de correo para poder enviar mensajes.

En el botnn "Configuracin" compruebe que est marcada la opcin
Informacin de inicio de session
Usar misma configuracin que el servidor de correo entrante

31

4. Personalizacin para alias de correo

Si utiliza un alias institucional para enviar mensajes de correo, debera cambiar tanto el nombre como
la direccin de origen. Aunque enve con la direccin institucional debera autenticarse
Obligatoriamente para enviar con su cuenta personal como se ha indicado anteriormente.

Entre en Men Herramientas -> Cuenta....
Pulse en el botn Propiedades de la cuenta.
Entre en la Solapa General

En el apartado Informacin del usuario:
Introduzca el nombre de la unidad organizativa.
Introduzca la direccin de correo del alias.
Recuerde que aunque enva desde una direccin institucional, debera autenticarse
con su contrasea personal para poder enviar mensajes de correo.
Nota: El programa Profiles del Servicio de Informtica tambin permite configurar
alias de correo institucionales.

32

5. Comprobacin de la configuracin.

Si todo est correctamente configurado, al enviar correo le solicitara la
contrasea de la cuenta de usuario que indica en el apartado 2.

33

Escenarios:

34

Planificacion POP3
De la RFC 1939, podemos extraer el siguiente comportamiento:

Al iniciar una conexin a un servidor POP, el cliente de correo debe abrir una conexin
TCP en el puerto 110 del servidor. Cuando la conexin se efecta correctamente, el
servidor POP enva al cliente POP una invitacin y a continuacion las dos mquinas se
envan mutuamente otras rdenes y respuestas que se especifican en el protocolo.
En este intercambio de informacion, al cliente POP se le pide que se autentifique (Estado
de autenticacin), donde el nombre de usuario y la contrasea del usuario se envan al
servidor POP. Si la autenticacin es correcta, el cliente POP pasa al Estado de
transaccin.
Los comandos en POP3 son de una palabra cdigo case-sensitive, seguida de uno o mas
argumentos. Todos los comandos terminan con el par de palabras CR LF. Las palabras
cdigo tienen 3 o 4 caracteres de largo, cada argumento puede tener un largo mximo de
40 caracteres.
Las respuestas en POP3 consisten en una indicacin de estado y una palabra cdigo
posiblemente seguida de informacin adicional, todas las respuestas terminan en el par
CR LF. Hay generalmente 2 estados que se indican: positivo (+OK) y negativo (-
ERR)
Una sesin POP3 pasa por los siguientes estados:
AUTHORIZATION state
TRANSACTION state
UPDATE state

Comandos POP3:

Minimal POP3 Commands:

USER name valid in the AUTHORIZATION state
PASS string
QUIT

STAT valid in the TRANSACTION state
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT

Optional POP3 Commands:

APOP name digest valid in the AUTHORIZATION state

TOP msg n valid in the TRANSACTION state
UIDL [msg]
35

POP3 Replies:

+OK
-ERR

Los mensajes definidos para su eliminacin no se quitan realmente del servidor hasta que
el cliente POP enva la orden QUIT para terminar la sesin. En ese momento, el servidor
POP pasa al Estado de actualizacin, fase en la que se eliminan los mensajes marcados y
se limpian todos los recursos restantes de la sesin.

Capturas con Wireshark

1. Inicion de conexin.

Detalles:

2. Autorizacion

36

Detalles:

37

3. Transaccin
Los comandos que capturamos que pertenecen a este estado son los siguientes:
STAT

Detalles

LIST

Detalles

38

RETR

Detalles

39

40

DELE

Detalles

4. Estado de Update

Detalles

5. Cierre de sesin TCP

41

Planificaion IMAP
Nos basamos en la RFC 3501, de ah sacamos las siguientes definiciones.
IMAP es un protocolo de aplicacin, se basa en TCP y el puerto que utiliza es el 143.

"Connection": Se refiere a la totalidad de las secuencias de iteracin entre el cliente y el
servidor, desde el establecimiento de la conexin hasta su fin.

"Session": Se refiere a las secuencias de iteraciones cliente/servidor desde el momento en
que la casilla de correo es seleccionada (comandos SELECT o EXAMINE) hasta el
momento en que esta seleccin termina por ejecutar por los siguientes motives (ejecutar
comandos SELECT o EXAMINE de otra casilla de correo, ejecutar el comando CLOSE,
o por terminar la conexin).

Comandos y Respuestas
Una conexin IMAPrev4 consiste en el establecimiento de una conexin de red
cliente/servidor, un saludo inicial por parte del server, e intercambios cliente/servidor.
Estos intercambios cliente/servidor son los siguientes: comandos por parte de los clientes,
datos del servidor y repuestas procesadas por parte del servidor.
Todo el intercambio transmitido entre el cliente y el servidor es en forma de lneas, esto
es cadena de caracteres que terminan en CRLF y el protocolo tanto en el cliente como en
el servidor se basa en la lectura de estas lneas.

Estados y Diagrama de flujo
Existen 4 estados en una comunicacin IMAP, la mayora de los comandos son solo
validos en determinados estados, si el servidor recibe un comando que no corresponde
con el estado en el que se encuentra, responde con BAD:
a. Not Authenticated State
b. Authenticated State
c. Selected State
d. Logout State

Como los mismas pasan de un estado a otro se puede ver en el siguiente diagrama.

42

(1) connection without pre-authentication (OK greeting)
(2) pre-authenticated connection (PREAUTH greeting)
(3) rejected connection (BYE greeting)
(4) successful LOGIN or AUTHENTICATE command
(5) successful SELECT or EXAMINE command
(6) CLOSE command, or failed SELECT or EXAMINE command
(7) LOGOUT command, server shutdown, or connection closed

Algunos comandos:
CAPABILITY: Consulta las propiedades disponibles en el server
IDLE: para saber si hay un Nuevo correo por recoger
LIST: Muestra la lista de mensajes y su estado
LSUB: Devuelve una respuesta etiquetada como una aceptacin
SUBSCRIBE: Aade un nuevo nombre al buzn
STATUS: Indica el estado del buzn
43

REAME: Renombra o cambia de nombre al buzn
EXPUGE: Borra todos los mensajes del buzn
CREATE. Crea un buzon con el nombre especificado.
Capturas
Inicio de la conexin TCP al puerto 143:

Respuesta del servidor a la conexin:

Pedido por parte del Cliente las caractersticas del Servidor:

44

Respuesta del Servidor al pedido de caracteristicas:

A continuacin podemos apreciar los distintos comandos y respuestas en las capturas
realizadas:

45

Captura de la lectura de un mensaje:

Detalles de cada uno de los comandos:
IDLE

DONE

46

UID FETCH

FETCH parametros y cuerpo del mensaje.

47

Cuerpo del mensaje

COCLUSIOES
Como podemos darnos cuenta claramente el protocolo POP sirve usar en una cuenta
de correo para poder descargar los correos al host desde un servidor pero bajndolos
del mismo el cual una vez descargado ya no figura y no es no es necesario estar
conectado al internet o servidor para revisarlo solo para bajarlo y enviar nada mas.

El protocolo IMAP se encarga de las cuentas de correo poder revisarlas durante la
conexin del servidor y los correos no se bajan solo se puedes leer y enviar pero se
tiene que estar conectado con el servidor de correo.

Adems del anlisis por las capturas nos podemos dar cuenta es tipo de negociacin que
tiene dicho protocolo para poder intercambiar paquetes tanto de servidor cliente como
viceversa. el protocolo IMAP4 permite accesos simultneos a mltiples clientes y
proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a
un buzn por otro cliente concurrentemente conectado.

Al utilizar IMAP, los clientes permanecen conectados el tiempo que su interfaz
permanezca activa y descargan los mensajes bajo demanda. Esta manera de trabajar de
IMAP puede dar tiempos de respuesta ms rpidos para usuarios que tienen una gran
cantidad de mensajes o mensajes grandes.

Lab DNS Pop Imap

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lab DNS Pop Imap

Загружено:

Авторское право:

Доступные форматы

LABORATORIO DE REDES TCP/IP

Вам также может понравиться