PROTOCOLOS: DNS, IMAP Y POP3

Transcripción

“LABORATORIO DE REDES TCP/IP”
TRABAJO PRÁCTICO
PROTOCOLOS: DS, IMAP Y POP3
PROFESORES:
- Ing. Marcelo Utard
- Ing. Javier Bozzuto
ITEGRATES:
- Walter Luna
- José Zerda
- Julio Cabrera
- René Garay
Miércoles 3 de Diciembre del 2008
LABORATORIO DE REDES
“PROTOCOLO DS”
•
Introducción
A continuación recordaremos brevemente las estructuras que contiene el protocolo DNS
en su formato genérico, 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 número que representa la cantidad de preguntas que
contiene el mensaje.
Total de respuestas: es un número que representa la cantidad de respuestas que
contiene el mensaje.
Total de registros Autoritarios: es un número que representa la cantidad de
servidores autoritarios que tienen relevancia en las respuestas
Total de registros adicionales: es un número 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
dirección IP
2
Tipo: existe una larga lista de tipos existentes y se detallan a continuación:
Type
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Description
A, IPv4 address.
NS, Authoritative name server.
MD, Mail destination. Obsolete use MX instead.
MF, Mail forwarder. Obsolete use MX instead.
CNAME, Canonical name for an alias.
SOA, Marks the start of a zone of authority.
MB, Mailbox domain name.
MG, Mail group member.
MR, Mail rename domain name.
NULL, Null resource record.
WKS, Well known service description.
PTR, Domain name pointer.
HINFO, Host information.
MINFO, Mailbox or mail list information.
MX, Mail exchange.
TXT, Text strings.
RP, Responsible Person.
AFSDB, AFS Data Base location.
X25, X.25 PSDN address.
ISDN, ISDN address.
RT, Route Through.
NSAP, NSAP address. NSAP style A record.
NSAP-PTR.
24
SIG, Security signature.
25
KEY, Security key.
26
27
28
29
30
31
32
PX, X.400 mail mapping information.
GPOS, Geographical Position.
AAAA, IPv6 Address.
LOC, Location Information.
NXT, Next Domain (obsolete).
EID, Endpoint Identifier.
NIMLOC, Nimrod Locator.
References
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1035
RFC 1183
RFC 1183
RFC 1183
RFC 1183
RFC 1183
RFC 1706
RFC 1348
RFC 2931, RFC
4034
RFC 3445, RFC
4034
RFC 2163
RFC 1712
RFC 3596
RFC 1876
RFC 2535
3
NB, NetBIOS general Name Service.
RFC 1002
RFC 2052, RFC
2782
RFC 1002
33
SRV, Server Selection.
NBSTAT, NetBIOS NODE STATUS.
34
35
36
ATMA, ATM Address.
NAPTR, Naming Authority Pointer.
KX, Key Exchanger.
37
CERT.
38
A6.
39
40
41
42
43
44
45
46
DNAME.
SINK.
OPT.
APL.
DS, Delegation Signer.
SSHFP, SSH Key Fingerprint.
IPSECKEY.
RRSIG.
47
NSEC.
48
49
50
51
52
53
54
55
56
98
99
100
101
102
103
104
-
DNSKEY.
DHCID, DHCP identifier.
NSEC3.
NSEC3PARAM.
RFC 2671
RFC 3123
RFC 3658
RFC 4255
RFC 4025
RFC 3755
RFC 3755, RFC
3845
RFC 3755
RFC 4701
RFC 5155
RFC 5155
HIP, Host Identity Protocol.
RFC 5205
SPF, Sender Policy Framework.
UINFO.
UID.
GID.
UNSPEC.
RFC 4408
RFC 3403
RFC 2230
RFC 2538, RFC
4398
RFC 2874, RFC
3226
RFC 2672
4
248
249 TKEY.
250 TSIG, Transaction Signature.
RFC 2930
RFC 2845, RFC
3645
RFC 1995
RFC 1035
251 IXFR, Incremental transfer.
252 AXFR, A request for a transfer of an entire zone.
MAILB, A request for mailbox-related records (MB, MG or
RFC 1035
253
MR).
RFC 1035
254 MAILA, A request for mail agent RRs. Obsolete.
RFC 1035
255 *. A request for all records.
256
32767
32768 DNSSEC Trust Authorities.
RFC 4431, RFC
32769 DNSSEC Lookaside Validation.
5074
Los más destacados son:
Tipo A: hace referencia a una típica consulta de conversión de nombre de
dominio en una dirección 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 canónico de un alias.
Clase: hace referencia a algún ítem de la siguiente lista:
Class
Description
References
0 Reserved.
RFC 1035.
1 IN, Internet.
2
RFC 1035.
3 CH, Chaos.
RFC 1035.
4 HS, Hesiod.
5
253
RFC 2136.
254 None.
255 Any (QCLASS only). RFC 1035.
256
65535
5
De esta última en la gran mayoría de las veces se utiliza clase 1 de Internet.
Es importante mencionar como funciona el mecanismo de resolución de la dirección IP.
Todo comienza por el resolver que se encuentra en la maquina cliente. Este envía 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 excepción en donde la consulta no puede ser
recursiva y es iterativa. Es decir que el DNS Server consultado responde con otra
dirección (hasta llegar al servidor autoritativo) en donde consultar para obtener la
respuesta. Este es el caso de los servidores denominados raíz (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. También se busca tener mecanismos de redundancia frente a fallas de hardware y
caídas del sistema.
El formato de la respuesta posee la siguiente estructura:
Esta estructura, aparte de contener los dos campos descriptos en la sección de query (tipo
y clase), además 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…
6
Escenario 1
•
Planificación
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 continuación:
Dado este escenario, se decide realizar un ping al muy conocido al site
www.yahoo.com, para que en el proceso de resolución de dicho comando se ejecuten la
secuencia de instrucciones que esperamos obtener y detallaremos a continuación.
Secuencia de eventos y resultados esperados
1. Se ejecuta el comando ping www.yahoo.com
Con el objeto de que la PC realice una operación de resolución 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
dirección al site elegido se ingresa por primera vez después de mucho
tiempo
2. El comando necesita resolver la dirección del dominio a una dirección IP.
7
Este es el caso para el cual el protocolo DNS fue creado, poder convertir
un nombre fácil de recordar por un ser humano en una dirección 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 dirección IP de dicho site (DNS Answer)
5. El comando ping envía los mensajes ICMP correspondientes.
Esta parte del análisis escapa al alcance de este informe cuyo principal y
único objetivo es el protocolo DNS
•
Ejecución
La ejecución de dicha planificación 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 continuación:
En el diagrama de flujo se pueden observar los siguientes eventos:
8
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
después sin haber recibido respuesta alguna.
Evento 3: Se recibe una respuesta del servidor DNS número 1, consultado en el evento 1.
Evento 4: Con la resolución de la dirección IP, el equipo envió el primer mensaje ICMP
(Echo request) para realizar el comando ping.
Evento 5: Se recibe la respuesta del servidor DNS número 2, consultado en el evento 2.
Esto es un evento no esperado en la planificación de la prueba. Dado que no se
contemplaban dos consultas.
Evento 6: Secuencias de transmisión y recepción de echo request y echo reply
respectivamente.
A continuación procedemos a detallar algunas características 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,
evalúa la dirección 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
MAC origen
IP destino
MAC destino
192.168.1.100
00:1A:73:EE:C3:80
200.45.191.35
00:21:29:69:C5:AA
IP de WALLAS
MAC de WALLAS
Servidor DNS 1
MAC de router CISCO
Como se puede observar en la captura de la siguiente figura
9
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 están vacíos.
La pregunta es de tipo A, es decir una típica conversión de nombre de domino (en este
caso www.yahoo.com) a dirección 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
continuación:
IP origen
MAC origen
IP destino
MAC destino
192.168.1.100
00:1A:73:EE:C3:80
200.45.48.233
00:21:29:69:C5:AA
IP de WALLAS
MAC de WALLAS
Servidor DNS 2
MAC de router CISCO
Nuevamente se corrobora dicha tabla con la captura que a continuación se muestra.
Notar que esta consulta es exactamente igual a la anterior BIT a BIT exceptuando la
dirección IP destino de la misma.
10
Evento 3:
Este evento corresponde a la respuesta del servidor DNS número 1 por lo que la tabla de
direcciones queda:
IP origen
MAC origen
IP destino
MAC destino
200.45.191.35
00:21:29:69:C5:AA
192.168.1.100
00:1A:73:EE:C3:80
IP de Servidor DNS 1
MAC de router CISCO
IP de WALLAS
MAC de WALLAS
Como se puede observar a continuación, se encuentra la captura de dicha respuesta.
Notar que el puerto de origen en este caso es el bien conocido 53 al puerto efímero
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
mínimo 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. Recién en la consulta siguiente, se paso de
www-real.wa1.b.yahoo.com a la dirección IP: 69.147.76.15. Es muy importante destacar
en dicho proceso de obtención de la dirección IP, se obtuvieron un conjunto de servidores
autoritativos. Esta información es de gran utilidad para el cache DNS del servidor DNS y
se encuentra detallada en la sección de registros autoritativos de al estructura del
11
protocolo DNS. En la última sección de dicha estructura, se encuentran los registros de
información adicional que detallan las direcciones IP de los servidores autoritativos de la
sección anterior.
Evento 4:
Con la resolución de la dirección 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 continuación:
Como era de esperar, la respuesta del servidor DNS numero 2 llega aunque ya no es
necesaria. En dicha respuesta se puede observar que también se han recibido tres
respuestas. Ahí vemos que los alias informados (www.wa1.b.yahoo.com , wwwreal.wa1.b.yahoo.com) son los mismos que se detallan en el evento 3. Por ultimo, como
es esperable, la dirección IP enviada como respuesta es la misma también. En el campo
12
de registros de servidores autoritativos, hemos recibido la lista de todos (13) los
servidores raíz 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 conclusión, podemos decir que en términos generales el resultado obtenido
se encuentra dentro de las expectativas. Es decir que la sucesión de paquetes DNS
concuerdan con lo descripto en la sección de resultados esperados. Cabe mencionar un
par de eventos inesperados a la hora de la ejecución. Uno de estos eventos fue el envío 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 planificación. Estimamos que es un
parámetro programable en alguna sección de configuración del sistema operativo
utilizado (Windows Vista en este caso). Otro evento que nos sorprendió, fue la recepción
del listadlo de los trece servidores raíz 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. También 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
•
Planificación
Maqueta
La maqueta sobre la cual se desarrolla la segunda ejecución, se encuentra
detallada a continuación:
Se ha decidido armar una pequeña red con servidor DNS incluido en ella. Se
ejecuta el comando ping desde una maquina y se monitorea la comunicación que se
establece con dicho servidor DNS. La idea de este escenario es poder visualizar los
13
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 operación de resolución de nombre de dominio a IP, a una
dirección inexistente.
2. El comando necesita resolver la dirección en su formato qdfn a una
dirección 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)
•
Ejecución
La ejecución de dicha planificación 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 continuación:
En el diagrama de flujo se pueden observar los siguientes eventos:
Evento 1: El equipo con dirección 192.168.112.128 realiza una consulta DNS al servidor
DNS dirección 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
configuración. En este caso particular la realiza hacia el servidor 192.112.36.4
(Columbus, Ohio, U.S.).
14
Evento 3: Se realiza la misma consulta a otro de los servidores Root que se tienen
guardado en la configuración. 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) envía
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 información 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,
extensión .co), el mensaje “No such name”.
Evento 7: Nuestro servidor DNS envía al host 192.168.112.128 que realizo la consulta
inicial el mismo mensaje recibido anteriormente “No such name”.
A continuación procedemos a detallar algunas características 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,
evalúa la dirección de dicho servidor, la encuentra en su propia red y le envía la consulta
DNS. Esto se traduce a la siguiente tabla:
IP origen
MAC origen
IP destino
MAC destino
192.168.112.128
00:0C:29:C3:FA:60
192.168.112.129
00:0C:29:2F:2C:4F
IP de Nicaragüita
MAC de Nicaragüita
Servidor DNS interno
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.
15
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 están vacíos.
La pregunta es de tipo A, es decir una típica conversión de nombre de domino (en este
caso www.collazos.com.co) a dirección 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
continuación:
IP origen
MAC origen
IP destino
MAC destino
192.168.112.129
00:0C:29:2F:2C:4F
192.112.36.4
00:50:56:F5:50:4D
IP de DNS Local
MAC de Nicaragüita
Servidor DNS Root G
MAC del default geteway
Nuevamente se corrobora dicha tabla con la captura que a continuación 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 parámetro 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 estarán 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
había perdido. De cualquier forma, se envía exactamente la misma consulta a otro
servidor Root de su lista. (evento que sigue).
16
Evento 3:
En este evento se reenvía la misma consulta pero esta vez hacia otro servidor raíz,
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 recepción en
ninguno de los equipos, se realizan consultas múltiples y simultáneas. Por lo que la tabla
de direcciones queda:
IP origen
MAC origen
IP destino
MAC destino
192.168.112.129
00:0C:29:2F:2C:4F
193.0.14.129
00:50:56:F5:50:4D
IP de Servidor DNS local
MAC del servidor DNS local
IP de DNS Root K
MAC de default geteway
Como se puede observar a continuación, se encuentra la captura de dicha respuesta.
Esta consulta es exactamente igual a la anterior con la diferencia de que cambia la
dirección 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 raíz K, la tabla
de direcciones quedará como sigue:
IP origen
MAC origen
IP destino
MAC destino
193.0.14.129
00:50:56:F5:50:4D
192.168.112.129
00:0C:29:2F:2C:4F
IP de DNS Root K
MAC de default Gateway
IP del servidor DNS local
17
A continuación la pantalla de la captura:
En esta captura se observa que el servidor raíz K no envía respuesta final sobre la
dirección correspondiente a la consulta pero si envía 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 próximo evento. El campo Recursion
Available de los flags está en “0”, comprueba el hecho de que los servidores raíz solo
permiten o entregan consultas no Recursivas. Los servidores autoritativos que se reciben
como lugares de posible búsqueda, corresponden a dos ramas principales: 4 para la rama
“.CO” correspondiente a las páginas en Colombia y 1 ultimo para la rama EDU
correspondiente a todas las organizaciones relacionadas con la Educación.
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
MAC origen
IP destino
MAC destino
192.168.112.129
00:0C:29:2F:2C:4F
157.253.99.15
00:50:56:F5:50:4D
IP de Servidor DNS local
IP de NS, NS1.nic.co
MAC de default geteway
18
En este evento se ve como se envía 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 típica. 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
MAC origen
IP destino
MAC destino
157.253.99.15
00:50:56:F5:50:4D
192.168.112.129
00:0C:29:2F:2C:4F
IP de NS, NS1.nic.co
MAC de default Gateway
IP del servidor DNS local
19
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 envía un servidor de este
tipo. Como toda respuesta a cualquier consulta realizada, en el segmento “Queries” se
copia la consulta original realizada. También 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 envía finalmente una respuesta al host que
realizo la consulta originalmente. Por lo que la tabla de direcciones queda como sigue:
IP origen
MAC origen
IP destino
MAC destino
192.168.112.129
00:0C:29:2F:2C:4F
192.168.112.128
00:0C:29:C3:FA:60
Servidor DNS interno
MAC del Servidor DNS Local
IP de Nicaragüita
MAC de Nicaragüita
20
En este ultimo evento se envía 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 básicamente 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
código del flag REPLY CODE 3 para el evento “no such name”. Hemos podido
comprobar utilizando esta topología de red con el servidor DNS y el HUB las
comunicaciones y pedidos de un servidor DNS resolviendo la dirección de forma iterativa
que fue muy didáctico 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
después. 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 detección de
no recepción en ninguna de las dos partes. Es por eso que creemos que los DNS Server
envían varias consultas a la vez, para sobrellevar eventualidades como estas. También se
pudo observar la división que existe en dominios de autoridad con servidores de
comienzo de zonas. Esto permite lograr una descentralización crucial para lograr un
sistema que intente disminuir la congestión de un equipo en particular y permite la
escalabilidad de la metodología.
21
De igual forma se nos hace muy interesante mostrar cómo se va armando la
estructura del árbol DNS dentro del servidor. A continuación mostramos la imagen de la
consola de configuración de DNS de Windows server 2003:
Se puede ver como se han agregado el árbol de la raíz “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 terminación UNIANDES y al consultar a algún
servidor de esta ultima rama término la consulta.
22
“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 recepción de correo electrónico más utilizados,
que soportan la mayoría de los servidores de correo electrónico y programas clientes
como Outlook Express o Mozilla Thunderbird. También podemos referirnos a ellos con
sus números de versión POP3 e IMAP4.
Existen varias diferencias, pero digamos que IMAP es más novedoso y permite más
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
sólo los que el cliente solicite. Además, lo normal cuando se accede a un correo con POP
es que los mensajes se borren del servidor según se descargan, mientras que por IMAP al
visualizar un mensaje no se borra del servidor, a no ser que se elimine explícitamente.
Otras diferencias es que con POP sólo se puede conectar un usuario para descargar el
correo electrónico y con IMAP se pueden conectar más de un usuario a la misma cuenta.
En cuanto a lo más recomendable, si POP o IMAP, eso depende del uso que des a tu
correo y el modo de conexión.
Con POP puedes descargar todos los mensajes en tu ordenador en un pequeño 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 conexión a Internet no podrás 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. Además, si cambias de ordenador en cualquier momento, podrás acceder
a tus mensajes igualmente, porque por IMAP todos los mensajes están disponibles desde
cualquier ordenador conectado a Internet.
Por lo tanto, con POP si descargas los mensajes, se guardarán en tu ordenador y tendrás
que tener tu ordenador para leer el correo antiguo. Si los miras por IMAP seguirán
almacenándose 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.
23
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. Además, al leer los mensajes y bajarlos a nuestro ordenador, liberamos espacio en
nuestro buzón del Host, con lo cual tenemos menos probabilidades que por descuido se
nos llene el buzón y no podamos recibir más mensajes. Es el más extendido
(prácticamente 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 leídos por terceras personas, al no quedarse en el PC, además, si
no tenemos la posibidad de conectarnos siempre del mismo ordenador, conseguimos
siempre acceder a la totalidad de nuestros mensajes. Hay que tener la precaución de ir
borrandolos de vez en cuando para no sobrepasar el límite de capacidad de nuestro buzón.
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 más 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. Además, 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 conexión a Internet no permanente, sin tarifa
plana, o con un coste alto por minuto (por ejemplo conexión de un portátil mediante un
móvil). En estos casos el protocolo POP te permite conectar al servidor, descargar los
mensajes, cortar la conexión y procesar las copias locales de los mensajes.
POP fue diseñado para ser fácil de implementar, pero tiene varias deficiencias en su
funcionamiento:
No maneja correctamente múltiples carpetas.
Fuerza la descarga completa de los mensajes. En vez de descargar al ordenador del
usuario sólo la cabecera “Asunto:” para que decida si el mensaje debe ser borrado o leído,
24
descarga el mensaje completo con todos sus archivos adjuntos y una vez descargado es
cuando el usuario puede procesarlo.
Por último y lo más 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
conexión y por tanto, a partir de este momento, no será visible desde ningún 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
opción 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 leído o
no; en la actualidad, con arquitecturas complejas de mensajería 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 diseñado 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 electrónico conecta al servidor y
descarga exclusivamente las cabeceras de los mensajes. Los mensajes quedan
almacenados en el “buzón del usuario” dentro de la estafeta y, por tanto, pueden ser
procesados nuevamente desde cualquier otro ordenador o localización. 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 conexión con la estafeta hasta
finalizar la consulta y por tanto no es aconsejable cuando disponemos de una conexión
con un alto coste por minuto y no permanente.
Lo más interesante del protocolo IMAP es que al quedar los buzones y su contenido
situados físicamente en las estafetas centrales y no en el PC del usuario, nos permite
acceder a los mensajes desde diferentes ordenadores, aunque previamente los hayamos
leído desde otra máquina o programa. Es especialmente interesante en desplazamientos
fuera del entorno de trabajo pues los buzones y mensajes podrán leerse mediante el
servicio WEBMAIL durante el desplazamiento y posteriormente desde el cliente de
correo habitual en RedUGR.
25
EJECUCIO : creación de cuentas IMAP o POP
1.
Introducción
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 guía muestra cómo configurar un Outlook manualmente, si quiere realizar una
configuración automática puede utilizar el programa Profiles del Servicio de Informática.
Nota: En las pantallas que aparecen a continuación se utiliza como ejemplo la dirección
de correo [email protected] y la cuenta "usuario". Usted debería 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 electrónico....
Pulse en Agregar una nueva cuenta de correo electrónico
Si elije el protocolo POP3 siga los pasos 2.1a, en caso contrario siga los pasos 2.1b.
Más información: Diferentes entre POP3 e IMAP
26
2.1a Introduzca los siguientes datos para configurar una cuenta POP:
Tipo de servidor: POP3
Su nombre
Su dirección de correo
Nombre de usuario
Recordar contraseña: (opción
desactivada)
Iniciar sesión utilizando Autenticación
de contraseña de seguridad (SPA):
(opción 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
27
cuenta IMAP:
Tipo de servidor: IMAP
Su nombre
Su dirección de correo
Nombre de usuario
Recordar contraseña: (opciónn
desactivada)
Iniciar sesiónn utilizando
Autenticaciónn de
contraseña de seguridad (SPA):
(opciónn desactivada)
Servidor de correo entrante(pop3):
imap.uba.ar
Servidor de correo saliente (smtp):
smtp.uba.ar
Pulse siguiente y finalizar.
28
3.
Configuración de conexiones seguras (recibir/enviar correo cifrado)
Entre en Menú Herramientas -> Cuentas de correo electrónico....
Pulse en Ver o cambiar cuentas de correo electrónico existentes
En la solapa Opciones Avanzadas active:
Servidor de Salida (SMTP): 25 (también está disponible el puerto 587)
Usar el siguiente tipo de conexión cifrada: TLS
Servidor de entrada (POP3): 995
Este servidor precisa una conexión cifrada(SSL)
Si está configurando correo entrante (IMAP)
Servidor de entrada (IMAP): 993
Este servidor precisa una conexión cifrada(SSL)
Nota: enversiones antiguas de Outlook, hay que configurar el tipo de conexiónn saliente
como SSL.
29
En la solapa Servidor de salida active:
Mi servidor de salida (SMTP) requiere autenticación.
Nota: la autenticación 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 botónn "Configuración" compruebe que está marcada la opción
Información de inicio de session
Usar misma configuración que el servidor de correo entrante
30
4.
Personalización para alias de correo
Si utiliza un alias institucional para enviar mensajes de correo, debería cambiar tanto el nombre como
la dirección de origen. Aunque envíe con la dirección institucional debería autenticarse
Obligatoriamente para enviar con su cuenta personal como se ha indicado anteriormente.
Entre en Menú Herramientas -> Cuenta....
Pulse en el botón Propiedades de la cuenta.
Entre en la Solapa General
En el apartado Información del usuario:
Introduzca el nombre de la unidad organizativa.
Introduzca la dirección de correo del alias.
Recuerde que aunque envía desde una dirección institucional, debería autenticarse
con su contraseña personal para poder enviar mensajes de correo.
Nota: El programa Profiles del Servicio de Informática también permite configurar
alias de correo institucionales.
31
5.
Comprobación de la configuración.
Si todo está correctamente configurado, al enviar correo le solicitaría la
contraseña de la cuenta de usuario que indica en el apartado 2.
32
Escenarios:
33
Planificacion POP3
De la RFC 1939, podemos extraer el siguiente comportamiento:
Al iniciar una conexión a un servidor POP, el cliente de correo debe abrir una conexión
TCP en el puerto 110 del servidor. Cuando la conexión se efectúa correctamente, el
servidor POP envía al cliente POP una invitación y a continuacion las dos máquinas se
envían 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 autenticación), donde el nombre de usuario y la contraseña del usuario se envían al
servidor POP. Si la autenticación es correcta, el cliente POP pasa al Estado de
transacción.
Los comandos en POP3 son de una palabra código case-sensitive, seguida de uno o mas
argumentos. Todos los comandos terminan con el par de palabras CR LF. Las palabras
código tienen 3 o 4 caracteres de largo, cada argumento puede tener un largo máximo de
40 caracteres.
Las respuestas en POP3 consisten en una indicación de estado y una palabra código
posiblemente seguida de información adicional, todas las respuestas terminan en el par
CR LF. Hay generalmente 2 estados que se indican: positivo (“+OK”) y negativo (“ERR”)
Una sesión POP3 pasa por los siguientes estados:
AUTHORIZATION state
TRANSACTION state
UPDATE state
Comandos POP3:
Minimal POP3 Commands:
USER name
PASS string
QUIT
STAT
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT
valid in the AUTHORIZATION state
valid in the TRANSACTION state
Optional POP3 Commands:
APOP name digest
TOP msg n
UIDL [msg]
valid in the AUTHORIZATION state
valid in the TRANSACTION state
34
POP3 Replies:
+OK
-ERR
Los mensajes definidos para su eliminación no se quitan realmente del servidor hasta que
el cliente POP envía la orden QUIT para terminar la sesión. En ese momento, el servidor
POP pasa al Estado de actualización, fase en la que se eliminan los mensajes marcados y
se limpian todos los recursos restantes de la sesión.
Capturas con Wireshark
1. Inicion de conexión.
Detalles:
2. Autorizacion
35
Detalles:
36
3. Transacción
Los comandos que capturamos que pertenecen a este estado son los siguientes:
• STAT
Detalles
•
LIST
Detalles
37
•
RETR
Detalles
38
39
DELE
Detalles
4. Estado de Update
Detalles
5. Cierre de sesión TCP
40
Planificaion IMAP
Nos basamos en la RFC 3501, de ahí sacamos las siguientes definiciones.
IMAP es un protocolo de aplicación, se basa en TCP y el puerto que utiliza es el 143.
"Connection": Se refiere a la totalidad de las secuencias de iteración entre el cliente y el
servidor, desde el establecimiento de la conexión 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 selección 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 conexión).
Comandos y Respuestas
Una conexión IMAPrev4 consiste en el establecimiento de una conexión 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 líneas, 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 líneas.
Estados y Diagrama de flujo
Existen 4 estados en una comunicación IMAP, la mayoría 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.
41
(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 aceptación
SUBSCRIBE: Añade un nuevo nombre al buzón
STATUS: Indica el estado del buzón
42
REAME: Renombra o cambia de nombre al buzón
EXPUGE: Borra todos los mensajes del buzón
CREATE. Crea un buzon con el nombre especificado.
Capturas
Inicio de la conexión TCP al puerto 143:
Respuesta del servidor a la conexión:
Pedido por parte del Cliente las características del Servidor:
43
Respuesta del Servidor al pedido de caracteristicas:
A continuación podemos apreciar los distintos comandos y respuestas en las capturas
realizadas:
44
Captura de la lectura de un mensaje:
Detalles de cada uno de los comandos:
IDLE
DONE
45
UID FETCH
FETCH parametros y cuerpo del mensaje.
46
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 bajándolos
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
conexión 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.
Además del análisis por las capturas nos podemos dar cuenta es tipo de negociación que
tiene dicho protocolo para poder intercambiar paquetes tanto de servidor –cliente como
viceversa. el protocolo IMAP4 permite accesos simultáneos a múltiples clientes y
proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a
un buzón 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 más rápidos para usuarios que tienen una gran
cantidad de mensajes o mensajes grandes.
47

PROTOCOLOS: DNS, IMAP Y POP3

Transcripción

Documentos relacionados

DNS Dinámico (DDNS): Elabora un informe del programa DNS2Go