PROTOCOLOS: DNS, IMAP Y POP3
Anuncio
“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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 MAC del servidor DNS local 17 LABORATORIO DE REDES 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 MAC del servidor DNS local IP de NS, NS1.nic.co MAC de default geteway 18 LABORATORIO DE REDES La captura de dicho evento se detalla a continuación: 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 MAC del servidor DNS local 19 LABORATORIO DE REDES La captura de dicho evento se detalla a continuación: 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 LABORATORIO DE REDES La captura de dicho evento se detalla a continuación: 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES “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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 usuario@prueba.ar 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES Escenarios: 33 LABORATORIO DE REDES 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 LABORATORIO DE REDES 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 LABORATORIO DE REDES Detalles: 36 LABORATORIO DE REDES 3. Transacción Los comandos que capturamos que pertenecen a este estado son los siguientes: • STAT Detalles • LIST Detalles 37 LABORATORIO DE REDES • RETR Detalles 38 LABORATORIO DE REDES 39 LABORATORIO DE REDES DELE Detalles 4. Estado de Update Detalles 5. Cierre de sesión TCP 40 LABORATORIO DE REDES 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 LABORATORIO DE REDES (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 LABORATORIO DE REDES 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 LABORATORIO DE REDES Respuesta del Servidor al pedido de caracteristicas: A continuación podemos apreciar los distintos comandos y respuestas en las capturas realizadas: 44 LABORATORIO DE REDES Captura de la lectura de un mensaje: Detalles de cada uno de los comandos: IDLE DONE 45 LABORATORIO DE REDES UID FETCH FETCH parametros y cuerpo del mensaje. 46 LABORATORIO DE REDES 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
