martes, 30 de septiembre de 2008

PROTOCOLO DNS

COMO FUNCIONA EL DNS

El DNS se utiliza principalmente para la resolución de nombres, esto es, decidir qué dirección IP pertenece a determinado nombre completo de host.

USOS DEL DNS

El DNS se utiliza para distintos propósitos. Los más comunes son:

  • Resolución de nombres: Dado el nombre completo de un host (por ejemplo blog.smaldone.com.ar), obtener su dirección IP (en este caso, 208.97.175.41).
  • Resolución inversa de direcciones: Es el mecanismo inverso al anterior. Consiste en, dada una dirección IP, obtener el nombre asociado a la misma.
  • Resolución de servidores de correo: Dado un nombre de dominio (por ejemplo gmail.com) obtener el servidor a través del cual debe realizarse la entrega del correo electrónico (en este caso, gmail-smtp-in.l.google.com).

Por tratarse de un sistema muy flexible, es utilizado también para muchas otras funciones, tales como la obtención de claves públicas de cifrado asimétrico y la validación de envío de e-mails (a través de mecanismos como SPF).

Terminología Básica

Antes de proseguir, es necesario introducir algunos términos básicos para evitar confusiones y ambigüedades. Otros términos más complejos serán tratados más adelante.

  • Host Name: El nombre de un host es una sola “palabra” (formada por letras, números y guiones). Ejemplos de nombres de host son “www“, “blog” y “obelix“.
  • Fully Qualified Host Name (FQHN): Es el “nombre completo” de un host. Está formado por el hostname, seguido de un punto y su correspondiente nombre de dominio. Por ejemplo, “blog.smaldone.com.ar
  • Domain Name: El nombre de dominio es una sucesión de nombres concatenados por puntos. Algunos ejemplos son “smaldone.com.ar“, “com.ar” y “ar“.
  • Top Level Domains (TLD): Los dominios de nivel superior son aquellos que no pertenecen a otro dominio. Ejemplos de este tipo son “com“, “org“, “ar” y “es“.
Arquitectura del DNS

El sistema DNS funciona principalmente en base al protocolo UDP. Los requerimientos se realizan a través del puerto 53.

El sistema está estructurado en forma de “árbol“. Cada nodo del árbol está compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algún subdominio de la zona sobre la que él tiene autoridad). Un subdominio puede verse como una especialización de un dominio de nivel anterior. Por ejemplo, “smaldone.com.ar” es un subdominio de “com.ar“, que a su vez lo es del TLDar“.

Los servidores con autoridad sobre los TLD son los llamados “root servers” (o “servidores raíz“) del sistema. Estos son fijos, ya que rara vez cambian, siendo actualmente 13.

Tomemos como ejemplo el dominio “com.ar“. Este dominio pertenece al TLDar“.

Los servidores con autoridad sobre el dominio “ar” son:

ns-ar.ripe.net
merapi.switch.ch
uucp-gw-1.pa.dec.com
uucp-gw-2.pa.dec.com
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar

En tanto que los servidores con autoridad sobre “com.ar” son:

merapi.switch.ch
relay1.mecon.gov.ar
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar

Podemos ver que ns.uu.net, ns1.retina.ar, athea.ar y ctina.ar tienen autoridad tanto sobre “com.ar” como sobre “ar“.

El Proceso de Resolución de Nombres

Cuando una aplicación (cliente) necesita resolver un FQHN envía un requerimiento al servidor de nombres configurado en el sistema (normalmente, el provisto por el ISP). A partir de entonces se desencadena el proceso de resolución del nombre:

  1. El servidor de nombres inicial consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente).
  2. Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.
  3. El servidor inicial interroga al nuevo servidor.
  4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.
  5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo interroga.
  6. El servidor resuelve el nombre correspondiente, si este existe.
  7. El servidor inicial informa al cliente el nombre resuelto.

