Actividad No.

11
Documentacin de protocolos.

Dns:
Sistema de Nombres de Dominio (DNS, por Domain Name System).
El DNS se utiliza principalmente para la resolucin de nombres, esto es, decidir qu direccin IP
pertenece a determinado nombre completo de host.

Usos del DNS

El DNS se utiliza para distintos propsitos. Los ms comunes son:

Resolucin de nombres: Dado el nombre completo de un host (por ejemplo

blog.smaldone.com.ar), obtener su direccin IP (en este caso, 208.97.175.41).
Resolucin inversa de direcciones: Es el mecanismo inverso al anterior. Consiste
en, dada una direccin IP, obtener el nombre asociado a la misma.
Resolucin de servidores de correo: Dado un nombre de dominio (por ejemplo
gmail.com) obtener el servidor a travs del cual debe realizarse la entrega del correo
electrnico (en este caso, gmail-smtp-in.l.google.com).

Por tratarse de un sistema muy flexible, es utilizado tambin para muchas otras funciones,
tales como la obtencin de claves pblicas de cifrado asimtrico y la validacin de envo de
e-mails (a travs de mecanismos como SPF).

Terminologa bsica
Antes de proseguir, es necesario introducir algunos trminos bsicos para evitar
confusiones y ambigedades. Otros trminos ms complejos sern tratados ms adelante.

Host Name: El nombre de un host es una sola palabra (formada por letras,
nmeros 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 sucesin 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 travs 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, algn subdominio de la zona sobre la que l tiene autoridad). Un
subdominio puede verse como una especializacin de un dominio de nivel anterior. Por
ejemplo, smaldone.com.ar es un subdominio de com.ar, que a su vez lo es del TLD
ar.
El siguiente diagrama ilustra esto a travs de un ejemplo:

Los servidores con autoridad sobre los TLD son los llamados root servers (o servidores
raz) del sistema. Estos son fijos, ya que rara vez cambian, siendo actualmente 13.
Tomemos como ejemplo el dominio com.ar. Este dominio pertenece al TLD ar.

El proceso de resolucin de nombres