Ilustremos esto con un ejemplo concreto. Supongamos que el navegador necesita resolver el nombre “blog.smaldone.com.ar“.

  1. El sistema tiene configurado el servidor de nombres 200.49.156.3 (perteneciente al proveedor argentino Fibertel). Por lo tanto envía a éste el requerimiento de resolver “blog.smaldone.com.ar“.
  2. El servidor de 200.49.156.3 envía la consulta root server 198.41.0.4.
  3. 198.41.0.4 le informa que el servidor con autoridad sobre “ar” es athea.ar, cuya dirección IP es 200.16.98.2. (En realidad, informa la lista de todos los servidores con tal autoridad, pero para simplificar el ejemplo tomaremos solamente uno.)
  4. 200.49.156.3 envía nuevamente el requerimiento a athea.ar (el cual, recordemos, también tiene autoridad sobre “com.ar“).
  5. athea.ar responde que la autoridad sobre smaldone.com.ar la tiene ns1.mydomain.com cuya dirección IP es 64.94.117.213.
  6. 200.49.156.3 envía ahora la consulta a ns1.mydomain.com.
  7. ns1.mydomain.com informa que la dirección IP de “blog.smaldone.com.ar” es 208.97.175.41.
  8. Finalmente, 200.49.156.3 devuelve este resultado a la aplicación que originó la consulta.
Mecanismos de Caché

Cada vez que un servidor de nombres envía una respuesta, lo hace adjuntando el tiempo de validez de la misma (TTL o “tiempo de vida“). Esto posibilita que el receptor, antes la necesidad de volver a resolver la misma consulta, pueda utilizar la información previamente obtenida en vez de realizar un nuevo requerimiento.

Esta es la razón por la cual los cambios realizados en el DNS no se propagan instantáneamente a través del sistema. Dependiendo de la naturaleza de los mismos (y de la configuración de cada servidor), la propagación puede tardar desde algunos minutos hasta varios días.

Corrreo Electrónico y Resolución de Nombres

Normalmente los usuarios de correo electrónico redactan su mensajes usando un cliente de correo y enviándolo a través de un servidor SMTP provisto por su ISP o a través de un sistema de correo vía web (webmail). En cualquier caso, una vez que el mensaje es recibido por el servidor, debe ser entregado al destinatario. Aquí interviene el sistema DNS:

  1. El servidor del emisor solicita al DNS (de acuerdo al mecanismo analizado anteriormente), la entrada MX del dominio del receptor del mensaje. MX significa “mail exchanger“, esto es, el nombre del servidor (o los servidores) encargado de recibir los mensajes destinados a determinado dominio.
  2. El DNS devuelve el FQHN y la dirección IP del mail exchanger.
  3. El servidor del emisor se conecta al puerto 25, mediante TCP, del servidor del destinatario y entrega el mensaje según el protocolo SMTP.
  4. El proceso podrá continuar si el servidor receptor del mensaje no es el último de la cadena. Existen servidores que actúan como “puertas de enlace” o “gateways” de correo electrónico, y que se encargan de recibir los mensajes de determinados dominios para luego enviarlos a otros servidores.
Tipos de Registro en un Servidor de Nombres

Un servidor de nombres puede almacenar distinta información. Para ello, en cada zona de autoridad dispondrá de entradas de distinto tipo. Entre los más importantes se encuentran:

  • A (Address): Este registro se utiliza para traducir nombres de hosts del dominio en cuestión a direcciones IP.
  • CNAME (Canonical Name): El nombre canónico es un alias para un host determinado. (No define una dirección IP, sino un nuevo nombre.)
  • NS (Name Server): Especifica el servidor (o servidores) de nombres para un dominio.
  • MX (Mail Exchange): Define el servidor encargado de recibir el correo electrónico para el dominio.
  • PTR (Pointer): Especifica un “registro inverso“, a la inversa del registro A, permitiendo la traducción de direcciones IP a nombres.
  • TXT (Text): Permite asociar información adicional a un dominio. Esto se utiliza para otros fines, como el almacenamiento de claves de cifrado, “DomainKeys” o “Sender Policy Framework“.
Blind, "el" Servidor de Nombres

Prácticamente el único software utilizado en los servidores de nombres de Internet es bind (”Berkeley Internet Name Domain“), creado originalmente en la Universidad de California, y actualmente propiedad del Internet Systems Consortium.

Este programa, distribuido bajo una licencia libre, es utilizado en prácticamente todos los sistemas Unix del mundo. Esto ha sido considerado un problema de seguridad, al punto que se ha propuesto la migración de algunos root servers a otro sistema, ya que la aparición de algún problema de seguridad en bind podría implicar la caída de todo el DNS de Internet.

Uso del DNS en una Red Local

Ya en redes de tamaño medio (quizás más de 5 equipos) es conveniente la utilización de DNS. Esto nada tiene que ver con el DNS de Internet (aunque el servidor local puede estar vinculado a este sistema).

Básicamente, es conveniente montar un servidor local de DNS por los siguientes motivos:

  • Agilizar el acceso a Internet: Al tener un servidor de nombres en nuestra propia red local (que acceda al DNS de nuestro proveedor o directamente a los root servers) se agiliza el mecanismo de resolución de nombres, manteniendo en caché los nombres recientemente usados en la red y disminuyendo el tráfico hacia/desde Internet.
  • Simplificar la administración de la red local: Al contar con un DNS propio (ya sea uno o varios servidores de nombres) es posible definir zonas locales (no válidas ni accesibles desde Internet) para asignar nombres a cada uno de los hosts de la LAN. De esta forma es posible, por ejemplo, referirnos a la impresora de red como “hplaser.mired.local” en vez de “192.168.0.2” y a nuestro servidor de correo interno como “smtp.mired.local” en vez de “192.168.0.3“. (Pensemos, por ejemplo, que ocurriría con las configuraciones de las aplicaciones si un día decidimos cambiar el esquema de direcciones IP de nuestra red.)
Problemas del DNS

El principal problema que presenta el DNS es que, al estar basado en UDP (protocolo de transporte que no garantiza la recepción de la información enviada), tanto las consultas como las respuestas pueden “perderse” (por ejemplo, a causa de congestionamiento en algún enlace de la red). Es común apreciar cómo, en el caso de servidores y redes no muy bien configuradas, la resolución de nombres se resiente sensiblemente ante cualquier anomalía (saturación de tráfico o del servidor de nombres local).

Otro inconveniente, que ya hemos hecho notar, es la lentitud de la propagación de las modificaciones en el sistema, producto de la propia arquitectura del mismo.

Pero quizás el mayor problema no sea inherente al sistema mismo, sino a la pésima configuración de los servidores de muchos ISP. Fibertel, el proveedor que utilizo, es un notable ejemplo de esta falencia. Una buena solución a esta situación es ejecutar un servidor de nombres en alguna PC de la red local, de forma tal que se comunique directamente con los root servers (evitando de esta forma pasar a través de los servidores de nombres de nuestro proveedor).

Herramientas Para Aprender Más

En sistemas Unix el comando dig (ver “man dig“) permite realizar requerimientos “a mano” para poder investigar un poco más sobre el funcionamiento del DNS y, cómo no, también para detectar y solucionar problemas en la red.

Los usuarios de sistemas Windows disponen del comando nslookup (aunque no tan potente como dig), para el mismo propósito.

Lectura Adicional
  • La página de Wikipedia sobre DNS contiene bastante información y buenos enlaces sobre este tema.
  • El “DNS Cómo” explica la configuración de bind en GNU/Linux.
  • El RFC 1591 explica detalladamente la estructura del DNS.
  • Los RFC 1034 y 1035 (ambos en inglés), describen completamente el DNS.

martes, 16 de septiembre de 2008

Modelo TCP/IP

TCP/IP es junto con OSI una arquitectura de protocolos que ha sido determinante y básica en el desarrollo de los estándares de comunicación. Es la arquitectura más adoptada para la interconexión de sistemas.Al contrario de lo que ocurre con OSI, el modelo TCP/IP es software, es decir, es un modelo para ser implementado en cualquier tipo de red. Facilita el intercambio de información independientemente de la tecnología y el tipo de subredes a atravesar, proporcionando una comunicación transparente a través de sistemas heterogéneos. Por todo esto, TCP/IP no define una capa física ni de enlace. Este protocolo define solamente tres capas que funcionarán en los niveles superiores a las capas físiscas y de enlace para hacerlo así un modelo independiente del hardware en el que se implemente.

Capas o niveles del TCP/IP

Para conseguir un intercambio fiable de datos entre dos computadoras, se deben llevar a cabo muchos procedimientos separados.
El resultado es que el software de comunicaciones es complejo. Con un modelo en capas o niveles resulta más sencillo agrupar funciones relacionadas e implementar el software de comunicaciones modular.
Las capas están jerarquizadas. Cada capa se construye sobre su predecesora. El número de capas y, en cada una de ellas, sus servicios y funciones son variables con cada tipo de red. Sin embargo, en cualquier red, la misión de cada capa es proveer servicios a las capas superiores haciéndoles transparentes el modo en que esos servicios se llevan a cabo. De esta manera, cada capa debe ocuparse exclusivamente de su nivel inmediatamente inferior, a quien solicita servicios, y del nivel inmediatamente superior, a quien devuelve resultados.