Cuando una aplicacin (cliente) necesita resolver un FQHN enva 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 resolucin del nombre:
1. El servidor de nombres inicial consulta a uno de los servidores raz (cuya direccin
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 subzona delegada.
5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestin, 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.

Mecanismos de cach
Cada vez que un servidor de nombres enva 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 informacin
previamente obtenida en vez de realizar un nuevo requerimiento.
Esta es la razn por la cual los cambios realizados en el DNS no se propagan
instantneamente a travs del sistema. Dependiendo de la naturaleza de los mismos (y de la
configuracin de cada servidor), la propagacin puede tardar desde algunos minutos hasta
varios das.

Tipos de registro en un servidor de nombres

Un servidor de nombres puede almacenar distinta informacin. Para ello, en cada zona de
autoridad dispondr de entradas de distinto tipo. Entre los ms importantes se encuentran:

A (Address): Este registro se utiliza para traducir nombres de hosts del dominio en
cuestin a direcciones IP.
CNAME (Canonical Name): El nombre cannico es un alias para un host
determinado. (No define una direccin 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 electrnico
para el dominio.
PTR (Pointer): Especifica un registro inverso, a la inversa del registro A,
permitiendo la traduccin de direcciones IP a nombres.
TXT (Text): Permite asociar informacin adicional a un dominio. Esto se utiliza
para otros fines, como el almacenamiento de claves de cifrado, DomainKeys o
Sender Policy Framework.

Bind, el servidor de nombres

Prcticamente 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 prcticamente todos los
sistemas Unix del mundo. Esto ha sido considerado un problema de seguridad, al punto que
se ha propuesto la migracin de algunos root servers a otro sistema, ya que la aparicin de
algn problema de seguridad en bind podra implicar la cada de todo el DNS de Internet.

Uso del DNS en una red local

Ya en redes de tamao medio (quizs ms de 5 equipos) es conveniente la utilizacin de
DNS. Esto nada tiene que ver con el DNS de Internet (aunque el servidor local puede estar
vinculado a este sistema).
Bsicamente, 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 resolucin de nombres, manteniendo en cach
los nombres recientemente usados en la red y disminuyendo el trfico hacia/desde
Internet.
Simplificar la administracin de la red local: Al contar con un DNS propio (ya
sea uno o varios servidores de nombres) es posible definir zonas locales (no vlidas
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 ocurrira con las configuraciones de las aplicaciones si un da 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 recepcin de la informacin enviada), tanto las consultas
como las respuestas pueden perderse (por ejemplo, a causa de congestionamiento en
algn enlace de la red). Es comn apreciar cmo, en el caso de servidores y redes no muy
bien configuradas, la resolucin de nombres se resiente sensiblemente ante cualquier
anomala (saturacin de trfico o del servidor de nombres local).
Otro inconveniente, que ya hemos hecho notar, es la lentitud de la propagacin de las
modificaciones en el sistema, producto de la propia arquitectura del mismo.

Pero quizs el mayor problema no sea inherente al sistema mismo, sino a la psima
configuracin de los servidores de muchos ISP. Fibertel, el proveedor que utilizo, es un
notable ejemplo de esta falencia. Una buena solucin a esta situacin 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 travs de los servidores
de nombres de nuestro proveedor).

Ftp:
FTP (File Transfer Protocol) es un servicio de la capa de aplicacin que nos permite descargarnos
archivos y subirlos a un servidor remoto.

La implementacin del FTP se remonta a 1971 cuando se desarroll un sistema de

transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnolgico de
Massachusetts (MIT, Massachusetts Institute of Technology). Desde entonces, diversos
documentos de RFC (peticin de comentarios) han mejorado el protocolo bsico, pero las
innovaciones ms importantes se llevaron a cabo en julio de 1973.
Actualmente, el protocolo FTP est definido por RFC 959 (Protocolo de transferencia de
archivos (FTP) - Especificaciones).

La funcin del protocolo FTP

El protocolo FTP define la manera en que los datos deben ser transferidos a travs de una
red TCP/IP.
El objetivo del protocolo FTP es:

permitir que equipos remotos puedan compartir archivos

permitir la independencia entre los sistemas de archivo del equipo del cliente y del equipo
del servidor
permitir una transferencia de datos eficaz

El modelo FTP
El protocolo FTP est incluido dentro del modelo cliente-servidor, es decir, un equipo enva
rdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor).
Durante una conexin FTP, se encuentran abiertos dos canales de transmisin:

Un canal de comandos (canal de control)

Un canal de datos

Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la
administracin de estos dos tipos de informacin:

DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la

conexin y de administrar el canal de datos. El DTP del lado del servidor se

denomina SERVIDOR DE DTP y el DTP del lado del cliente se denomina
USUARIO DE DTP.
PI (Intrprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser
controlado mediante los comandos recibidos a travs del canal de control. Esto es
diferente en el cliente y el servidor:
o

El SERVIDOR PI es responsable de escuchar los comandos que provienen de un

USUARIO PI a travs del canal de control en un puerto de datos, de establecer la
conexin para el canal de control, de recibir los comandos FTP del USUARIO PI a
travs de ste, de responderles y de ejecutar el SERVIDOR DE DTP.
El USUARIO PI es responsable de establecer la conexin con el servidor FTP, de
enviar los comandos FTP, de recibir respuestas del SERVIDOR PI y de controlar al
USUARIO DE DTP, si fuera necesario.

Cuando un cliente FTP se conecta con un servidor FTP, el USUARIO PI inicia la conexin
con el servidor de acuerdo con el protocolo Telnet. El cliente enva comandos FTP al
servidor, el servidor los interpreta, ejecuta su DTP y despus enva una respuesta estndar.
Una vez que se establece la conexin, el servidor PI proporciona el puerto por el cual se
enviarn los datos al Cliente DTP. El cliente DTP escucha el puerto especificado para los
datos
provenientes
del
servidor.
Es importante tener en cuenta que, debido a que los puertos de control y de datos son
canales separados, es posible enviar comandos desde un equipo y recibir datos en otro.
Entonces, por ejemplo, es posible transferir datos entre dos servidores FTP mediante el
paso indirecto por un cliente para enviar instrucciones de control y la transferencia de
informacin entre dos procesos del servidor conectados en el puerto correcto.

En esta configuracin, el protocolo indica que los canales de control deben permanecer
abiertos durante la transferencia de datos. De este modo, un servidor puede detener una
transmisin si el canal de control es interrumpido durante la transmisin.

Los comandos FTP

Toda comunicacin que se realice en el canal de control sigue las recomendaciones del
protocolo Telnet. Por lo tanto, los comandos FTP son cadenas de caracteres Telnet (en
cdigo NVT-ASCII) que finalizan con el cdigo de final de lnea Telnet (es decir, la
secuencia <CR>+<LF>, Retorno de carro seguido del carcter Avance de lnea indicado
como
<CRLF>).
Si el comando FTP tiene un parmetro, ste se separa del comando con un espacio (<SP>).
Los comandos FTP hacen posible especificar:

El puerto utilizado
El mtodo de transferencia de datos
La estructura de datos
La naturaleza de la accin que se va a realizar (Recuperar, Enumerar, Almacenar, etc.)

Existen tres tipos de comandos FTP diferentes:

Comandos de control de acceso

Comandos de parmetros de transferencia
Comandos de servicio FTP

Dhcp:
El objetivo del servicio DHCP es automatizar la configuracin IP de un grupo de mquinas
Cuando se disponen mquinas en una red con protocolo TCP/IP, como todos sabemos, es
necesario configurarle parmetros adecuados, obligatoriamente Direccin IP y Mscara de
Subred, y seguramente algunos ms como son la Puerta de Enlace (Default Gateway),
direccin de servidores DNS y/o WINS, sufijo de dominio, etc.
Lo anterior lo podemos hacer manualmente mquina por mquina, si son pocas puede ser
una opcin, pero a medida que aumenta la cantidad de equipos, o que cambien parmetros,
o inclusive si disponemos de ms de una red, el tema se va tornando ms complicado, pues
adems de tener que cambiar la configuracin en cada mquina debemos llevar el control
de que no se repitan las direcciones IP, o marcarlas cundo se dejan de usar
Justamente para evitar ese trabajo, es que usamos el servicio DHCP
Aunque este servicio es habitual que funcione en Routers (Enrutadores), en este ejemplo
desarrollar el tema sobre el servicio DHCP en un sistema servidor. El funcionamiento es el
mismo
El servicio DHCP se debe instalar sobre un sistema operativo de tipo servidor, que tenga
configurados parmetros de IP en forma manual, no automtica. Esto es importante porque
un Servidor DHCP no puede ser al mismo tiempo Cliente DHCP
Una vez instalado el servicio hay que configurar un mbito, o sea un rango de direcciones
IP que alquilar temporalmente a los clientes que lo soliciten. Este mismo mbito lo
podemos configurar para que conjuntamente con Direccin IP y Mscara de Subred (los
dos obligatorios) adems configure otros parmetros adicionales que necesitemos, como ser
Puerte de Enlace (Default Gateway), servidores DNS, etc.
Una vez que tenemos el mbito creado y configurado ya tenemos el servicio disponible
para ser usado
Y cmo acceden y configuran los clientes para usar este servicio? es lo ms fcil que hay,
ya que por omisin las mquinas Windows quedan en su configuracin IP para obtener una
direccin IP y DNS en forma automtica. Eso es todo

Una muy breve descripcin de los diferentes trficos de red para poder comprender lo que
sigue
En una red TCP/IPv4 existe tres tipos de trfico:

Unicast: trfico de uno a uno

Broadcast: trfico de uno a todos
Multicast: trfico de uno a un grupo determinado, no todos

Aclarado lo anterior comencemos con el tema que nos ocupa

Cuando configuramos a una mquina para que obtenga configuracin IPv4
automticamente, sta incializa una versin reducida del protocolo TCP/IPv4 la cual
permite enviar trfico desde la direccin IP 0.0.0.0 (undefined = no definida) hacia
255.255.255.255 (la direccin IPv4 de Broadcast); adems le permite recibir trfico de
Broadcast (255.255.255.255)
Entonces el primer paso que debe hacer el cliente es averiguar si hay algn servidor DHCP
que le pueda asignar su configuracin. Para esto enva un Broadcast llamado DHCP
Discover, usando como direccin de origen 0.0.0.0 y como destino 255.255.255.255
Todos los servidores DHCP, porque en algunas circunstancias podra haber ms de uno,
que escuchen este pedido, y que dispongan de una direccin IPv4 libre y vlida como para
ofrecer lo harn. Elegirn una direccin IP de su mbito, la marcarn como ofrecida, y se la
harn llegar al cliente a traves de un Broadcast llamado DHCP Offer usando como
direccin de origen la direccin del servidor DHCP, y como origen 255.255.255.255 que es
lo nico que puede recibir el cliente
Si el cliente recibiera ms de un ofrecimiento de DHCP, aceptar el primero que reciba, y
este es uno de los motivos por los que no hay balance de carga por parte del cliente entre
varios servidores DHCP
Luego que el cliente acepta el ofrecimiento, se lo har saber a los servidores DHCP que le
han ofrecido configuracin enviando un Broadcast llamado DHCP Request que incluye
la direccin IP del server del cual acept el ofrecimiento. Todava sigue usando como
origen 0.0.0.0 ya que an no ha finalizado el proceso
Los servidores DHCP que reciban este trfico del cliente y que no les fue aceptado el
ofrecimiento, vuelven a marcar la direccin ofrecida como libre; pero en cambio el servidor
al cual se le acept el procedimiento (indicado en el DHCP Request) marcar la direccin
como ocupada, y se la confirmar al cliente con un Broadcast llamado DHCP Ack
Recin cuando el cliente reciba este cuarto mensaje (DHCP Ack) terminar de incializar
TCP/IPv4 y comenzar a usar los parmetros asignados, incluyendo la direccin IP

Resumiendo, hay cuatro mensajes de tipo Broadcast durante la obtencin de una direccin
IPv4, a travs de DHCP

DHCP Discover
DHCP Offer
DHCP Request
DHCP Ack

(Broadcast de cliente a servidores)

(Broadcast de servidores a cliente)
(Broadcast de cliente a servidores)
(Broadcast de servidor DHCP a cliente)

Para completar la informacin, la configuracin que ofrece el servidor DHCP a los clientes
tiene un perodo de validez que el cliente deber renovar peridicamente, por eso se habla
de una alquiler o lease
Si la mquina cliente quedara prendida la renovacin del lease se har llegado el 50% del
tiempo
de
asinacin.
Si la mquina cliente se apagara o reiniciar, se renovar en cada arranque
Hay una diferencia en el trfico de acuerdo al primer o el segundo caso. En el primero,
como el cliente tiene direccin IP y conoce que an tiene tiempo el trfico es dirigido entre
cliente y servidor, y es con los dos ltimos de los cuatro mencionados anteriormente, esto
es DHCP Request y DHCP Ack
En el segundo caso, tambin son los mismos mensajes, pero en este caso el trfico es por
Broadcast, esto tiene por finalidad conocer si el cliente fue cambiado de red, ya que en ese
caso no llegara el Broadcast al servidor y no podra renovar el lease, lo cual es lgico
pues al cambiar de red necesita otra configuracin diferente de IP