COMPARACION CAPA MODELO TCP/IP Y MODELO OSI



Capas del modelo TCP/IP

Capa 4 - Aplicación, asimilable a las capas 5 (sesión), 6 (presentación) y 7 (aplicación) del modelo OSI.
Capa 3 - Transporte, asimilable a la capa 4 (transporte) del modelo OSI.
Capa 2 - Internet, asimilable a la capa 3 (red) del modelo OSI.
Capa 1 - Acceso al Medio, asimilable a la capa 1 (física) y 2 (enlace de datos) del modelo OSI.




miércoles, 10 de septiembre de 2008

Modelo OSI

MODELO OSI




El modelo de referencia de Interconexión de Sistemas Abiertos lanzado en 1984 fue el modelo de red descriptivo creado por ISO; esto es, un marco de referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones.


Capas del Modelo OSI

Esta compuesta por siete capas, los cuales son:

Capa 1 o Capa Física
Capa 2 o Capa de enlace de datos
Capa 3 o Capa de red
Capa 4 o Capa de transporte
Capa 5 o Capa de sesión
Capa 6 o Capa de presentación
Capa 7 o Capa de aplicación

Capa 1 o Capa Física

La Capa Física del modelo de referencia OSI es la que se encarga de las conexiones físicas de la computadora hacia la red, tanto en lo que se refiere al medio; características del medio y la forma en la que se transmite la información .
Es la encargada de transmitir los bits de información a través del medio utilizado para la transmisión. Se ocupa de las propiedades físicas y características eléctricas de los diversos componentes; de la velocidad de transmisión, si ésta es uni o bidireccional. También de aspectos mecánicos de las conexiones y terminales, incluyendo la interpretación de las señales eléctricas/electromagnéticas.
Se encarga de transformar una trama de datos proveniente del nivel de enlace en una señal adecuada al medio físico utilizado en la transmisión. Estos impulsos pueden ser eléctricos (transmisión por cable) o electromagnéticos. Estos últimos, dependiendo de la frecuencia / longitud de onda de la señal pueden ser ópticos, de micro-ondas o de radio. Cuando actúa en modo recepción el trabajo es inverso; se encarga de transformar la señal transmitida en tramas de datos binarios que serán entregados al nivel de enlace.
Sus principales funciones se pueden resumir como:
* Definir el medio o medios físicos por los que va a viajar la comunicación: cable de pares trenzados, coaxial, guías de onda, aire, fibra óptica.
* Definir las características materiales y eléctricas que se van a usar en la transmisión de los datos por los medios físicos.
* Definir las características funcionales de la interfaz.
* Transmitir el flujo de bits a través del medio.
* Manejar las señales eléctricas/electromagnéticas
* Especificar cables, conectores y componentes de interfaz con el medio de transmisión, polos en un enchufe, etc.
* Garantizar la conexión.

Capa 2 o Capa de enlace de datos

Cualquier medio de transmisión debe ser capaz de proporcionar una transmisión sin errores, es decir, un tránsito de datos fiable a través de un enlace físico. Debe crear y reconocer los límites de las tramas, así como resolver los problemas derivados del deterioro, pérdida o duplicidad de las tramas. También puede incluir algún mecanismo de regulación del tráfico que evite la saturación de un receptor que sea más lento que el emisor.
La capa de enlace de datos se ocupa del direccionamiento físico, de la topología de la red, del acceso a la red, de la notificación de errores, de la distribución ordenada de tramas y del control del flujo.
Se hace un direccionamiento de los datos en la red ya sea en la distribución adecuada desde un emisor a un receptor, la notificación de errores, de la topología de la red de cualquier tipo. La tarjeta NIC (Network Interface Card, Tarjeta de Interfaz de Red en español o Tarjeta de Red) que se encarga que tengamos conexión, posee una dirección MAC y la LLC.
Los Switches realizan su función en esta capa.
La PDU de la capa 2 es la trama.

Capa 3 o Capa de red

El cometido de la capa de red es hacer que los datos lleguen desde el origen al destino, aún cuando ambos no estén conectados directamente. Los dispositivos que facilitan tal tarea se denominan en castellano encaminadores, aunque es más frecuente encontrar el nombre inglés routers y, en ocasiones enrutadores.
Adicionalmente la capa de red lleva un control de la congestión de red, que es el fenómeno que se produce cuando una saturación de un nodo tira abajo toda la red (similar a un atasco en un cruce importante en una ciudad grande). La PDU de la capa 3 es el paquete.
Los routers trabajan en esta capa, aunque pueden actuar como switch de nivel 2 en determinados casos, dependiendo de la función que se le asigne. Los firewalls actuan sobre esta capa principalmente, para descartar direcciones de maquinas.
A este nivel se determina la ruta de los datos y su receptor final IP

Capa 4 o Capa de transporte

Su función básica es aceptar los datos enviados por las capas superiores, dividirlos en pequeñas partes si es necesario, y pasarlos a la capa de red. En el caso del modelo OSI, también se asegura que lleguen correctamente al otro lado de la comunicación. Otra característica a destacar es que debe aislar a las capas superiores de las distintas posibles implementaciones de tecnologías de red en las capas inferiores, lo que la convierte en el corazón de la comunicación. En esta capa se proveen servicios de conexión para la capa de sesión que serán utilizados finalmente por los usuarios de la red al enviar y recibir paquetes. Estos servicios estarán asociados al tipo de comunicación empleada, la cual puede ser diferente según el requerimiento que se le haga a la capa de transporte. Por ejemplo, la comunicación puede ser manejada para que los paquetes sean entregados en el orden exacto en que se enviaron, asegurando una comunicación punto a punto libre de errores, o sin tener en cuenta el orden de envío. Una de las dos modalidades debe establecerse antes de comenzar la comunicación para que una sesión determinada envíe paquetes, y ése será el tipo de servicio brindado por la capa de transporte hasta que la sesión finalice. De la explicación del funcionamiento de esta capa se desprende que no está tan encadenada a capas inferiores como en el caso de las capas 1 a 3, sino que el servicio a prestar se determina cada vez que una sesión desea establecer una comunicación. Todo el servicio que presta la capa está gestionado por las cabeceras que agrega al paquete a transmitir.
En resumen, podemos definir a la capa de transporte como:
Capa encargada de efectuar el transporte de los datos de la máquina origen a la destino, independizándolo del tipo de red física que se esté utilizando. La PDU de la capa 4 se llama Segmentos.

Capa 5 o Capa de sesión

Esta capa establece, gestiona y finaliza las conexiones entre usuarios finales. Ofrece varios servicios que son cruciales para la comunicación, como son:
* Control de la sesión a establecer entre el emisor y el receptor.
* Control de la concurrencia.
* Mantener puntos de verificación, que sirven para que, ante una interrupción de transmisión por cualquier causa, la misma se pueda reanudar desde el último punto de verificación en lugar de repetirla desde el principio.
Por lo tanto, el servicio provisto por esta capa es la capacidad de asegurar que, dada una sesión establecida entre dos máquinas, la misma se pueda efectuar para las operaciones definidas de principio a fin, reanudándolas en caso de interrupción. En muchos casos, los servicios de la capa de sesión son parcial o totalmente prescindibles.

Capa 6 o Capa de presentación

El objetivo de la capa de presentación es encargarse de la representación de la información, de manera que aunque distintos equipos puedan tener diferentes representaciones internas de caracteres, números, sonido o imágenes, los datos lleguen de manera reconocible.
Esta capa es la primera en trabajar más el contenido de la comunicación que en como se establece la misma. En ella se tratan aspectos tales como la semántica y la sintaxis de los datos transmitidos, ya que distintas computadoras pueden tener diferentes formas de manejarlas.
Por lo tanto, podemos resumir definiendo a esta capa como la encargada de manejar las estructuras de datos abstractas y realizar las conversiones de representación de datos necesarias para la correcta interpretación de los mismos.
Esta capa también permite cifrar los datos y comprimirlos. En pocas palabras es un traductor.

Capa 7 o Capa de aplicación

Ofrece a las aplicaciones la posibilidad de acceder a los servicios de las demás capas y define los protocolos que utilizan las aplicaciones para intercambiar datos, como correo electrónico, gestores de bases de datos y servidor de ficheros. Hay tantos protocolos como aplicaciones distintas y puesto que continuamente se desarrollan nuevas aplicaciones el número de protocolos crece sin parar.