8 EL NIVEL DE APLICACIÓN EN INTERNET

8 EL NIVEL DE APLICACIÓN EN INTERNET
8.1 Servidor de Nombres (DNS domain name server)
8.1.1 Introducción
8.1.2 DNS, el Sistema de Nombres de Dominio
8.1.3 Nombres de dominio, delegación de autoridad y registro de recursos
Nombres de Dominio
Delegación de la Autoridad
Nombres absolutos y relativos
Registro de Recursos
8.1.4 Zonas de autoridad
8.1.5 El proceso de resolución de nombres de dominio
8.1.6 Preguntas inversas
8.1.7 Formato de los mensajes del DNS.
8.1.8 Ejemplo de consulta de direcciones: comandos nslookup (host o dig)
Traducción de dirección a nombre.
Servidores de nombres de dominios locales y globales.
8.1.9 Conexión a Internet y diseño de la base de datos de un servidor de nombres.
8.1.10 Configuración de un cliente y un servidor de DNS estático.
Configuración de un cliente de DNS.
Configuración de un servidor primario de DNS.
Configuración de un servidor secundario de DNS.
8.1.11 RFCs
8.2 Correo electrónico (Simple Mail Transfer Protocol: SMTP)
8.2.1 Introducción
8.2.2 Arquitectura de los sistemas de correo electrónico.
Los agentes de transferencia de mensajes: SMTP y ESMTP
Los agentes de usuario.
Formato de los buzones: mailbox V7
Seguridad en el correo
8.2.3 Formato de los mensajes.
RFC 822.
MIME- Extensiones multipropósito de correo Internet.
8.3 SNMP: Simple Network Management Protocol
8.3.1 Introducción
8.3.2  Estándares de la estructura de la información de administración
8.3.3  El estándar SNMP
8.3.4 El estándar MIB-2
MIB-2
Leyendo un MIB
Determinando el identificador de un objeto
Atributos de objetos
Tipo de datos comunes
Areas funcionales del MIB-2
8.3.5 Mensajes SNMP
EJEMPLO de CONSULTA SNMP: snmpget(): cálculo de utilización de una interface de un enlace serie
8.3.6 SNMPv2
8.3.7 RMON y monitorización remota

8.1 Servidor de Nombres (DNS domain name server)

8.1.1 Introducción

Para poder comunicarse con un ordenador necesitamos saber su dirección IP. Dado que las direcciones IP son difíciles de memorizar o recordar necesitamos asignar a las direcciones nombres significativos, por ejemplo, para poder ver la página web de la universidad de Valencia, www.uv.es,  necesitaríamos saber la dirección IP del servidor web de esta, que en este caso es 147.156.1.46, lo mismo para cualquier otra página web que se nos ocurra, www.yahoo.com, www.sun.com, robotica.uv.es, etc.  Este método es inviable y engorroso.

En los comienzos de Internet se utilizaba una única tabla centralizada de traducción de nombres a direcciones. En los 70 el ARPANET estaba formada por unos cientos de máquinas y un sólo archivo, HOSTS.TXT,(que se conserva como reminiscencia en la mayoría de sistemas operativos actuales, permitiendo trabajar a una máquina en red sin un servidor DNS) que contenía toda la información que se necesitaba sobre esas máquinas. El centro de información de red del Departamento de defensa disponía de la versión maestra de la tabla y otros sistemas realizaban una copia regularmente.

Con el paso del tiempo y cuando Internet, con los protocolos TCP/IP “explotó”, este método, como podemos imaginar, presento serios inconvenientes, entre los que podemos destacar los siguientes:
	
-	El tráfico y la carga de red para la máquina que contenía las tablas que hacía posible el mapeo era desbordante.
-	La consistencia del archivo era muy difícil de mantener, cuando el HOST.TXT  llegaba a una maquina muy lejana era ya obsoleto.
-	No se podía garantizar la no duplicidad de nombres, dado que mantener una administración central en una red Internacional era algo muy complicado.
-	El método era claramente no Escalable.

Conclusión, el método se convirtió en obsoleto y muy ineficiente a medida que aumentaron el número de máquinas. Es entonces cuando surgió un nuevo sistema de resolución de nombres, DNS (Domain Name System), que solucionó los problemas anteriores.

8.1.2 DNS, el Sistema de Nombres de Dominio

El Sistema de Nombres de Dominio básicamente es un esquema que permite asignar nombres significativos de alto nivel  a grandes conjuntos de máquinas y direcciones IP. El esquema es jerárquico y basado en dominio utilizando una Base de Datos Distribuida para implementarlo. Se utiliza un mecanismo Cliente/Servidor, donde unos programas llamados servidores de nombres contienen información acerca de un segmento de la base de datos y la ponen a disposición de los clientes, llamados resolvers.

Los llamados resolvers son rutinas de biblioteca que crean preguntas y las envían en forma de paquete UDP a un servidor DNS local. Este devuelve al resolver la dirección IP correspondiente al nombre solicitado en la pregunta. El motivo de utilizar UDP como capa de transporte, se justifica porque estas aplicaciones se basan en consulta y contestación, de forma atomatizada, sin crear ningún tipo de flujo ni conexión. Además, como es realizada a nivel local, la probabilidad de error es muy baja.

El servicio DNS los podemos situar en la arquitectura de TCP/IP como protocolo de aplicación, tanto sobre UDP como TCP en el puerto 53 de la capa de transporte. Véase la siguiente figura:

SNMP

NFS

FTP

ASN1

XDR

DNS

Telnet

TFTP

RPC

RPC

SMTP

HTTP

UDP

TCP	

IP

PROTOCOLOS de ACCESO al MEDIO

					

Figura 8.1: Modelo TCP/IP y la aplicación DNS

Gracias a la estructura y funcionamiento del DNS se eliminaron los problemas inherentes al sistema de archivo plano. A continuación describimos brevemente el porqué:

-	Carga de la red y de los hosts: este problema ya no existe debido a que la información esta distribuida por toda la red, al tratarse de una base de datos distribuida.
-	Duplicidad de Nombres: el problema se elimina debido a la existencia de dominios controlados por un único administrador. Puede haber nombres iguales pero en dominios diferentes. 
-	Consistencia de la Información: ahora la información que esta distribuida es actualizada automáticamente sin intervención de ningún administrador.

8.1.3 Nombres de dominio, delegación de autoridad y registro de recursos

El Sistema de Nombres de Dominio lo podemos desglosar en dos conceptos independientes:

•	el primero, especifica la sintaxis del nombre y las reglas para delegar la autoridad respecto al nombre
•	el segundo especifica la implementación en ordenadores de la base de datos distribuida que transforma de una manera eficiente los nombres a direcciones IP. 

Como veremos, se puede considerar el DNS como una forma de inventariar todos los recursos de una red, donde los recursos puede ser desde máquinas, servidores de correo, direcciones postales, etc información propia de la administración de una red.

Nombres de Dominio

Como dijimos anteriormente el DNS se basa en un esquema jerárquico de nombres denominado nombre de dominio. Un nombre de dominio consiste en una secuencia de etiquetas separadas por un punto. Por ejemplo, robotica.uv.es, contiene tres etiquetas, el dominio de nivel inferior es robotica.uv.es, el segundo nivel de dominio es uv.es, y el nivel superior es es. Como jerarquía que es podemos apreciar que el dominio de nivel local corresponde con la primera etiqueta, y el de nivel superior la última etiqueta.

Como veremos posteriormente, en la practica un dominio es un índice en la base de datos de DNS. Un dominio puede ser una máquina o puede ser un nodo del cual pueden partir otros dominios (o ambas cosas a la vez).

En Internet se ha decidido particionar el nivel superior en dos tipos de dominios, los geográficos y los genéricos. Con los primeros se pretende dividir los recursos a direccionar por país (por ej, uv.es), también son conocidos como ISO3166 . Con los segundos se pretende un división en función del tipo de organización. A continuación podemos ver una tabla con algunos de los dominios genéricos más utilizados, que corresponde a la tabla TLD (Top Domain Level):
	
Nombre de Dominio	Significado	
COM	Organizaciones comercianles, Microsoft.com, ibm.com	
EDU	Universidades, Instituciones academicas,...	
GOV	Instituciones Gubernamentales	
MIL	Organizaciones militares	
ORG	Organizaciones no comerciales	
NET	Grupos relacionados con la Red	
INT 	Organizaciones Internacionales	
Tabla 8.1: Dominio genéricos. Tabla Top Domain Level (TLD)

Todos los dominios en Internet pueden representarse mediante un árbol. Las hojas del árbol serían los dominios que ya no contiene más dominios (subdominios, aunque este término no esta definido es bastante utilizado). Entonces, cada dominio en Internet estaría definido por la trayectoria hacia arriba desde él a la raíz (esta está vacía). El árbol tendría la siguiente forma: 

                       GENÉRICOS                                   		Geográficos (por paises)

				            ROOT (vacío)					

		

edu	com	mil	gov	net	org	...	es	it	fr	us	....

ibm   cisco    oracle      nasa          ieee   acm		uv

tools		soft				       robotica	

				        oracle	cisco	lab1	lab2	lab3

					rut1 rut2 rut3              tools
Figura 8.2: árbol de la jerarquía de nombres de Internet

Como puede verse en el árbol al ser jerárquico no hay conflicto cuando dos nombres son iguales, mientras pertenezcan a dominios distintos. En la figura 8.2, por ejemplo, esto se da con oracle.com y oracle.robotica.uv.es .

Los nombres pueden ser texto ASCII de hasta 63 caracteres de longitud, mientras que los nombres de trayectoria completa (desde la hoja hasta la raíz) no debe sobrepasar los 255 caracteres. 

Delegación de la Autoridad

La organización que posee un Nombre de Dominio, como por e.j. uv.es, es responsable del funcionamiento y mantenimiento de los servidores de nombres que traducen sus propios nombres a direcciones. Se crea entonces un administrador local quien bajo su responsabilidad introduce altas, bajas y cambios de forma rápida y precisa. E incluso puede delegar parte de los dominios que caen bajo su responsabilidad en otro administrador. 

Para ver más claramente la relación entre la jerarquía de nombres y la delegación de la autoridad para los nombres veamos el siguiente ejemplo (véase la figura 8.2): una máquina del Instituto de Robótica de la Universidad de Valencia tiene el nombre de dominio oficial oracle.robotica.uv.es . El nombre de la máquina fue registrado por el administrador local de la red del mencionado Instituto. El Administrador de esta red local había obtenido previamente autorización para la administración del subdominio robotica.uv.es de una Autoridad de la red Universitaria, es decir, del Administrador de la red uv.es.  Este a su vez había obtenido permiso de la Autoridad que Administra el dominio geográfico .es . Quién a su vez había obtenido el permiso para administrar el dominio superior geográfico de la Autoridad de Internet. 

Para aclarar más si cabe el concepto de delegación de Autoridad, cuando alguien (Administrador ,Entidad, Grupo,..) recibe la responsabilidad de Administrar un dominio, a partir de ese dominio es él, el único responsable de administrar como mejor crea conveniente todos los subdominios que caen bajo el nodo que él administra. Consecuencia de esto lo podemos ver en el dominio superior us .La autoridad que lo administra a creído conveniente dividirlo en un segundo nivel por estado. De esta forma quién quiera conectarse bajo el dominio de EE.UU, us, deberá hacerlo obligatoriamente bajo un dominio de segundo nivel. Por ejemplo, imaginemos la empresa ComputerUncleTom situada en Virgina  en EE.UU. La empresa desea conectarse a internet bajo el dominio superior us. Ésta no podría hacerlo directamente,  debería conectarse como dominio de segundo nivel, es decir, computeruncletom.va.us

Nombres absolutos y relativos

En la configuración de un servidor DNS como veremos a continuación, el cliente que realiza las consultas al servidor, recibe contestaciones de carácter absoluto. Esto quiere decir que se detalla el nombre completo a partir de la dirección raíz, por ejemplo glup.irobot.uv.es. 

Sin embargo, para configurar un servidor, introducir todo el nombre completo en los registros que veremos a continuación, puede ser un poco tedioso y por eso la utilización de nombres relativos. Los nombres relativos son nombres que completan su nombre en función del dominio del cual están registrados. Por ejemplo, en el dominio uv.es, la máquina con nombre relativo “glup.irobot”, tomará como nombre absoluto “glup.irobot.uv.es”.

Por tanto, el nombre absoluto no requiere de ninguna referencia a un dominio, dado que es un nombre completo. Para indicar que un nombre es absoluto, terminará su nombre con “.”, en caso contrario, al nombre relativo que termina sin “.”se le añadirá la coletilla del dominio.

Esta distinción es importante y hay que tenerla en cuenta al configurar los registros del DNS, dado que si algún registro por descuido es dejado sin “.”, el DNS añadirá su dominio. Por ejemplo, en el caso de tener un registro con valor “glup.uv.es” sin “.”en el valor de un registro, el DNS cuando se le consulte dicho registro devolverá “glup.uv.es.uv.es”.

Registro de Recursos 

Cuando un resolvedor da un nombre al DNS para que este le responda, el nombre dado puede transformarse en más de un aspecto en el sistema de dominio. Es decir, la respuesta no tiene porque se únicamente una dirección IP, sino que pueden ser muchos tipos de recursos, como por ejemplo, una dirección que sólo acepta correo electrónico. Por tanto, cuando el cliente envía al DNS el nombre del objeto o recurso que busca indica el tipo de objeto que busca (también existe la posibilidad de pedir todos los recursos asociados con el nombre). 	

Los datos del DNS se almacenan como una serie de entradas de texto, llamadas Registros de Recursos (RR). Un RR esta formado por cinco tuplas y tiene el siguiente formato:

	[Nombre_dominio]	[TTL]	    [Clase]      Tipo   Dato_Registro(Valor)

Adicionalmente se pueden añadir comentarios en la misma línea incluyendo al principio del comentario ; .

•	El Primer campo, Nombre_dominio, indica el nombre de dominio. Puede haber más de un registro por dominio. Este campo a veces puede omitirse, en ese caso siempre se toma por defecto el último nombre de domino indicado con anterioridad.

•	El campo TTL, se refiere al tiempo de vida, e indica la estabilidad del registro, es decir, cuanto tiempo debe guardarse en caché después de almacenarse.

•	El campo Clase se refiere al tipo de información. Actualmente sólo se utiliza IN, para información de Internet. Este campo si se omite, al igual que el campo Nombre se toma el último valor indicado con anterioridad. A veces, el orden de los campos TTL y Clase pueden intercambiarse, no dando a confusión dado que TTL es numérico.

  El campo Tipo indica el tipo de registro, puede contener algunos de los siguientes valores (los más importantes):

Tipo de Registro	Descripción	
SOA	Inicio de autoridad, Start Of Authority), identifica el dominio o la zona y se fijan una serie de parámetros para esta zona, información utilizada por los DNS secundarios que trabajen bajo esta SOA.	
NS name server	El nombre de dominio se hace corresponder con el nombre de una computadora de confianza para el dominio, es decir, un servidor de nombres con nombre absoluto.	
A address	Dirección IP de un host. Si este tiene varias direcciones IP, multihomed, habrá un registro diferente por cada una de ellas.	
CNAME	Es un alias que se corresponde con el nombre canónico verdadero, con nombre absoluto.	
MX	Se trata de un intercambiador de correo (Mail eXchanger), es decir, un dominio dispuesto a aceptar solo correo electrónico con nombre absoluto.	
TXT 	Texto, es una forma añadir comentarios a la Base de Datos. Por Ej., para dar la dirección posta del dominio miempresa.com .  	
PTR	Apuntador, hace corresponder una dirección IP con el nombre de un sistema. Usado en archivos dirección-nombre. 	
HINFO	Información del Host, tipo y modelo de computadora.	
MINFO	Información de Buzón o lista de correo.	
WKS	Servicios públicos (Well-Known Services). Puede listar los servicios de las aplicaciones disponibles en el ordenador.	

Tabla 8.2: Descripción del campo TIPO en los registros de recursos del DNS

Volviendo a la estructura general del RR el campo valor será un número o texto ascii  dependiendo del tipo de registro.  También decir, que el orden en la tabla de los RR no es significativo.

Ahora presentamos un ejemplo (ficticio) del tipo de información que podríamos encontrar  en la base de datos del dominio de una empresa conectada a Internet, en este caso computeruncletom.va.us :

;Fichero Configuración
;Datos autorizados para computeruncletom.va.us
;
computeruncletom.va.us.	86400	IN	SOA	(1; Serie
						 28800 ;Refrescar cada 8 horas 
3600	;Reintentar cada hora
604800 ;Expirar al cabo 1 semana
86400 ) ;El defecto es un dia
;información de la empresa
computeruncletom.va.us.	86400	IN	TXT	“Empresa de Informatica”
computeruncletom.va.us.	86400	IN	TXT	“Virginia, EE.UU”

;Servidores de correo
computeruncletom.va.us.	86400	IN	MX	1 correo.computeruncletom.va.us.
computeruncletom.va.us.	86400	IN	MX	2 postal.computeruncletom.va.us.

;Nuestros servidores de nombres
computeruncletom.va.us.	86400	IN	NS	mesa.computeruncletom.va.us.
computeruncletom.va.us.	86400	IN	NS	silla.computeruncletom.va.us.

;Direcciones de hosts
correo.computeruncletom.va.us.	86400	IN	A	192.253.253.2
postal.computeruncletom.va.us.	86400	IN	A	192.253.253.3
start.computeruncletom.va.us.		86400	IN    A	192.253.253.4
start.computeruncletom.va.us.		86400	IN    A	192.253.253.5
start.computeruncletom.va.us.		86400	IN   HINFO  Linuix SuSE 7.2
mesa.computeruncletom.va.us.	      86400 IN    A     192.253.253.6
silla.computeruncletom.va.us.	      86400 IN    A     192.253.253.7

;Alias
www.computeruncletom.va.us.	86400	IN CNAME start.computeruncletom.va.us.
ftp.computeruncletom.va.us.  86400 IN CNAME start.computeruncletom.va.us.
…					…	  …	…          …
…					…       …   …          …			

A continuación describimos el significado de cada línea (omitimos la líneas que son comentarios, ;…) :

- En la primera línea damos información del dominio que estamos administrando. 
- En la línea siguiente damos información textual de nuestro dominio,  en este caso a que se dedica la empresa y donde se localiza.
- En la cuarta y quinta línea estamos facilitando nuestros servidores de correo, es decir, máquinas que recibirán todo el correo dirigido a quiensea@computeruncletom.va.us Primero se intentará con la máquina de nombre correo y en caso de que esta fallará se intentaría con postal. 
- Las líneas seis y siete contienen información de nuestros servidores de nombres
-	A continuación indicamos las direcciones IP de nuestras máquinas. En esta sección véase que damos información del sistema operativo de una nuestra máquinas, start, que además es mutihomed.
-	 Por último, indicamos los alias, en este caso www.computeruncletom.va.us y ftp.computeruncletom.va.us. Nótese que de esta forma nuestra máquina start  será un servidor web y un servidor ftp.

En este ejemplo no hemos puesto las direcciones IP a usar para buscar los dominios de nivel superior,  están son facilitadas por los servidores raíz.

Otro ejemplo, en este caso del servidor DNS de la Universitat de València, lo podemos ver en las siguientes configuraciones a través de diferentes registros de recusos:

uv.es.   SOA    gong.ci.uv.es. root.gong.ci.uv.es. 
(2002041601 --número de serie
86400 -- DNS secundario deben conectar cada 24 horas
7200 - si no lo consiguen deben reintentar cada 2 horas
2592000 -los datos en DNS secundario caducan a los 30 días
172800)-tiempo de vida por defecto de los registros

uv.es.                         MX     10   sello.ci.uv.es.
uv.es.                         MX     20   postin.uv.es.

sello.ci                       MX     10   sello.ci.uv.es.
sello.ci                       MX     20   postin.uv.es.

sello.ci                       A      147.156.1.82
postin                         A      147.156.1.90

post                           CNAME  sello.ci.uv.es.

uv.es.      NS     sun.rediris.es. ;DNS secundario                             
NS     gong.ci.uv.es. 	;DNS primario             
NS     chico.rediris.es.    ;DNS secundario                       
NS     qfgate.quifis.uv.es. ;DNS secundario  
                     
localhost                      A      127.0.0.1

gong.ci                        A      147.156.1.1
gong.ci                       MX    10   gong.ci.uv.es.; Mail 1ª op
gong.ci                       MX    20   postin.uv.es.; Mail 2ª op
gong                          CNAME  gong.ci.uv.es.

sweb.informat                  A      147.156.16.46
sweb.informat                  MX     10   sweb.informat.uv.es.
sweb.informat                  MX     20   postin.uv.es.
informat.informat              CNAME  sweb.informat.uv.es.
informatica                    CNAME  sweb.informat.uv.es.
sweb                           CNAME  sweb.informat.uv.es.

proxy                          A      147.156.1.18
proxy                          A      147.156.1.162

dkw.ci                         A      147.156.1.46
dkw.ci                         MX     10   dkw.ci.uv.es.
dkw.ci                         MX     20   postin.uv.es.
www                            CNAME  dkw.ci.uv.es.
infoserver                     CNAME  dkw.ci.uv.es.

8.1.4 Zonas de autoridad

Toda la información acerca de un espacio de dominio se guarda en una computadora que llamamos Servidor de Nombres. Esto es la implementación física del llamado programa servidor que antes hemos mencionado. Generalmente, los servidores tienen información completa acerca de una parte del espacio de dominio de nombres, que llamamos zona de autoridad. Más exactamente una zona es la porción del espacio de nombres de dominio de la que es responsable un determinado servidor DNS. La zona de autoridad de estos servidores abarca al menos un dominio y también pueden incluir subdominios, aunque a veces los servidores de un dominio puede delegar sus dominios en otros servidores.

La diferencia entre una zona y un dominio es que la primera contiene los nombres de dominio y datos que representan a un dominio y un dominio es un nombre a que agrupa a otras máquinas o dominios inferiores.

Veamos en la figura 8.3 a continuación, una forma de dividir el espacio de nombres de la figura 8.2: 

					

		

edu	com	mil	gov	net	org	...	es	it	fr	us	....

ibm   cisco    oracle      nasa          ieee   acm		uv

tools		soft				       robotica	

				        oracle	cisco	lab1	lab2	lab3

					rut1 rut2 rut3              tools

Fig. 8.3: División en zonas de parte del Espacio de Dominio de Nombres.

Cada zona tendrá asignada un servidor de nombres primario que obtiene su información de su base de datos local y uno o más servidores secundarios que obtienen su información del servidor de nombres primario. Recordemos que (delegación de autoridad) el lugar donde se colocan los limites de una zona dentro de una zona es responsabilidad del administrador de esa zona.

Hasta ahora hemos nombrado sólo dos tipos de servidores los Primarios y los Secundarios. Según la configuración del servidor podemos encontrarnos con cuatro tipos de servidores, desempañando cada uno una función distinta. Veamos en detalle cada uno de ellos en la siguiente tabla:

Tipo de Servidor	Descripción	
Primarios (Primary Name Servers)	Almacenan la información de su zona en una base de datos local. Son responsables de mantener la información actualizada y cualquier cambio debe ser notificado a este servidor	
Secundarios (Secundary Name Servers)	Son aquellos que obtienen los datos de su zona desde otro servidor que tenga autoridad para esa zona. El proceso de copia de la información se denomina transferencia de zona.	
Maestros (Master Name Servers)	Los servidores maestros son los que transfieren las zonas a los servidores secundarios. Cuando un servidor secundario arranca busca un servidor maestro y realiza la transferencia de zona. Un servidor maestro para una zona puede ser a la vez un servidor primario o secundario de esa zona. Estos servidores extraen la información desde el servidor primario de la zona. Así se evita que los servidores secundarios sobrecargen al servidor primario con transferencias de zonas.	
Locales (Caching-only servers)	Los servidores locales no tienen autoridad sobre ningún dominio: se limitan a contactar con otros servidores para resolver las peticiones de los clientes DNS. Estos servidores mantienen una memoria caché con las últimas preguntas contestadas. Cada vez que un cliente DNS le formula una pregunta, primero consulta en su memoria caché. Si encuentra la dirección IP solicitada, se la devuelve al cliente; si no, consulta a otros servidores, apunta la respuesta en su memoria caché y le comunica la respuesta al cliente.	

Tabla. 8.3: Clasificación de servidores DNS.

8.1.5 El proceso de resolución de nombres de dominio 
La resolución de un nombre de dominio es la traducción del nombre a su correspondiente dirección IP. En este proceso como dijimos anteriormente hay dos partes el cliente, Resolver, y el servidor, el DNS. 
Un Resolver tiene las siguiente tareas:
-	Interrogar al Servidor de nombres, DNS
-	Interpretar las respuestas, que pueden ser RR o errores
-	Y devolver información al programa que ha solicitado la resolución
Para este proceso de traducción los Resolvers pueden formular dos tipos de preguntas: recursivas e iterativas: 
-	Cuando un cliente formula una pregunta recursiva a un servidor DNS, éste debe intentar por todos los medios resolverla aunque para ello tenga que preguntar a otros servidores. Esta es la forma de interrogación más frecuente.
-	Si el cliente formula una pregunta iterativa a un servidor DNS, este servidor devolverá o bien la dirección IP si la conoce o si no, la dirección de otro servidor que sea capaz de resolver el nombre. Esta forma de interrogación es poco utilizada y requiere que el cliente realice la consulta a otros DNS directamente.
Veamos un ejemplo: queremos visualizar en el browser la página web de la dirección www.uv.es. En primer lugar, el navegador tiene que resolver el nombre de dominio a una dirección IP. Después podrá comunicarse con la correspondiente dirección IP, abrir una conexión TCP con el servidor y mostrar en pantalla la página principal de la Universidad de Valencia. Los pasos que se van produciendo a lo largo del proceso de resolución los podemos resumir en los siguientes:
1.	Nuestro ordenador (cliente DNS) formula una pregunta recursiva a nuestro servidor DNS local (generalmente el proveedor de Internet). 
2.	El servidor local es el responsable de resolver la pregunta, aunque para ello tenga que reenviar la pregunta a otros servidores. Si el usuario a solicitado información local, el servidor extrae la respuesta de su propia base de datos. Si la información solicitada es sobre un ordenador externo, el servidor comprueba primero su caché de consultas recientes, si la respuesta esta aquí entonces la devuelve (no es de confianza). Suponemos que no conoce la dirección IP asociada a www.uv.es; entonces formulará una pregunta iterativa al servidor del dominio raíz. 
3.	El servidor del dominio raíz no conoce la dirección IP solicitada, pero devuelve la dirección del servidor del dominio es. 
4.	El servidor local reenvía la pregunta iterativa al servidor del dominio es. 
5.	El servidor del dominio es tampoco conoce la dirección IP preguntada, aunque sí conoce la dirección del servidor del dominio uv.es, por lo que devuelve esta dirección. 
6.	El servidor local vuelve a reenvíar la pregunta iterativa al servidor del dominio uv.es. 
7.	El servidor del dominio uv.es conoce la dirección IP de www.uv.es y devuelve esta dirección al servidor local. 
8.	El servidor local por fin ha encontrado la respuesta y se la reenvía a nuestro ordenador. Al mismo tiempo la respuesta es almacenada en la caché para futuras referencias. El tiempo máximo que permanece la información almacenada en la caché se configura en los servidores de confianza.
8.1.6 Preguntas inversas 
Los clientes DNS también pueden formular preguntas inversas, es decir, conocer el nombre de dominio dada una dirección IP. Para evitar una búsqueda exhaustiva por todo el espacio de nombres de dominio, se ha creado un dominio especial llamado in-addr.arpa. Cuando un cliente DNS desea conocer el nombre de dominio asociado a la dirección IP w.x.y.z formula una pregunta inversa a z.y.x.w.in-addr.arpa. La inversión de los bytes es necesaria debido a que los nombres de dominio son más genéricos por la derecha, al contrario que ocurre con las direcciones. Véase la figura siguiente:

ROOT

ARPA

EDU

COM

IN-ADDR

128

147

157

156

Figura.8.4 . Árbol para la resolución Inversa
La organización que posee una dirección de red es responsable de registrar todas sus traducciones de dirección a nombre en la base de datos del DNS. Esto se hace en una tabla que es independiente de las correspondencias entre nombre y direcciones. Como puede verse en el árbol de la fig. 8.4, el subárbol especial de dominio in-addr.arpa se creó para apuntar hacia todas esas tablas de red. Cuando se colocan las direcciones en el árbol, tiene sentido poner el primer número en la parte superior y bajar poco a poco.
8.1.7 Formato de los mensajes del DNS.

Los mensajes de consulta y respuesta intercambiados entre los clientes y los servidores del DNS tienen un formato muy sencillo. Un servidor añade la información requerida a la consulta original y la envía de vuelta. El formato general del mensaje se muestra a continuación:

Tabla. 8.4: Formato general de un mensaje DNS.

La cabecera contiene los campos que se muestran en la tabla siguiente:

Campo	Descripción	
ID	Identificador para hacer corresponder una respuesta con su petición	
Parámetros	Consulta o respuesta.
Consulta normal o inversa.
En respuestas, si es de confianza.
En respuestas, si está truncada.
Recursivo o no.
En respuestas, si la recursión está disponible.
En respuestas, código de error.	
Número de consultas.	Proporcionado en una consulta y en una respuesta.	
Número de respuestas.	Proporcionado en una respuesta.	
Número de registros de autoridad.	Proporcionado en una respuesta. La información de los registros de autoridad incluye los nombres de los servidores que contienen los datos de confianza.	
Número de registros adicionales.	Proporcionado en una respuesta. La información incluye las direcciones de los servidores de confianza.	

Tabla. 8.5: Descripción de los campos de cabecera de un mensaje DNS.

La sección de consulta contiene los campos que se muestran en la tabla siguiente. Normalmente, un mensaje contiene una única consulta, pero se permite concatenar varias peticiones en la sección de consulta.

Campo	Descripción	
Nombre	Nombre de dominio o dirección de IP en el subárbol IN-ADDR.ARPA.	
Tipo	Tipo de consulta, por ejemplo A o NS.	
Clase	IN para Internet, se representa como 1.	

Tabla. 8.6: Campos de la sección de consulta de un mensaje DNS.

Las secciones de respuesta, información de autoridad e información adicional se estructuran todas ellas de la misma forma. Consisten en una secuencia de registros de recurso que contienen los campos que se muestran en la tabla siguiente:

Campo	Descripción	
Nombre	Nombre del nodo para este registro.	
Tipo	Tipo de registro, como SOA o A, indicado por un código numérico.	
Clase	IN, se representa como 1.	
TTL	Tiempo de vida, un entero con signo de 32 bits que indica cuánto tiempo el registro puede permanecer en la caché.	
RDLENGTH	Tamaño del campo de datos de recursos.	
RDATA	La información, por ejemplo, para un registro de direcciones, es la dirección IP. Para un registro SOA, incluye información más extensa.	

Tabla. 8.7: Campos de la respuesta de un mensaje DNS.

La sección de información de autoridad identifica los servidores de nombres de confianza para el dominio. La sección de información adicional proporciona información, como las direcciones IP de los servidores de nombres de confianza.
	
8.1.8 Ejemplo de consulta de direcciones: comandos nslookup (host o dig)

Un programa cliente capaz de consultar información sobre el sistema de nombres de dominio es parte estándar de los productos TCP/IP y se denomina resolutor. Normalmente, un resolutor trabaja discretamente en segundo plano y los usuarios no conocen su presencia, es decir que, toda consulta de un cliente DNS a su servidor suele realizarla el programa que invocamos (telnet, ftp, mail, navegador web, etc.).  Por ejemplo, un usuario solicita una conexión telnet a glup.irobot.uv.es, la aplicación telnet del usuario llama a un programa resolutor local que busca la dirección IP de ese ordenador (147.156.160.55) sin que el usuario tenga conciencia de ello.

Además de este trabajo en segundo plano, el usuario puede conectarse directamente al programa resolutor enviando consultas y resolviendo respuestas. Esto puede hacerse en WindowsNT/2000 y UNIX con el comando nslookup. El comando “nslookup” en algunas distribuciones de Linux no está soportado y han creado el comando “host” para consulta de direcciones IP y “dig” para consulta de servidores DNS activos. Veamos el diálogo establecido con “nslookup”, con ejecución equivalente a “host” y “dig”:

1.	Inmediatamente después de que el usuario teclee nslookup, el servidor local por defecto se identifica mostrando en pantalla su nombre y dirección. En este caso el nombre es glup.irobot.uv.es y la dirección 147.156.160.55.

2.	El usuario teclea el nombre del ordenador cuya dirección desea conocer.

3.	La petición se envía al servidor.

4.	Después de cada consulta, el servidor (glup.irobot.uv.es) se identifica y proporciona la respuesta.

5.	Si el usuario ha solicitado información local, el servidor extrae la respuesta de su propia base de datos.

6.	Si el usuario ha solicitado información sobre un ordenador externo, el servidor comprueba primero su caché de consultas recientes para ver si la información está disponible y, si no es así, interacciona con un servidor remoto de confianza para obtener la respuesta.

7.	Cuando se recibe una respuesta del servidor remoto de confianza, la respuesta se almacena en la caché de disco del servidor local para futuras referencias y, a continuación, se envía al usuario solicitante. El tiempo de validez de la respuesta en la caché se configura en los servidores remotos de confianza y se envía como parte de la respuesta.

Veamos un ejemplo de funcionamiento del comando nslookup.

>nslookup
Default Name Server: glup.irobot.uv.es	Se muestra el nombre y dirección del servidor local.
Address: 147.156.160.55

>mozart.econom.uv.es.		El usuario realiza una consulta local.
Name Server: glup.irobot.uv.es	De nuevo nombre y dirección del servidor local.
Address: 147.156.160.55

Name: mozart.econom.uv.es		El nombre de la consulta.
Address: 147.156.209.32		La respuesta.

>ftp.funet.fi.				El usuario realiza una consulta remota.
Name Server: glup.irobot.uv.es	De nuevo nombre y dirección del servidor local.
Address: 147.156.160.55

Name: ftp.funet.fi			El nombre de la consulta.
Address: 128.214.248.6		La respuesta.

>ftp.funet.fi.				El usuario repite la consulta remota.
Name Server: glup.irobot.uv.es	De nuevo nombre y dirección del servidor local.
Address: 147.156.160.55

Non-authoritative answer:		Está respuesta se obtuvo de la cache.
Name: ftp.funet.fi			El nombre de la consulta.
Address: 128.214.248.6		La respuesta.

Una pregunta que puede hacerse es: ¿Porque el servidor continúa identificándose a sí mismo?. Esto es debido a que en una organización mantiene en funcionamiento dos o más servidores, ya que uno de ellos podría estar muy ocupado o incluso, fuera de servicio, por ejemplo, para mantenimiento. Si el resolutor no puede obtener una respuesta del primer sistema de la lista, lo intenta con el siguiente. Un administrador que utilice nslookup puede ver de inmediato que servidor está atendiendo la consulta.

Traducción de dirección a nombre.

El sistema de nombres de dominio es versátil y permite realizar traducciones de dirección a nombres. La forma de hacerlo utilizando nslookup puede parecer un poco extraña:

•	Se determina que la consulta sea de tipo ptr.

•	Se escribe la dirección en sentido inverso, seguida de .in-addr.arpa.

Por ejemplo:

>nslookup
>set type=ptr
>1.1.156.147.in-addr.arpa.

Name Server: glup.irobot.uv.es	Nombre y dirección del servidor local.
Address: 147.156.160.55

1.1.156.147.in-addr.arpa	name= gong.ci.uv.es

Esta singularidad tiene sentido cuando se conoce cómo están construidas las consultas globales inversas. La organización que posee una dirección de red es responsable de registrar todas sus traducciones de dirección a nombre en la base de datos del DNS. Esto se hace en una tabla que es independiente de las correspondencias entre nombre y direcciones.

El subárbol especial de dominio in-addr.arpa como hemos dicho anteriormente se creó para apuntar hacia todas esas tablas de red. Cuando se colocan las direcciones en el árbol, tiene sentido poner el primer número en la parte superior y bajar poco a poco. De está forma, todas las direcciones del tipo 147.x.x.x están debajo del nodo 147.

Si leemos las estiquetas del árbol utilizando el mismo convenio de abajo hacia arriba que utilizábamos para los nombres, la dirección aparece en sentido inverso, es decir, 1.1.156.147.in-addr.arpa. Este tecnicismo puede ocultarse en la mayoría de servidores nslookup, pues introduciendo la pregunta:

>147.156.1.1
Name Server: glup.irobot.uv.es	Nombre y dirección del servidor local.
Address: 147.156.160.55

Name: gong.ci.uv.es
Address: 147.156.1.1

Se obtiene el nombre del ordenador como si la pregunta hubiera sido la de la dirección conocido el nombre del ordenador.

Con el comando “host” resulta de forma similar. Dicho programa es /usr/bin/host.

Así, si deseamos consultar la dirección IP del ordenador “glup” del Instituto de Robótica de la Universitat de València, basta con ejecutar:

host glup.irobot.uv.es

Y obtener como respuesta la siguiente línea.

glup.irobot.uv.es has address 147.156.222.65

De igual forma, podemos realizar una consulta inversa, esto es, introducir la dirección IP de un ordenador y obtener su nombre. Por ejemplo:

host 147.156.222.65

Devuelve como respuesta la línea:

65.222.156.147.in-addr.arpa domain name pointer glup.irobot.uv.es

Servidores de nombres de dominios locales y globales.

Si se posee una red TCP/IP independiente, se puede utilizar el software del DNS para crear una base de datos primaria de traducción de nombres y duplicarla en los lugares de la red que se estime conveniente. Todas las consultas de usuarios serán atendidas por los servidores propios de nombres. Pero si la red se conecta a Internet, los servidores de nombres necesitarán obtener información global. Esto se consigue inscribiendo la organización que quiere conectarse a Internet en una autoridad de registro, en este caso InterNIC, e identificando los nombres y direcciones de, al menos, dos servidores de nombres de dominio que vaya a utilizar. La autoridad de inscripción InterNIC añade esta información a su listado principal de servidores de nombres de dominio.

Este listado principal se duplica en muchos servidores raíz, que tienen un papel fundamental a la hora de procesar consultas remotas. Por ejemplo, supongamos que se envía una petición de traducción de nombre a dirección para ftp.funet.fi al servidor local de nombres de dominio:

•	El servidor comprueba si ftp.funet.fi pertenece al dominio local.

•	Si no es así, el servidor comprueba si el nombre se encuentra en su caché.

•	Si el nombre no está en la caché, el servidor envía una consulta a un servidor raíz.

•	El servidor raíz devuelve el nombre y dirección de los servidores de nombres de dominio que contienen información sobre funet.fi.

Para ver la lista de servidores raíz, ejecutamos nslookup indicando que la consulta sea de tipo ns. Si introducimos <<.>> (que indica la raíz), nos devuelve los nombres y direcciones de varios servidores base.

>nslookup
>set type=ns
>.

Non-authoritative answer:
(root)  nameserver = B.ROOT-SERVERS.NET
(root)  nameserver = C.ROOT-SERVERS.NET
(root)  nameserver = D.ROOT-SERVERS.NET
(root)  nameserver = E.ROOT-SERVERS.NET
(root)  nameserver = I.ROOT-SERVERS.NET
(root)  nameserver = F.ROOT-SERVERS.NET
(root)  nameserver = G.ROOT-SERVERS.NET
(root)  nameserver = J.ROOT-SERVERS.NET
(root)  nameserver = K.ROOT-SERVERS.NET
(root)  nameserver = L.ROOT-SERVERS.NET
(root)  nameserver = M.ROOT-SERVERS.NET
(root)  nameserver = A.ROOT-SERVERS.NET
(root)  nameserver = H.ROOT-SERVERS.NET

Authoritative answers can be found from:
(root)  nameserver = B.ROOT-SERVERS.NET
(root)  nameserver = C.ROOT-SERVERS.NET
(root)  nameserver = D.ROOT-SERVERS.NET
(root)  nameserver = E.ROOT-SERVERS.NET
(root)  nameserver = I.ROOT-SERVERS.NET
(root)  nameserver = F.ROOT-SERVERS.NET
(root)  nameserver = G.ROOT-SERVERS.NET
(root)  nameserver = J.ROOT-SERVERS.NET
(root)  nameserver = K.ROOT-SERVERS.NET
(root)  nameserver = L.ROOT-SERVERS.NET
(root)  nameserver = M.ROOT-SERVERS.NET
(root)  nameserver = A.ROOT-SERVERS.NET
(root)  nameserver = H.ROOT-SERVERS.NET
B.ROOT-SERVERS.NET      internet address = 128.9.0.107
C.ROOT-SERVERS.NET      internet address = 192.33.4.12
D.ROOT-SERVERS.NET      internet address = 128.8.10.90
E.ROOT-SERVERS.NET      internet address = 192.203.230.10
I.ROOT-SERVERS.NET      internet address = 192.36.148.17
F.ROOT-SERVERS.NET      internet address = 192.5.5.241
G.ROOT-SERVERS.NET      internet address = 192.112.36.4

Los servidores raíz proporcionan referencias directas a servidores de los dominios de segundo nivel, como COM, EDU, GOV, etc.

Podemos obtener la información sobre los servidores de nombres de una organización por medio de nslookup especificando set type=ns y el dominio de la organización:

>nslookup
>set type=ns
>uv.es

Name Server:  glup.irobot.uv.es
Address:  147.156.160.55

uv.es   nameserver = gong.ci.uv.es
uv.es   nameserver = sun.rediris.es
uv.es   nameserver = chico.rediris.es
uv.es   nameserver = qfgate.quifis.uv.es
gong.ci.uv.es   internet address = 147.156.1.1
sun.rediris.es  internet address = 130.206.1.2
chico.rediris.es        internet address = 130.206.1.3
qfgate.quifis.uv.es     internet address = 147.156.122.64

Sin embargo, en lugar de que InterNIC mantenga actualizadas las listas de servidores pertenecientes a organizaciones de todo el mundo, cada país mantiene su servicio propio de inscripción y publica una lista de servidores de dominio en sus propios servidores principales.

Cuando se buscan servidores de nombres para un código de país, la base de datos raíz de InterNIC devuelve una lista de nombres y direcciones de servidores raíz de ese país. Así, si en el dialogo anterior podemos preguntar por la lista de servidores españoles.

>es.

Name Server:  glup.irobot.uv.es
Address:  147.156.160.55

Non-authoritative answer:
es      nameserver = SUN.REDIRIS.ES
es      nameserver = CHICO.REDIRIS.ES
es      nameserver = PRADES.CESCA.ES
es      nameserver = NS.EUNET.ES
es      nameserver = SUNIC.SUNET.SE
es      nameserver = NS.EU.NET
es      nameserver = RS0.INTERNIC.NET
es      nameserver = NS.UU.NET

Authoritative answers can be found from:
es      nameserver = SUN.REDIRIS.ES
es      nameserver = CHICO.REDIRIS.ES
es      nameserver = PRADES.CESCA.ES
es      nameserver = NS.EUNET.ES
es      nameserver = SUNIC.SUNET.SE
es      nameserver = NS.EU.NET
es      nameserver = RS0.INTERNIC.NET
es      nameserver = NS.UU.NET
SUN.REDIRIS.ES  internet address = 130.206.1.2
CHICO.REDIRIS.ES        internet address = 130.206.1.3
PRADES.CESCA.ES internet address = 192.94.163.152
NS.EUNET.ES     internet address = 193.127.1.11
SUNIC.SUNET.SE  internet address = 192.36.125.2
NS.EU.NET       internet address = 192.16.202.11
RS0.INTERNIC.NET        internet address = 198.41.0.5
NS.UU.NET       internet address = 137.39.1.3

De hecho, el sistema de nombres de dominio es muy flexible y permite una cadena larga de referencias. Un país puede dividirse en regiones de nombres y la raíz nacional podría apuntar a servidores raíz de cada región.

De forma similar, cualquier organización puede establecer un árbol raíz propio que apunte a servidores de nombres de dominio de confianza para partes de su dominio de nombres. En la práctica, se realizan relativamente pocas subdivisiones y, por tanto, los nombres se encuentran en muy pocos pasos.

Otro tipo de información, se podría extraer a través de la siguiente consulta: 

>nslookup
>set q=any
>uv.es
>ls –d uv.es 

lo que permite listar y enumerar la información completa del dominio uv.es.

8.1.9 Conexión a Internet y diseño de la base de datos de un servidor de nombres.

La conexión de un servidor de nombres de dominio particular a la base de datos mundial de Internet necesita:

1.	Registrar uno o más bloques de direcciones IP y, opcionalmente, un número de sistema autónomo.

2.	Asignar nombres y direcciones a los ordenadores propios.

3.	Obtener la lista de servidores raíz que, en conjunto, cubran el servicio mundial.

4.	Construir un servidor de nombres de dominio primario y, al menos, una copia secundaria.

5.	Comprobar los servidores.

6.	Pasar a la condición de operativo.

7.	Registrar los nombres de dominio y servidores de la organización en los servicios de inscripción de la región.

El diseño de la base de datos puede realizarse estructurando toda la información como una base de datos única, si la organización es pequeña, o bien, en organizaciones grandes, distribuidas geográficamente, puede tener más sentido delegar la gestión del árbol de nombres de la organización en los administradores de esos lugares, e incluso, tener en funcionamiento servidores de nombre independientes en esas ubicaciones.

El árbol de nombres de una organización se compone de una o más zonas. Una zona es una parte contigua del árbol de nombres que se administra como una unidad. Por ejemplo, si observamos la figura 8.5 vemos que corresponde a una empresa con una central y dos sucursales. La base de datos raíz de Internet apuntará a los servidores de nombres de la oficina central. Estos servidores responderán directamente a peticiones de nombres que pertenezcan a su zona. Si se solicita un nombre de otra de las zonas, el servidor de la oficina central devolverá los nombres y direcciones de los servidores adecuados. Entonces, el servidor de nombres de dominio que originó la consulta enviará la petición al servidor correcto para esa zona.

Figura 8.5: Ejemplo de árbol de nombres de una organización.

Para muchas organizaciones resulta más sencillo tener en funcionamiento un único grupo de servidores primarios y secundarios en su red interna, incluso aunque los datos se repartan para varias zonas. Resulta completamente aceptable la utilización de un servidor para varias zonas, e incluso, para varios dominios. Los datos de cada zona se almacenarán en un archivo diferente. Cada archivo puede actualizarlo un administrador diferente si es necesario.

Para poder acceder a una copia de la información sobre una o más zonas se instala un servidor secundario. Este obtiene su información del servidor primario de la zona mediante una transferencia de zona.

Se puede configurar un servidor secundario para que consiga información de varias zonas, de servidores primarios diferentes. De esta forma, un servidor puede actuar como secundario para varios primarios diferentes. Un servidor puede actuar, incluso, como primario para algunas zonas y secundario para otras. Un servidor de nombres necesita, para poder resolver los nombres:

•	Una lista de los servidores raíz mundiales para conocer a dónde debe enviar las consultas externas. Se puede copiar un archivo de InterNIC que contiene esta lista del registro.

•	Una lista de nombres con sus direcciones correspondientes.

•	Una lista de direcciones con sus nombres correspondientes.

Como hemos visto, los datos del DNS se almacena como una serie de entradas de texto o registros de recursos con el formato:

[nombre]   [TTL]   [clase]   Tipo-Registro   Dato-Registro   [; comentario]

8.1.10 Configuración de un cliente y un servidor de DNS estático.

Veremos a continuación como configurar, en UNIX, un ordenador como cliente de DNS así como la forma de realizar la configuración de un ordenador como servidor de DNS, tanto como servidor primario como servidor secundario de la red.

Aunque en este apartado sólo vamos a estudiar DNS estáticos, hay otras configuraciones que se llaman DNS dinámicos, que lo que hacen en vincular las direcciones IP asignadas por DHCP (Dynamic Host Configuration Protocol) con los nombres de forma dinámica.

Configuración de un cliente de DNS.

La existencia de un cliente DNS es necesaria en todo ordenador conectado a Internet, excepto, que deseemos realizar cualquier operación en Internet conociendo la dirección IP de los ordenadores y no su nombre, y además deseemos no utilizar servicios como el de los servidores virtuales de páginas Web.

El funcionamiento del cliente DNS se basa en tres ficheros, hosts, host.conf y resolv.conf, que pasamos a explicar de forma detallada a continuación.

El primero de estos ficheros, /etc/hosts, puede considerarse como una herencia del antiguo fichero host.txt de ARPANET que hemos comentado con anterioridad. El fichero contiene la relación entre los nombres y las direcciones IP de todos los ordenadores necesarios en el arranque del ordenador, cuando este todavía no tiene activados sus interfaces de acceso a la red y por tanto no puede consultar los servidores de DNS. Aunque dicho fichero es de forma general una sola línea, pueden añadirse en el todas las líneas que se deseen conteniendo cada una la relación entre el nombre de un ordenador y su dirección IP. Un ejemplo del fichero es el siguiente:

127.0.0.1	glup		localhost	localhost.localdomain
147.156.222.65	glup		glup.uv.es

La primera línea, 127.0.0.1 es siempre necesaria, pues hace referencia a localhost, que es el nombre por defecto del ordenador en el arranque, antes de activar sus dispositivos de acceso a la red.

El segundo de estos ficheros, /etc/host.conf, indica el orden en que deben utilizarse las posibilidades disponibles para la resolución de los nombres, esto es, si primero debe mirarse el fichero /etc/hosts y en caso de no encontrar allí la resolución del nombre debe consultarse al servidor de nombres o bien debe hacerse al contrario. La entrada típica de este fichero es:

order hosts,bind

Que indica que el orden es primero mirar el fichero local (hosts) y, en caso de no obtener respuesta, recurrir al servidor de nombres (bind).

El tercer fichero, /etc/resolv.conf, indica el dominio al que pertenece este ordenador y las direcciones IP de los servidores de nombres a los que pueden efectuarse las consultas. Los parámetros de configuración más utilizados en este fichero son domain, search y nameserver.

El parámetro domain indica el dominio al que pertenece el ordenador, de forma que se puedan realizar consultas de nombres de ordenadores pertenecientes al dominio sin que sea necesario escribir el nombre completo del ordenador, esto es, su nombre más el nombre del dominio. Así, la especificación con el parámetro domain del dominio uv.es, permite realizar una consulta de nombre de ordenador “post” y obtener la respuesta 147.156.1.112, sin necesidad de preguntar por su nombre completo, esto es “post.uv.es”.

El segundo parámetro, search, es una generalización del anterior, de forma que es posible especificar hasta seis dominios donde la suma de la longitud de los nombres de todos ellos no exceda de 256 caracteres. Este parámetro, a pesar de representar una ventaja sobre el anterior, no suele usarse, o bien se usa con un solo dominio, el del ordenador servidor de DNS, pues en caso contrario obliga a los servidores a generar una gran cantidad de tráfico, realizando consultas a los servidores de todos los dominios que se especifiquen hasta encontrar la respuesta, si esta existe. Como consecuencia añadida del efecto anterior, la resolución de nombres puede volverse muy lenta, llegando los clientes a producir fallos por suceder un “timeout” en la espera de la respuesta.

El último parámetros, nameserver, indica las direcciones IP de los servidores de red que podemos consultar. Pueden existir tantas entradas nameserver como se deseen, consultándose los servidores en el orden en que se encuentran sus entradas. Por ello, deben ponerse en primer lugar aquellos servidores que se consideren más rápidos y disponibles, pues ello disminuye el tiempo de respuesta, tanto por la rapidez del servidor, como por el hecho de que si un servidor esta disponible de forma intermitente en el tiempo, toda pregunta que se le realice cuando no esta disponible deberá esperar el que suceda un “timeout” para enviar dicha pregunta al siguiente servidor de nombres.

Un ejemplo de fichero /etc/resolv.conf es el siguiente:

domain		uv.es
nameserver		147.156.222.65
nameserver		147.156.1.1
nameserver		147.156.1.3

Configuración de un servidor primario de DNS.

Para configurar un servidor primario de DNS es necesario configurar cinco ficheros. Estos ficheros son:

/etc/named.boot
/var/named/db.127.0.0.local
/var/named/db.irobot
/var/named/db.147.156.160
/var/named/db.cache

El archivo /etc/named.boot especifica el directorio y el nombre del dominio en el que se localizan los archivos del DNS. Este archivo es leído por el programa servidor de DNS, llamado named y usado para su configuración. Un ejemplo típico del fichero /etc/named.boot para un servidor primario es:

;
; Archivo /etc/named.boot
;
domain	irobot.uv.es	; Dominio del cual es servidor primario.
directory	/var/named	; Directorio de trabajo.
;
primary	0.0.127.IN-ADDR.ARPA		db.127.0.0.local
primary	irobot.uv.es				db.irobot
primary	160.156.147.IN-ADDR.ARPA	db.147.156.160
cache		.					db.cache

El archivo db.127.0.0.local ,cuya localización siempre se encuentra referida al directorio especificado en el archivo archivo /etc/named.boot, se utiliza para especificar la interfaz de loopback para el servidor primario de nombres de dominio. Un ejemplo típico es:

;
; Fichero primario inverso para la red local 127
;
@       IN      SOA     glup.irobot.uv.es.      root.glup.irobot.uv.es.
                        (
                        1       ; Serie
                        28800   ; Refrescar cada 8 horas
                        3600    ; Reintentar cada hora
                        604800  ; Expirar al cabo de una semana
                        86400   ; El defecto es un dia
                        )
         IN      NS      glup.irobot.uv.es.
1       IN      PTR     localhost.

El archivo db.cache proporciona información sobre los servidores raíz de DNS. Un ejemplo de este archivo es:

;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129 
;
; temporarily housed at ISI (IANA)
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
; housed in Japan, operated by WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
; End of File

Los archivos db.irobot y db.147.156.160 proporcionan información sobre los ordenadores y direcciones de IP, en formato directo en el archivo db.irobot y en formato inverso en el archivo db.147.156.160, asociadas al dominio irobot.uv.es. Un ejemplo típico de estos archivos es:

;
; Archivo /var/named/db.irobot
;

@       IN      SOA     glup.irobot.uv.es.      root.glup.irobot.uv.es.
                        (
                        1       ; Serie
                        28800   ; Refrescar cada 8 horas
                        3600    ; Reintentar cada hora
                        604800  ; Expirar al cabo de una semana
                        86400   ; El defecto es un dia
                        )
         IN      NS      glup.irobot.uv.es.
amparo      IN      A     147.156.160.54
glup           IN      A     147.156.160.55
carpanta   IN     A      147.156.160.56

;
; Archivo /var/named/db.147.156.160
;
@       IN      SOA     glup.irobot.uv.es.      root.glup.irobot.uv.es.
                        (
                        1       ; Serie
                        28800   ; Refrescar cada 8 horas
                        3600    ; Reintentar cada hora
                        604800  ; Expirar al cabo de una semana
                        86400   ; El defecto es un dia
                        )
          IN      NS      glup.irobot.uv.es.
54      IN      PTR     amparo.irobot.uv.es.
55     IN      PTR      glup.irobot.uv.es.
56     IN     PTR       carpanta.irobot.uv.es.

Configuración de un servidor secundario de DNS.

La configuración de un servidor secundario de DNS es mucho más sencilla. Basta con configurar solo tres ficheros, estos fichero son:

/etc/named.boot
/var/named/db.127.0.0.local
/var/named/db.cache

El archivo /etc/named.boot especifica el directorio y el nombre del dominio en el que se localizan los archivos del DNS. Este archivo es leído por el programa servidor de DNS, llamado named y usado para su configuración. Un ejemplo típico del fichero /etc/named.boot para un servidor secundario es:

;
; type          domain          source file
;

domain          uv.es		 ; Dominio del cual es servidor secundario
directory       /var/named 	; Directorio de trabajo

primary          0.0.127.IN-ADDR.ARPA                                db.127.0.0.local
secondary       uv.es                                      147.156.1.1     db.uv.bak
secondary       156.147.IN-ADDR.ARPA     147.156.1.1     db.147.156.bak
cache               .                                                                    db.cache

Si se observa, en las líneas secondary de la definición del servidor secundario de DNS, aparece la dirección IP (147.156.1.1) del servidor primario de DNS del cual se deben leer las tablas con las direcciones y nombres de los ordenadores del dominio del que se es servidor secundario, y guardarlas en los ficheros indicados (db.uv.bak y db.147.156.bak).

Los ficheros, db.uv.bak y db.147.156.bak, son copiados del servidor primario indicado, por lo cual no es necesario crearlos ni realizar ninguna acción sobre los mismos, pues son los administradores del servidor primario los que se encargan de introducir las altas, bajas o modificaciones que hayan podido producirse.

Los ficheros db.127.0.0.local y db.cache son iguales a los mostrados en el caso del servidor primario de DNS y no requieren por tanto una mayor explicación.

8.1.11 RFCs

RFC’s principalesRFC 920: Domain Requierments
RFC 1101: DNS Enconding of Network Names and Other TypesRFC 1033 : Domain Adminstrators Operations Guide RFC 1034:  Domain Names – Concepts and FacilitiesRFC 1035:  Domain Names – Implementation and SpecificationRFC 1591: Domain Name System Structure and DelegationRFC 1183: New RR Types 
También se está trabajando en DNS y seguridad para evitar el ataque conocido como DNS Spoofing o suplantación. RFC 2535.

8.2 Correo electrónico (Simple Mail Transfer Protocol: SMTP)

8.2.1 Introducción

El correo electrónico o email, ha existido desde hace más de dos décadas. Los primeros sistemas de correo electrónico simplemente consistían en protocolos de transferencia de archivos, con la convención de que la primera línea de cada mensaje (es decir del archivo) contenía la dirección del destinatario. A medida que pasó el tiempo, las limitaciones de este enfoque se hicieron obvias. Algunas eran:

•	El envío de un mensaje a un grupo de gente era laborioso. Los administradores con frecuencia necesitaban esta facilidad para enviar un memorando a todos sus subordinados.

•	Los mensajes no tenían estructura interna, dificultando el proceso del mismo por parte de la computadora. Por ejemplo, si un mensaje reenviado se incluía en el cuerpo de otro mensaje, la extracción de la parte reenviada del mensaje recibido era difícil.

•	El remitente nunca sabía si el mensaje había llegado o no.

•	Si alguien planeaba ausentarse por un viaje durante varias semanas y quería que el correo entrante fuera manejado por otra persona, esto no era fácil de arreglar.

•	La interfaz de usuario estaba mal integrada al sistema de transmisión, requiriendo que el usuario editara un archivo, luego saliera del editor e invocara el programa de transferencia.

•	No era posible crear y enviar mensajes que contuvieran una mezcla de texto, dibujos, facsímiles y voz.

A medida que se acumuló experiencia, se propusieron sistemas de correo electrónico más elaborados. Así, en 1982 se publicaron las propuestas de correo electrónico del ARPANET como RFC 821 (protocolo de transmisión) y RFC 822 (formato de mensaje). Dos años después, el CCITT elaboró su recomendación X.400, que luego se tomó como base para el MOTIS de OSI. En 1988, el CCITT modificó el X.400 para alinearlo con MOTIS. MOTIS debía ser la aplicación insignia del OSI, un sistema que era todo para todos.

Tras una década de competencia, los sistemas de correo basados en RFC 822 se usan ampliamente y se han convertido en los estándares de facto de Internet y los basados en el X.400 han desaparecido. La razón del éxito del RFC 822 no es que sea mejor que X.400, sino que X.400 está mal diseñado y es tan complejo que nadie pudo implementarlo bien. Dada la opción entre un sistema de correo electrónico sencillo pero funcional basado en el RFC 822 y un sistema de correo electrónico X.400 supuestamente maravilloso pero no funcional, muchas organizaciones escogieron el primero.

8.2.2 Arquitectura de los sistemas de correo electrónico.

La idea clave de todos los sistemas modernos de correo electrónico es la distinción entre la envoltura y su contenido. La envoltura encapsula el mensaje o envolvente primitiva, contiene toda la información necesaria para transportar el mensaje, como la dirección de destino, prioridad y nivel de seguridad, etc., información que es independiente del mensaje mismo y está especificada en RFC821. El mensaje se encuentra en el interior de la envoltura y contiene dos partes: la cabecera y el cuerpo, ambos especificados en RFC822. La cabecera contiene información de control para la computadora. El cuerpo es por completo para el destinatario humano. Los actuales sistemas de correo electrónico desempeñan cinco funciones básicas:

1.	La composición, que es el proceso de crear mensajes y respuestas. Aunque puede crearse un mensaje usando cualquier editor de texto para el cuerpo del mensaje, el sistema mismo puede proporcionar asistencia para el direccionamiento y los numerosos campos de cabecera que forman parte de cada mensaje. Por ejemplo, al contestar un mensaje, el sistema de correo electrónico puede extraer la dirección del emisor e insertarla automáticamente en el lugar adecuado del mensaje de respuesta.

2.	La transferencia, que se refiere a mover mensajes del emisor al destinatario. En gran medida, esto requiere establecer una conexión con el destino o alguna máquina intermedia, enviar el mensaje y liberar la conexión. El sistema de correo electrónico debe hacer esto automáticamente, sin molestar al usuario.

3.	La generación del informe, tiene que ver con indicar al remitente lo que ocurrió con el mensaje. Existen muchas aplicaciones en las que la confirmación de la entrega es importante y puede incluso tener implicación legal.

4.	La visualización de los mensajes de entrada es necesaria para que la gente pueda leer su correo electrónico. A veces se requiere cierta conversión o debe invocarse un visor especial, por ejemplo si el mensaje es un archivo PostScript o voz digitalizada. También se intentan a veces conversiones y formatos de presentaciones sencillos.

5.	La disposición es el paso final y se refiere a lo que el destinatario hace con el mensaje tras recibirlo. Las posibilidades incluyen tirarlo antes de leerlo, desecharlo tras leerlo, guardarlo, etc. También debe ser posible recuperar y releer mensajes guardados, reenviarlos o procesarlos de otras maneras.

Además de estos servicios básicos, la mayoría de los sistemas de correo electrónico proporcionan una gran variedad de características avanzadas como puede ser el reenvío automático de correo, la creación de buzones de correo independientes para almacenar el correo entrante, etc.

Un sistema de correo electrónico consiste generalmente en dos subsistemas distintos:

•	Los agentes de transferencia de mensajes son los encargados de mover los mensajes del origen al destino. Por lo general son "daemons" del sistema operativo que trabajan en segundo plano y se encargan de recoger el correo electrónico, transferir el correo electrónico de una computadora a otra hasta su destino y almacenarlo una vez llegado al destino. Los agentes de transferencia del mensaje usan la envoltura para calcular la ruta que debe seguir el correo, de igual forma a como sucede en una oficina postal.

•	Los agentes de usuario permiten a la gente leer y enviar el correo electrónico. Los agentes de usuario son programas locales que proporcionan un método basado en comandos, basado en menús o basado en la interacción gráfica, para comunicarse con el sistema de correo electrónico.

Los agentes de transferencia de mensajes: SMTP y ESMTP

El sistema de transferencia de mensajes se encarga de transmitir los mensajes del remitente al destinatario. La manera más sencilla de hacer esto es establecer una conexión de transporte de la máquina de origen a la de destino y sencillamente transferir el mensaje.

En Internet, el correo electrónico se transfiere de la computadora origen a la computadora destino, mediante el establecimiento de una conexión TCP desde la computadora origen al puerto 25 de la computadora destino. Escuchando este puerto está un "daemon" de correo electrónico capaz de usar el protocolo SMTP (Simple Mail Transfer Protocol). Este "daemon" acepta conexiones de entrada y copia mensajes de ellas a los buzones adecuados. Si no puede entregarse un mensaje, se devuelve al transmisor un informe de error que contiene la primera parte del mensaje que no pudo entregarse.

SMTP: Protocolo sencillo de transferencia de correo.

El SMTP es un sencillo protocolo cliente/servidor en formato ASCII. Establecida una comunicación TCP entre la computadora transmisora del correo, que opera como cliente, y el puerto 25 de la computadora receptora del correo, que opera como servidor, la computadora cliente permanece a la espera de recibir un mensaje de la computadora servidor. El servidor comienza por enviar una línea de texto que proporciona su identidad e indica si está preparado o no para recibir correo. Si no lo está, el cliente libera la conexión y lo intenta después.

Si el servidor está dispuesto a aceptar correo electrónico, el cliente anuncia de quién viene el mensaje, y a quién está dirigido. Si existe tal destinatario en el destino, el servidor da al cliente permiso para enviar el mensaje. Entonces el cliente envía el mensaje y el servidor acusa su recibo. Si existe más correo electrónico se envía ahora. Una vez que todo el correo ha sido intercambiado en ambas direcciones, se libera la conexión.

Los comandos y respuestas del protocolo SMTP así como su significado pueden verse en las tablas siguientes. Son intercambiados tal cual entre los agentes en formato ASCII, por lo cual podemos reliazar una conexión al servidor post.uv.es con un telnet post.uv.es 25 e introducir dichos comandos, siguiendo el protocolo. 

Comando	Descripción	
HELO	Identifica el remitente al destinatario.	
MAIL FROM	Identifica una transacción de correo e identifica al emisor.	
RCPT TO	Se utiliza para identificar un destinatario individual. Si se necesita identificar múltiples destinatarios es necesario repetir el comando.	
DATA	Permite enviar una serie de líneas de texto. El tamaño máximo de una línea es de 1.000 caracteres. Cada línea va seguida de un retorno de carro y avance de línea <CR><LF>. La última línea debe llevar únicamente el carácter punto "." seguido de <CR><LF>.	
RSET	Aborta la transacción de correo actual.	
NOOP	No operación. Indica al extremo que envíe una respuesta positiva. Utilizados para keepalives.	
QUIT	Pide al otro extremo que envíe una respuesta positiva y cierre la conexión.	
VRFY	Pide al receptor que confirme que un nombre identifica a un destinatario valido.	
EXPN	Pide al receptor la confirmación de una lista de correo y que devuelva los nombres de los usuarios de dicha lista.	
HELP	Pide al otro extremo información sobre los comandos disponibles.	
TURN	El emisor pide que se inviertan los papeles, para poder actuar como receptor. El receptor puede negarse a dicha petición.	
SOML	Si el destinatario está conectado, entrega el mensaje directamente al terminal, en caso contrario lo entrega como correo convencional.	
SAML	Entrega del mensaje en el buzón del destinatario. En caso de estar conectado también lo hace al terminal.	
SEND	Si el destinatario está conectado, entrega el mensaje directamente al terminal.	

Tabla 8.8: Comandos del protocolo SMTP.

Código	Descripción	
211	Estado del sistema.	
214	Mensaje de ayuda.	
220	Servicio preparado.	
221	Servicio cerrando el canal de transmisión.	
250	Solicitud completada con éxito.	
251	Usuario no local, se enviará a <dirección de reenvío>	
354	Introduzca el texto, finalice con <CR><LF>.<CR><LF>.	
421	Servicio no disponible.	
450	Solicitud de correo no ejecutada, servicio no disponible (buzón ocupado).	
451	Acción no ejecutada, error local de procesamiento.	
452	Acción no ejecutada, insuficiente espacio de almacenamiento en el sistema.	
500	Error de sintaxis, comando no reconocido. Si agente es SMTP y se conecta ESMTP	
501	Error de sintaxis en parámetros o argumentos.	
502	Comando no implementado.	
503	Secuencia de comandos errónea.	
504	Parámetro no implementado.	
550	Solicitud no ejecutada, buzón no disponible.	
551	Usuario no local, pruebe <dirección de reenvío>. Si no tiene buzón	
552	Acción de correo solicitada abortada.	
553	Solicitud no realizada (error de sintaxis).	
554	Fallo en la transacción.	

Tabla 8.9: Códigos de respuesta del protocolo SMTP.

Un ejemplo de dialogo donde las líneas del cliente se indican por "C:" y las del servidor por "S:", puede verse a continuación:

S: 220 servicio SMTP bugs.uv.es listo
C: HELO glup.uv.es
S: 250 bugs.uv.es dice hola a glup.uv.es
C: MAIL FROM <profesor@glup.uv.es>
S: 250 transmisor OK
C: RCPT TO: <alumno@bugs.uv.es>
S: 250 receptor OK
C: DATA
S: 354 envía correo; termina con una línea únicamente con”.”
C: From: profesor@glup.uv.es
C: To: alumno@bugs.uv.es
C: MIME-Version: 1.0
C: Message-Id: <0123456789.AA00123@glup.uv.es>
C: Content-Type: multipart/alternative; boundary=abcdef
C: Subject: Mensaje de correo
C:
C: Éste es el preambulo, el agente de usuario lo ignora.
C:
C: --abcdef
C: Content-Type: text/richtext
C:
C: Aquí va el mensaje de correo en texto.
C:
C: --abcdef
C: Content-Type: message/external-body;
C:	access-type=”anon-ftp”,
C:	site=”glup.uv.es”,
C:	directory=”pub”,
C:	name=”mensaje.snd”
C:
C: content-type: audio/basic
C: content-transfer-encoding: base64
C: --abcdef
C: .
S: 250 mensaje aceptado
C: QUIT
S: 221 bugs.uv.es cerrando conexión

La sintaxis de los comandos del cliente se especifica con rigidez. La sintaxis de las respuestas es menos rígida, sólo cuenta el código numérico, pudiendo cada implementación del protocolo SMTP poner la cadena de texto que desee después del código numérico.

Aunque el protocolo SMTP está bien definido por el RFC 821, pueden surgir algunos problemas. Así, algunas implementaciones más viejas no pueden manejar mensajes mayores de 64 Kbytes. Otro problema se relaciona con las terminaciones de temporización. Si el cliente y el servidor tienen temporizaciones distintas, uno de ellos puede terminar mientras que el otro continúa trabajando, terminando inesperadamente la conexión. Por último, en ocasiones pueden dispararse tormentas de correo infinitas. Por ejemplo, si el ordenador 1 contiene la lista de correo A y el ordenador 2 contiene la lista de correo B y cada lista contiene una entrada para la otra lista, entonces un mensaje enviado a cualquiera de las listas generará una cantidad sin fin de correo electrónico.

Para superar algunos de estos problemas, se ha definido el SMTP extendido (ESMTP) en el RFC 1425. Los clientes que deseen usarlo deben enviar un mensaje EHLO, en lugar de HELO. Si el saludo se rechaza, esto indica que el servidor es un servidor SMTP normal (basado en el RFC 821) y el cliente debe proceder de la manera normal. El tipo de protocolo que implementa un agente SMTP o ESMTP lo podemos ver en el código de respuesta a comandos ESMTP, ya que si la contestación a EHLO es 500, nos da a entender que el agente es SMTP y no interpreta ESMTP.

Relaying o intercambiadores de correo.

Dentro de los comandos utilizados para intercambiarse información los servidores de correo, cabe destacar la opción de “relaying” o confiar en otro servidor para atender las peticiones a un servidor de correo, en el momento que este servidor quede fuera de servicio.

En los comandos anteriores, si el servidor de correo no acepta “relaying”, entonces cuando en la entrega, tras “RCPT TO”  se especifica una máquina que no es la propia (por ejemplo el servidor es glup.uv.es y RCTP es para felici@uv.es, otra máquina que no es glup.uv.es), se descarta el mensaje. Por el contrario, si aceptamos intercambiadores, aceptaremos el mensaje de otro servidor (en este caso de uv.es, cuando esté fuera de servicio), al cual cuando esté operativa se le reenviará el correo. Para ello, no requiere habilitarse cuentas de usuario de los otros servidores que se está haciendo intercambio, simplemente se recoge el correo de otra máquina que no recibe el correo y a la cual, posteriormente se le hará entrega. Es decir, se actúa como un intermediario o recogedor, para el caso que falle el servidor.

Pasarelas de correo electrónico.

El correo electrónico usando SMTP funciona mejor cuando el transmisor y el receptor están en Internet y pueden manejar conexiones TCP entre ellos. Sin embargo, muchas máquinas que no están en Internet también quieren transmitir y recibir correo electrónico de instalaciones de Internet. Por ejemplo, muchas compañías intencionadamente no quieren estar en Internet por razones de seguridad. Algunas de ellas incluso se aíslan de Internet levantando muros de seguridad entre ellas mismas e Internet.

Otro problema ocurre cuando el transmisor sólo habla RFC 822 y el receptor sólo habla un protocolo de correo X.400 o alguno patentado, específico del proveedor. Dado que estos dos mundos difieren en cuanto al formato de mensaje y los protocolos, es imposible la comunicación directa.

Ambos problemas se resuelven usando pasarelas de correo electrónico. En la figura siguiente, el ordenador 1 sólo habla TCP/IP y RFC 822, mientras que el ordenador 2 sólo habla TP4 y X.400 de OSI. No obstante, pueden intercambiar correo usando una pasarela de correo electrónico.

Figura 8.6: Esquema de una pasarela de correo electrónico.

El procedimiento usado consiste en que el ordenador 1 establezca una conexión TCP con la pasarela y luego use SMTP para transferir el mensaje a la pasarela. El "daemon" de la pasarela pone el mensaje en el buffer de mensajes destinados al ordenador 2. Después, se establece una conexión TP4 (el equivalente OSI del TCP) con el ordenador 2 y el mensaje se transfiere usando el equivalente OSI del SMTP.

Parece sencillo, pero no lo es. El primer problema es que las direcciones Internet y las direcciones X.400 son diferentes por completo. Se requiere un complejo mecanismo de transformación entre ellas. El segundo problema es que los campos de envoltura y cabecera presentes en un sistema pueden no estar presentes en el otro. Por ejemplo, si un sistema requiere clases de prioridad y el otro no tiene este concepto, en un sentido de envío debe desecharse información valiosa y en el otro sentido debe generarse de la nada.

Un problema más grave es qué debe hacerse si son incompatibles partes del cuerpo. ¿Qué debe hacer una pasarela con un mensaje Internet cuyo cuerpo contiene una referencia a un archivo de sonido que debe ser obtenido mediante FTP si el sistema de destino no maneja este concepto?. ¿Qué debe hacer la pasarela cuando el sistema X.400 le dice que entregue un mensaje a cierta dirección pero, si falla, envíe el contenido por fax?, pues el uso del fax no es parte del estándar RFC 822. Por tanto, para los mensajes de texto ASCII sencillos y sin estructura, las pasarelas son una solución razonable, pero para cualquier cosa más complicada la idea tiende a desmoronarse.

Protocolos de entrega final del correo electrónico.

Hasta ahora hemos visto como envían y reciben las computadoras el correo electrónico a través de SMTP. Sin embargo, en muchas compañías los usuarios trabajan en un PC de escritorio que no está en Internet y que es incapaz de enviar o recibir correo electrónico. Sin embargo, la compañía puede tener uno o más servidores que pueden enviar y recibir correo electrónico.

Para poder recibir el correo electrónico, un PC debe comunicarse con un servidor de correo electrónico usando alguna clase de protocolo de entrega. Generalmente para poder enviar se realizar a través del propio protocolo SMTP. Los protocolos más comunes son:

•	El protocolo POP3 (Post Office Protocol) se define en el RFC 1225. El POP3 tiene comandos para que un usuario establezca una sesión (USER y PASS), la termine (QUIT), obtenga mensajes (RETR) y los borre (DELE). El protocolo mismo consiste en texto ASCII y se asemeja un poco al SMTP. El objetivo del POP3 es obtener correo electrónico del buzón remoto y almacenarlo en la máquina local del usuario para su lectura posterior. Hay versiones actualmente que permiten configurar con POP3 la no descarga del buzón de correo.

•	El protocolo IMAP (Interactive Mail Access Protocol) se define en el RFC 1064. IMAP se diseñó para ayudar al usuario que tiene varias computadoras (una estación de trabajo, un PC, un computador portátil). La idea en que se basa IMAP es que el servidor de correo electrónico mantenga un depósito central al que puede accederse desde cualquier máquina. Por tanto, a diferencia del POP3, el IMAP no copia el correo electrónico en la máquina personal del usuario dado que el usuario puede tener varias.

•	Un tercer protocolo de entrega es DMSP (Distributed Mail System Protocol) que es parte del sistema PCMAIL y se describe en el RFC 1056. Éste no supone que todo el correo está en un servidor, como el POP3 y el IMAP. En cambio, permite a los usuarios descargar correo del servidor a una estación de trabajo, PC o portátil y luego desconectarse. El correo electrónico puede leerse y contestarse estando desconectado. Al ocurrir una reconexión después, el correo electrónico se transferirá y el sistema se sincronizará.

Además de la posibilidad de entregar el correo a un PC, los agentes de transferencia de mensajes poseen herramientas adicionales que permiten establecer filtros. Los filtros son reglas que se consultan cuando llega un correo electrónico o cuando se inicia el agente de usuario. Cada regla especifica una condición y una acción. Por ejemplo, una regla podría indicar que todos los mensajes recibidos de un cliente se resalten en negrita, etc.

Otra característica de los agentes de transferencia es la capacidad de reenviar el correo electrónico entrante a una dirección diferente. Esta dirección puede ser incluso una computadora operada por un sistema localizador comercial, que entonces llama al usuario por radio o satélite, presentando la línea Subject: en su localizador.

Por último, otra característica común es la capacidad de instalar un "daemon" de vacaciones, programa que examina cada mensaje de entrada y envía al transmisor una respuesta como:

Estoy de vacaciones. Regresaré el 15 de Agosto. Que tenga feliz día.

La mayoría de los "daemons" de vacaciones mantienen un registro de a quiénes se enviaron respuestas prefabricadas y se abstienen de enviar a la misma persona una segunda respuesta. Los mejores verifican si el mensaje de entrada se envió a una lista de correo, y de ser así, no envían ninguna respuesta prefabricada.

Listas de distribución

Una lista de correo o distribución es un conjunto de direcciones de correo electrónico junto con un software de control. Recibe un mensaje electrónico y lo retransmite automáticamente a todos aquellos que se hayan suscrito previamente, sin que el remitente tenga que enviar el mensaje a cada uno de ellos por separado, o mantener un fichero con las direcciones de todos los destinatarios. Solo necesita el nombre de la lista, enviar un único mensaje a la lista, y el servidor ya se encarga de distribuirlo.

La finalidad básica de una lista de correo es permitir una comunicación rápida y facil entre un grupo de personas; de cada uno de ellos a todos los demás. En general no se pretende que sea una via para que un usuario distribuya mensajes a un grupo de direcciones, que se limitan a recibirlos (aunque puede haber listas así configuradas para temas específicos), sino que todos puedan enviar mensajes a los demás, así como recibir los de ellos. 

La lista tiene un nombre (dirección electrónica, en realidad) y en ella se trata una determinada temática (el nombre de la lista suele escogerse para que de una idea de la temática de que trata). Un usuario puede suscribirse a la lista y, a partir de ese momento, los mensajes que envía a la lista son recibidos por un servidor, el cual los distribuye a todos los demás miembros de la lista. La distribución de los mensajes, el alta y baja de usuarios, etc. son gestionados por el software de la lista (probablemente con ayuda ocasional de la persona responsable de la lista). Adicionalmente dicho software suele proporcionar una serie de utilidades adicionales, como pueden ser: 

•	proporcionar información sobre la temática, difusión de la lista, y sobre los suscritos a ella. 
•	control (más o menos amplio) de acceso a la lista: quien puede o no suscribirse a la lista, quien puede enviar mensajes a ella, etc. 
•	archivar automáticamente los mensajes enviados a la lista, y proporcionar algún medio de acceso a ellos para referencia futura. Algunos de los productos proporcionan un interfaz web para acceder a los archivos, incluso con capacidades de realizar búsquedas selectivas en ellos. 
Existen diversos paquetes de software de gestión de listas de correo. En la Universitat de València se instaló el Majordomo (Julio 1997, vers. 1.94.3). Desde principios del 2000 se utiliza el software LISTSERV, el cual posee características superiores al anterior (en cuanto a rendimiento y facilidad de uso).

Los agentes de usuario.

Hemos visto hasta ahora los agentes de transferencia de correo. Veremos a continuación los agentes de usuario.

Un agente de usuario es normalmente un programa que acepta una variedad de comandos para componer, recibir y contestar los mensajes, así como para manipular los buzones de correo. Algunos agentes de usuario tienen una interfaz elegante operada por menús o por iconos que requieren el uso de un ratón, mientras que otros esperan comandos de un carácter desde el teclado. Funcionalmente, todos son iguales.

La labor de un agente de usuario puede dividirse, para su estudio, en su capacidad de procesar y enviar correo electrónico y su capacidad de recibir el mismo.

Envío de correo electrónico.

Para enviar un mensaje de correo electrónico, el usuario debe proporcionar el mensaje, la dirección de destino y, posiblemente, algunos otros parámetros (por ejemplo, prioridad o nivel de seguridad). El mensaje puede producirse con un editor de textos independiente, un programa de procesamiento de textos o, posiblemente, un editor de textos incorporado en el agente de usuario. La dirección de destino debe estar en un formato que el agente de usuario pueda manejar. La mayoría de agentes de usuario esperan direcciones DNS de la forma buzón_de_correo@ubicación. Sin embargo, las direcciones X.400 tienen un aspecto radicalmente diferente del de las direcciones DNS. Las direcciones X.400 se componen de pares atributo=valor, por ejemplo:

/C=US/SP=MASSACHUSETTS/L=CAMBRIDGE/PA=360 MEMORIAL DR./CN=KEN SMITH/

Esta dirección especifica un país, estado, localidad, dirección personal y nombre común. Son posibles muchos otros atributos, de modo que puede enviarse correo electrónico a alguien cuyo nombre no se conoce, siempre y cuando se conozca un número suficiente de los otros atributos (por ejemplo, compañía y puesto). Esta forma de nombrar es menos funcional que los nombres DNS, sin embargo, los diseñadores de X.400 supusieron que la gente usaría alias (cadenas cortas asignadas por el usuario) para identificar a los destinatarios, por lo que nunca verían direcciones completas. Sin embargo, el software necesario nunca estuvo ampliamente disponible, por lo que la gente que enviaba correo a los usuarios con direcciones X.400 tenía que escribir cadenas como la anterior.

La mayoría de sistemas de correo electrónico manejan listas de correo, por lo que un usuario puede enviar el mismo mensaje a un grupo de personas con un solo comando. Si la lista de correo se mantiene localmente, el agente de usuario puede enviar un mensaje por separado a cada destinatario. Sin embargo, si la lista se mantiene remotamente, entonces los mensajes se multiplicaran en la maquina remota.

Lectura de correo electrónico.

Por norma general, al arrancar un agente de usuario, éste buscará en el buzón del usuario el correo electrónico recibido antes de presentar cualquier otra cosa en la pantalla. Entonces puede anunciar la cantidad de mensajes en el buzón o presentar un resumen de una línea de cada uno y esperar un comando.

Existen incontables programas de correo electrónico, cada uno con sus interfaces propias, etc. Como norma general, todos ellos constan de una serie de comandos o iconos de interfaz que permiten leer el correo, responder al mismo, etc. No parece conveniente, dada la sencillez de los mismos dedicar líneas a describirlos.

Formato de los buzones: mailbox V7

Mientras el correo se guarda en el buzón del usuario a la espera de la entrega final, se utiliza un formato determinado en la propia máquina servidora. El más frecuente es separar los diferentes correos con una línea empezando por “From “ y si se repite en el interior del texto, entonces se introduce el prefijo “>”.  Este formato es conocido por V7 Mailbox, por ser una convención en Unix Version 7. Existen otros formatos como BABYL, MMDF, MH y QMAIL MAILDIR

Seguridad en el correo

Inicialmente, la seguridad no estaba incluida en Internet, pues el objetivo era extenderse en un ámbito de investigadores y universidades. •Actualmente los temas de seguridad son importantes, ya que muchos impresentables hacen uso incorrecto de los servicios de Internet. Por ello, el intercambio de contraseñas entre clientes y servidores que se realiza en modo texto, así como el correo,...deben protegerse.

Estos temas (PGP, PEM, SSMTP, POP3s etc) los retomaremos en el capítulo de seguridad. Son en definitiva, aspectos que integran la seguridad en estos protocolos. También es aconsejable instalar antivirus y que inspeccionen los buzones de correo, para evitar la propagación de virus entre usuarios.

8.2.3 Formato de los mensajes.

Pasemos ahora al formato de los mensajes de correo electrónico. Primero veremos el correo electrónico ASCII básico usando el RFC 822, viendo posteriormente las extensiones multimedia del mismo.

RFC 822.

Los mensajes con formato RFC 822 están formados por una envoltura primitiva (descrita en el RFC 821), algunos campos de cabecera, una línea en blanco, y el cuerpo del mensaje. Cada campo de cabecera consiste en una sola línea de texto ASCII que contiene el nombre del campo, dos puntos (:) y, para la mayoría de los campos un valor. Los principales campos de cabecera de cabecera son:

Cabecera	Descripción	
To:	Direcciones de email de los destinatarios primarios.	
Cc:	Direcciones de email de los destinatarios secundarios. En términos de entrega no existe diferencia con los destinatarios primarios.	
Bcc:	Direcciones de email de las copias al carbón ciegas. Es como el campo anterior excepto que esta línea se borra de todas las copias enviadas a los destinatarios primarios y secundarios.	
From:	Persona o personas que crearon el mensaje.	
Sender:	Dirección de correo del remitente. Puede omitirse si es igual al campo anterior.	
Received:	Línea agregada por cada agente de transferencia en la ruta. La línea contiene la identidad del agente, la fecha y hora de recepción del mensaje y otra información que puede servir para detectar fallos en el sistema de enrutamiento. Esta cabecera se va apilando en los emails a medida que el mensaje va saltando entre los diferentes servidores de correo por los que transcurre el correo.	
Return-Path:	Puede usarse para identificar una trayectoria de regreso al remitente.	

Tabla 8.10: Campos de cabecera de RFC822.

Además de los campos anteriores, los mensajes RFC 822 pueden contener una variedad de campos de cabecera usados por los agentes de usuario o los destinatarios. Los más comunes son:

Cabecera	Descripción	
Date:	Fecha y hora de envío del mensaje.	
Reply-To:	Se usa cuando la persona que escribió el mensaje y la que lo envió no desean ver la respuesta.	
Message-Id:	Número único para referencia posterior a este mensaje. Este campo tiene un formato que incluye un número y la dirección de correo completa de quien manda el mensaje.	
In-Reply-To:	Identificador del mensaje al que éste corresponde.	
References:	Otros identificadores de mensaje.	
Keywords:	Claves seleccionadas por el usuario.	
Subject:	Resumen corto del mensaje para exhibir en una línea.	

Tabla 8.11: Campos de cabecera auxiliares de RFC822.

El RFC 822 explícitamente indica que los usuarios pueden inventar cabeceras nuevas para uso privado siempre y cuando comiencen con la cadena X-. Se asegura que no habrá cabeceras futuras que usen nombres que comiencen con X-.

MIME- Extensiones multipropósito de correo Internet.

Al comienzo de Internet, el correo consistía exclusivamente en mensajes de texto escritos en inglés y expresados en ASCII. En ese entorno, el RFC 822 hacía todo el trabajo. Sin embargo, hoy día, la red Internet presenta problemas a esa restricción, problemas que incluyen:

•	Mensajes en idiomas con acentos (español, francés y alemán).
•	Mensajes en alfabetos no latinos (hebreo y ruso).
•	Mensajes en idiomas sin alfabetos (chino y japonés).
•	Mensajes que no contienen texto (audio y vídeo).

Se propuso una solución en el RFC 1341 y se actualizó en el RFC 1521. Esta solución, llamada MIME (Multipurpose Internet Mail Extensions) se usa ampliamente.

Cabe destacar que MIME no afecta al protocolo SMTP si no a los clientes de correo.

La idea básica de MIME es continuar usando el RFC 822, pero agregar una estructura al cuerpo del mensaje y definir reglas de codificación para los mensajes no ASCII. Al no desviarse del RFC 822, los mensajes MIME pueden enviarse usando los programas y protocolos de correo electrónico existentes. Todo lo que tiene que cambiarse son los programas transmisores y receptores. MIME define cinco nuevas cabeceras de mensaje, como puede verse en la tabla siguiente:

Cabecera	Descripción	
MIME-Version:	Identifica la version de MIME. Si no existe se considera que el mensaje es texto normal en inglés.	
Content-Description:	Cadena de texto que describe el contenido. Esta cadena es necesaria para que el destinatario sepa si desea descodificar y leer el mensaje o no.	
Content-Id:	Identificador único, usa el mismo formato que la cabecera estándar Message-Id.	
Content-Transfer-Encoding:	Indica la manera en que está envuelto el cuerpo del mensaje.	
Content-Type:	Especifica la naturaleza del cuerpo del mensaje.	

Tabla 8.12: Formatos de cabecera MIME.

Veamos más detenidamente las dos últimas cabeceras enumeradas en la tabla anterior.

El Content-Transfer-Encoding indica la manera en que está envuelto el cuerpo para su transmisión a través de una red donde se podría tener problemas con la mayoría de los caracteres distintos de letras, números y signos de puntuación. Existen cinco tipos de codificación de los mensajes conocidos con el nombre de esquemas:

1.	El esquema más sencillo es simplemente texto ASCII. Los caracteres ASCII usan 7 bits y pueden transmitirse directamente mediante el protocolo de correo electrónico siempre y cuando ninguna línea exceda de 1000 caracteres.

2.	El siguiente esquema más sencillo es lo mismo, pero usando caracteres de 8 bits, es decir, todos los valores de 0 a 255. Este esquema de codificación viola el protocolo original del correo electrónico de Internet, pero es usado por algunas partes de Internet que implementan ciertas extensiones al protocolo original. Mientras que la declaración de la codificación no la hace legal, hacerla explícita puede cuando menos explicar las cosas cuando algo sucede mal. Los mensajes que usan codificación de 8 bits deben adherirse a la longitud máxima de línea estándar.

3.	Los mensajes que usan codificación binaria. Éstos son archivos binarios arbitrarios que no sólo utilizan los 8 bits, sino que ni siquiera respetan el límite de 1000 caracteres por línea. Los programas ejecutables caen en esta categoría. No se da ninguna garantía de que los mensajes en binario llegarán correctamente.

4.	La manera correcta de codificar mensajes binarios es usar codificación base64, a veces llamada armadura ASCII. En este esquema, se dividen grupos de 24 bits en unidades de 6 bits, enviándose cada unidad como carácter ASCII legal. La codificación es ‘A’ para 0, ‘B’ para 1, etc., seguidas por las 26 letras minúsculas, los 10 dígitos y, por último, + y / para los valores 62 y 63 respectivamente. Las secuencias == y = se usan para indicar que el último grupo contenía solo 8 o 16 bits, respectivamente. Los retornos de carro y avances de línea se ignoran, por lo que pueden introducirse a voluntad para mantener la línea lo suficientemente corta.

5.	En el caso de mensajes que son casi completamente ASCII, pero con algunos caracteres no ASCII, la codificación base64 es algo ineficiente. En cambio, se puede usar una codificación conocida como codificación entrecomillada-imprimible. Ésta codificación es ASCII de 7 bits, con todos los caracteres por encima de 127 codificados como un signo de igual seguido del valor del carácter en dos dígitos hexadecimales.

Veamos a continuación un ejemplo de codificación base64. Supongamos que deseamos enviar el siguiente fragmento de código binario de un programa:

	214	04	23	97	08	200	
Binario	11010110	00000100	00010111	01100001	00001000	11001000	

Dividimos cada grupo de 24 bits en grupos de 6 bits, con lo que resultan lo grupos de seis bits siguientes:

110101	100000	010000	010111	011000	010000	100011	001000	

Calculando ahora su valor decimal y teniendo en cuenta la codificación en caracteres descrita con anterioridad:

53	32	16	23	24	16	35	8	
0	f	P	W	X	P	i	H	

Por lo cual el mensaje de correo que enviaríamos seria: 0fPWXPiH

El Content-Type especifica la forma del cuerpo del mensaje. Existen siete tipos definidos en el RFC 1521, cada uno de los cuales tiene uno o más subtipos. El tipo y el subtipo se separan mediante un carácter diagonal (/), como:

Content-Type: video/mpeg

El subtipo debe indicarse explícitamente en la cabecera; no se proporcionan valores predeterminados. La lista inicial de tipos y subtipos especificada por el RFC 1521 puede verse en la tabla siguiente. Se han agregado muchos otros desde entonces y se agregan nuevas entradas a medida que surge la necesidad.

Tipo	Subtipo	Descripción	
Text	Plain	Texto sin formato.	
	Richtext	Texto con comandos de formato sencillos.	
Image	Gif	Imagen fija en formato GIF.	
	Jpeg	Imagen fija en formato JPEG.	
Audio	Basic	Sonido.	
Video	Mpeg	Película en formato MPEG.	
Application	Octet-stream	Secuencia de bytes no interpretada.	
	Postscript	Documento imprimible PostScript.	
Message	Rfc822	Mensaje MIME RFC 822.	
	Partial	Mensaje dividido para su transmisión.	
	External-body	El mensaje mismo debe obtenerse de la red.	
Multipart	Mixed	Partes independientes en el orden especificado.	
	Alternative	Mismo mensaje en diferentes formatos.	
	Parallel	Las partes deben verse simultáneamente.	
	Digest	Cada parte es un mensaje RFC 822 completo.	

Tabla 8.13: Tipos y subtipos del formato MIME.

Repasemos la lista de tipos. El tipo text es para texto normal. La combinación text/plain es para mensajes ordinarios que pueden visualizarse como se reciben, sin codificación ni ningún procesamiento posterior. Esta opción permite el transporte de mensajes ordinarios en MIME con sólo unas pocas cabeceras extra.

El subtipo text/richtext permite la inclusión de un lenguaje de marcación sencillo en el texto. Este lenguaje proporciona una manera independiente del sistema para indicar negritas, cursivas, tamaños en puntos menores y mayores, sangrías, etc. El lenguaje de marcación se basa en el SGML (Standard Generalized Markup Language), también usado como base del HTML usado en el Web.

El siguiente tipo MIME es image, que se usa para transmitir imágenes fijas. Hoy día se usan muchos formatos para almacenar y transmitir imágenes, tanto con compresión como sin ella. Dos de estos, gif y jpeg son subtipos oficiales.

Los tipos audio y video son para sonido e imágenes en movimiento, respectivamente. Nótese que video sólo incluye la información visual, no la pista de sonido. Si se debe transmitir una película con sonido, tal vez sea necesario transmitir las partes de vídeo y de audio por separado, dependiendo del sistema de codificación usado.

El tipo application es un tipo general para los formatos que requieren procesamiento externo no cubierto por ninguno de los otros tipos. Un octet-stream simplemente es una secuencia de bytes no interpretados. A la recepción de una de tales secuencias, un agente de usuario debería presentarla en la pantalla sugiriendo al usuario que se copie en un archivo y solicitando un nombre de archivo. El otro subtipo definido es postscript, que se refiere al lenguaje PostScript producido por Adobe Systems y usado por muchas páginas impresas. Aunque un agente de usuario puede llamar a un intérprete PostScript externo para visualizar los archivos PostScript entrantes, hacerlo no está exento de riesgos al ser PostScript un lenguaje de programación completo, lo cual permite que alguien, además de exhibir texto, pueda leer, modificar o borrar los archivos del usuario y tener otros efectos secundarios desagradables.

El tipo message permite que un mensaje esté encapsulado por completo dentro de otro. Este esquema es útil para reenviar, por ejemplo, correo electrónico. Cuando se encapsula un mensaje RFC 822 completo en un mensaje exterior, debe usarse el subtipo rfc822. El subtipo partial hace posible dividir un mensaje encapsulado en pedazos y enviarlos por separado. Los parámetros hacen posible ensamblar correctamente todas las partes en el destino. Por último el subtipo external-body puede usarse para mensajes muy grandes, por ejemplo películas de vídeo. En lugar de incluir el archivo mpeg en el mensaje, se da una dirección de FTP y el agente de usuario del receptor puede obtenerlo a través de la red cuando se requiera.

El último tipo es multipart, que permite que un mensaje contenga más de una parte, con el comienzo y el fin de cada parte claramente delimitados. El subtipo mixed permite que cada parte sea diferente. En contraste, el subtipo alternative indica que cada parte contiene el mismo mensaje, pero expresado en un medio o codificación diferente. El subtipo parallel se usa cuando todas las partes deben “verse” simultáneamente. Por ejemplo, las películas con frecuencia tienen un canal de audio y un canal de vídeo. Por último, el subtipo digest se usa cuando se juntan muchos mensajes en un mensaje compuesto.

Veamos un ejemplo de mensaje MIME:

From: profesor@glup.uv.es
To: alumno@bugs.uv.es
MIME-Version: 1.0
Message-Id: <0123456789.AA00123@glup.uv.es>
Content-Type: multipart/alternative; boundary=abcdef
Subject: Mensaje de correo

Éste es el preambulo, el agente de usuario lo ignora.

--abcdef
Content-Type: text/richtext

Aquí va el mensaje de correo en texto.

--abcdef
Content-Type: message/external-body;
	access-type=”anon-ftp”,
	site=”glup.uv.es”,
	directory=”pub”,
	name=”mensaje.snd”

content-type: audio/basic
content-transfer-encoding: base64
--abcdef

8.3 SNMP: Simple Network Management Protocol

8.3.1 Introducción

Es una aplicación para analizar el estado de los dispositivos de la red, permitiendo su manejo (configuración) y monitorización, con lo cual permite diagnosticar problemas existentes. Antiguamente en ocasiones de un mal funcionamiento de la red se utilizaba ping y traceroute, pero la información suministrada por este comando es muy limitada para detección de problemas.

La administración de redes gira entorno al concepto de MIB.  Un MIB es una base de datos estructurada de información que esta físicamente localizada en un dispositivo de red.   El acceso a esta información lo proporciona el protocolo denominado SNMP (Simple Network Management Protocol).  Un subconjunto de esta base de datos, es el MIB-2.  Esto es una base de datos con información común que está soportada por todos los dispositivos de red.

8.3.2  Estándares de la estructura de la información de administración

El SMI (Structure of Management Information) presenta una estructura en forma de árbol global para la información de administración, convenciones, sintaxis y las reglas para la construcción de MIBs. 

Un MIB es una base de datos que contiene información que caracteriza los aspectos funcionales y operacionales de un dispositivo de red.  Los MIBs contienen objetos que necesitan ser gestionados para controlar un dispositivo. Estos objetos se pueden considerar como variables a controlar en cada dispositivo y cada variable refleja un estado o información del dispositivo, como por ejemplo si está o no conectado, el número de errores, tamaño de las colas, etc.

Actualmente existen gran variedad de MIBs.  Algunos son específicos de un fabricante y otros muchos son comunes.  Los MIBs comunes (por ejemplo:  MIB-2, RMON y RMON2 ) son muy importantes en la administración de redes.  Proporcionan una serie de objetos que son soportados por la mayoría de dispositivos, dando al administrador una importante herramienta para el control de dispositivos independientemente del fabricante.

Todos lo objetos de un MIB poseen un identificador único (OID).  Este identificador está formado por, enteros separados por puntos o bien etiquetas o bien de forma mixta, como se identifica en el árbol SMI, como se ve en la figura.  Se necesita conocer el OID de un objeto si se pretende acceder a este objeto dentro de un MIB.   El árbol global de objetos es completamente extensible a nuevos MIBs, ya que existen infinidad de ramas que pueden ser añadidas por debajo de ciertas ramas (privadas o experimentales) designadas por el IETF.  Esta estructura proporciona un código de identificación que es único para cada rama. Ejemplo: iso.org.dod.internet.mgmt.mib_2.interfaces, ó 1.3.6.1.2.1.2.

ccitt (0)		iso (1)		itu (2)		joing-iso-ccitt (3)

Standard (0)	registration-authority (1) 	member-body (2)		identified-organization Org (3)

Dod (6)

Internet (1)

Directory (1)	Mgmt (2)	experimental (3) 	private (4)	security (5)	snmpv2 (6)

Mib_2 (1)

System (1) 	interfaces (2)	addr-traslation (3) 	ip (4)	icmp (5)	tcp(6)	udp (7) 	egp (8) 

Figura 8.7: Árbol SMI global estructurado para sintaxis y convenciones

Como podemos observa, la raíz del árbol SMI  (iso(1).org(3).dot(6).internet(1).mgmt(2) o 1.3.6.1.2) es usado repetidamente en los OIDs dentro de SNMP, por lo que a menudo se define como el prefijo principal de todos los objetos del MIB. Esto es así, porque las variables o objetos manejados por SMNP en la administración de equipos en Internet, caen debajo de esta rama del árbol.

8.3.3  El estándar SNMP

SNMP  es el protocolo de administración que facilita la comunicación entre la estación administradora  y el agente de un dispositivo de red.   SNMP se puede implementar usando comunicaciones UDP o TCP, pero por norma general, se suelen usar comunicaciones UDP en la mayoría de los casos.  Con UDP,  el protocolo SNMP se implementa utilizando los puertos 161 y 162.  El puerto 161 se utiliza para las transmisiones normales de comando SNMP, mientras que el puerto número 162 se utiliza para los mensajes de tipo “trap”.

El modelo subyacente del SNMP es una estación administradora que envía solicitudes a los agentes de nodos administrados, haciendo consultas sobre cualquiera de las variables o objetos del MIB.  Veremos ahora el protocolo mismo al que le hablan la estación administradora y los agentes. 

La forma normal de uso del SNMP es que la estación administradora envíe una solicitud a un agente pidiéndole información o mandándole actualizar su estado de cierta manera.   Idealmente, la respuesta del agente simplemente es la información solicitada o la confirmación de que ha actualizado su estado según se solicitó.  Los datos se envían empleando la sintaxis de transferencia del ASN.1. Es un formato para representación de los datos para ínter actuación de diferentes fabricantes.  Sin embargo, también pueden informarse varios errores, como “no existe tal variable”.

El SNMP proporciona un acceso remoto a todos los objetos soportados por un dispositivo de red.  Este protocolo facilita el muestreo del dispositivo con el objetivo de chequear los posibles estados en los que se encuentra este, recoger características operacionales, y recibir notificaciones sobre eventos producidos por algún cambio importante en el dispositivo. El SNMP fue definido para ser un protocolo simple, con el objetivo de obtener una amplia y rápida aceptación.  En un principio fue así, pero posteriores versiones han complicado el protocolo a cambio de conseguir mejores prestaciones en diversos aspectos.

Todos los datos SNMP siguen la estructura de los MIBs  definidos mediante el SMI.  Actualmente, los datos que se envían a través del cable están codificados en un subconjunto de la ASN.1 (Abstract Syntax Notation One).

8.3.4 El estándar MIB-2

Este es el MIB más importante para SNMP.  El MIB-2 está ampliamente expendido dentro de Internet, ya que proporciona un importante conjunto de posibilidades para una gran variedad de dispositivos diferentes.

MIB-2

Cuando un dispositivo de red soporta el MIB-2, permite tener acceso a una colección de datos de administración comunes y de gran utilidad. Cuando se tiene un conjunto discreto de diversos dispositivos que soportan el MIB-2, se tiene acceso al mismo conjunto de datos de administración en todos los dispositivos.  Esto es importante, ya que permite tratar idénticamente los diferentes dispositivos, sin importar de qué dispositivo se trate.

Por ejemplo, MIB-2 proporciona los contadores necesarios para calcular  la utilización de una red Ethernet o Token Ring.  La utilización proporciona  una medida del porcentaje de tiempo durante el que un  recurso es utilizado dentro de un cierto intervalo de tiempo dado.   Esto permite que una aplicación de administración obtenga la utilización de un determinado dispositivo X, seguidamente calcule la utilización de un dispositivo Y, consiguiendo así obtener una serie de estadísticas que van a facilitar la comparación entre estos dos dispositivos.  Debido a que las redes suelen estar compuestas por dispositivos de diferentes fabricantes, la obtención de características de este tipo, va a permitir tomar una serie de decisiones importantes en algunos casos.

Leyendo un MIB

El SMI proporciona las reglas básicas y convenciones usadas para definir el MIB y la estructura de los identificadores de los objetos utilizables.  Estos objetos están formados por los siguientes campos:

•	Nombre (usando la convención del SMI)
•	Tipo de dato ( puede ser un entero, texto, cadena, etc.)
•	Descripción (explicación del contenido)
•	Acceso al objeto (si es posible acceso de lectura o escritura)
•	Identificador del objeto (identificador único dentro del árbol de objetos)

Determinando el identificador de un objeto

El identificador de un objeto es necesario para acceder y cambiar el valor de un objeto en el caso que se pueda escribir sobre él.  El siguiente código extraído del MIB-2 muestra la sintaxis basada en el SMI usada para representar el objeto sysDescr (objeto que contiene una descripción del sistema en el que se encuentra) y la posición de sysDescr dentro del árbol global del MIB. El identificador de sysDescr es 1.3.6.1.2.1.1.1.  como podemos comprobar en el árbol SMI contiene referencias a otros MIBs que proporcionan información externa a este fichero.  De esta simple forma es posible identificar cualquier objeto del árbol conociendo las ramas de las que procede. 

Por tanto, a partir del árbol de objetos, deducimos que el identificador de sysDescr  es el siguiente:
Iso=1
Org=3
Dod=6
Internet=1
Mgmt=2
Mib-2=1
System=1
SysDescr=1

Con lo que obtenemos el identificador que estábamos buscando.

Adicionalmente, cada objeto dentro de un dispositivo, incluye atributos. Por tanto, el resto de la definición de sysDescr, se completa y vendría dado a través de otros atributos de objetos. 

Atributos de objetos

Estos atributos son: 

	SYNTAX:  indica el tipo de dato del objeto.  En este caso, el objeto sysDescr es un DisplayString,  definido en el SMI como una cadena de texto de 0 a 255 caracteres. Existen muchos otros tipos de datos definidos en SMI como veremos.

	ACCESS:  para sysDescr es solo lectura.  Esto significa que el objeto solamente puede ser leído, pero no escrito por la estación administradora.  Los diferentes tipos de acceso son:  read-only, read-write, write-only, o not-accessible para objetos que existen dentro del agente pero que no son accesibles externamente. 	

	STATUS: describe la versión de SNMP para administrar dicho objeto.

	DESCRIPTION:  proporciona una descripción textual del objeto.  En el caso de sysDescr,  la descripción nos dice que el objeto contiene la descripción del sistema que contiene al dispositivo

Tipo de datos comunes

	El SMI proporciona un gran número de tipos de datos, aunque en la mayoría de las ocasiones se utilizan un número reducido de estos.   Estos tipos de datos más comunes son:

•	Integer:  	número entero, positivo o negativo, limitado a una precisión de 32 bits.
•	Octec String:  secuencia ordenada de 0 o más octetos.
•	Display String: un octet string que contiene cualquier carácter ASCII
•	Object Identifier: un identificador único en el árbol MIB, definido oficialmente
•	Object Descriptor: forma textual imprimible de un OID.  Mientras un OID es un array de enteros, el object descriptor es un string del array de enteros separados por puntos decimales.
•	Sequence:  es un grupo de 1 o más objetos ordenados, almacenados como una fila en una tabla.
•	Ipaddress:  Es una dirección IP de 32 bits representada por 4 bytes
•	Counter:  entero positivo que se incrementa hasta alcanzar el valor máximo.  Una vez alcanzado, si se vuelve a incrementar, toma el valor 0.
•	Gauge:  es un entero positivo que puede incrementarse o decrementarse.  Cuando se alcanza el valor máximo, este se mantiene hasta que no se decremente.  Es decir que no vuelve al valor 0.
•	TimeTicks:  entero positivo que cuenta el tiempo en centésimas de segundo.

Areas funcionales del MIB-2

Por conveniencia, los objetos administrados por SNMP se agrupan en categorías, que se localizan bajo la rama de Mib_2 en el árbol SMI. Los objetos que están dentro del MIB-2 están agrupados en una serie de ramas, en función de un conjunto de características comunes.   Los objetos que pertenecen a cada uno de estos grupos se caracterizan por un prefijo y un identificador que indican a qué grupo pertenecen.  Por ejemplo, todos los objetos dentro del grupo system tienen el prefijo “sys”.

Una breve descripción de cada uno de estos grupos y de algunas de sus componentes más destacadas:

1.	System:  (prefijo “sys”)Contiene información general sobre el dispositivo. Muchos de los objetos son configurables por el administrador.  Los objetos que lo forman son:

•	SysDescr: descripción textual del dispositivo.
•	SysObjectID: indica una identificación especifica del vendedor
•	SysUpTime: es el tiempo en centésimas de segundo, desde que el dispositivo fue arrancado.
•	SysContact:  es un campo que puede contener el nombre de la persona responsable del dispositivo.
•	SysName:  define un nombre para el dispositivo dentro de la red.
•	SysLocation:  define donde esta localizado el dispositivo
•	SysServices: es un entero de indica que niveles de red soporta el dispositivo.

2.	Interfaces: (prefijo “if”) Contiene una fila de información sobre los enlaces del dispositivo y una cuenta de estas filas.  Algunos de los objetos más importantes que contiene este grupo son la velocidad del enlace (ifSpeed), el tipo de enlace (ifType), el estado operacional del enlace (ifOperStatus), y una serie de contadores de errores.  Este grupo es crítico cuando se maneja un dispositivo que posea diferentes enlaces.
3.	IP: (prefijo “ip”) Contiene información útil para manejar el dispositivo en el nivel 3 (nivel de red).  El ipRouteTable  contiene información para determinar como enrutar paquetes, (como por ejemplo, destino del enrutado, varias medidas de enrutado, y el protocolo de enrutado).
4.	ICMP: (prefijo “icmp”) Contiene información para monitorizar el protocolo ICMP (contadores de paquetes, contadores de errores, etc.)
5.	TCP:  (prefijo “tcp”)  Contiene información importante para monitorizar el protocolo TCP.  Una tabla importante contenida dentro de este grupo es la tabla de conexiones (tcpConnTable).  Esta tabla contiene mapeado de direcciones y de puertos y el estado de la conexión (por ejemplo: cerrada o establecida).
6.	UDP: (prefijo “udp”) contiene información sobre el protocolo UDP, como contadores de paquetes y de errores.
7.	EGP: (prefijo “egp”) Contiene información sobre este protocolo usado para el intercambio de información de enrutado entre routers.
8.	Transmission: (prefijo “transmission”) Realmente esto no es un grupo, ya que es un nodo de posición en el árbol MIB-2.  Para cada transmisión estándar, existe un subárbol de administración MIB.  Por ejemplo existen subárboles para FDDI, Token Ring, y Ethernet.
9.	SNMP: (prefijo “snmp”) Contiene información sobre SNMP como paquetes entrantes, salientes y un  número de errores.

Ejemplo: sysName, como hemos visto nos informa del nombre del sistema y se puede ser alcanzado por 1.3.6.1.2.1.1.5.

VARIABLES MÁS IMPORTANTES del MIB-2 DENTRO DEL AREA FUNCIONAL INTERFACE

Son las variables que tienen una mayor relevancia dentro del MIB-2.   Como hemos comentado en anteriores ocasiones, el MIB-2 posee cientos de variables, pero en la práctica, únicamente nos van a importar un grupo limitado de estas. Una breve descripción del objetivo de cada una de estas variables las vemos en la siguiente table:

IfAdminStatus:	Se utiliza para cambiar el estado operacional de un enlace.   Unicamente es accesible por el administrador de la red.
	
IfOperStatus:	Nos indica el estado operacional de un determinado enlace.	
IfInErrrors:	Nos indica el número de paquetes entrantes en los que el agente ha      encontrado algún tipo de error	
IfInDiscards:	El número de paquetes entrantes que el agente ha seleccionado para ser eliminados.  No necesariamente son solo los que contienen errores.   Una razón 	para eliminar paquetes suele ser liberar espacio en los buffers de entrada.
	
IfInOctets:	Indica el número total de octetos recibidos en el enlace.
	
IfOutErrors:	Indica el número total de paquetes que no han podido ser enviados por 	causa de un error.	
IfOutDiscards:	El número de paquetes salientes que el agente ha seleccionado para ser eliminados.  Además de aquellos que contienen algún error, también se eliminan para liberar espacio en los buffers de salida.
	
IfOutOctets:	El número total de octetos transmitidos fuera del enlace.	
IfSpeed:	Nos da una estimación del ancho de banda actual que dispone el enlace en bits por segundo.  En aquellos enlaces en los que el ancho de banda no varíe o en los 	que no sea posible hacer una aproximación exacta, este objeto suele contener el ancho de banda nominal.

Tabla 8.14: Objetos del área funcional Interfaz

8.3.5 Mensajes SNMP

El SNMP define siete mensajes que pueden enviarse.   Los seis mensajes de un iniciador se listan en la tabla siguiente (el séptimo mensaje es el de respuesta).

Get_request	Solicita el valor de una o más variables	
Get_next_request	Solicita el valor de la variable que sigue a esta.	
Get_bulk_request	Obtiene una tabla grande	
Set_request	Actualiza una o más variables	
Inform_request	Mensaje de administrador a administrador describiendo la MIB local	
Snmp_v2_trap	Informe de interrupciones de agente a administrador.	

Tabla 8.15: Mensajes SNMP

Los tres primeros mensajes solicitan la devolución de valores de variables.   El primer formato nombra explícitamente las variables que quiere. En el caso de que se pida más de una variable, se deberá construir una lista, que contenga las variables solicitadas.  La construcción de esta lista debe seguir unas normas comunes al agente y a la estación, para que sea posible la comunicación y el entendimiento entre ambos.   El segundo solicita la siguiente variable, permitiendo al administrador ir paso por paso a través de la MIB en orden alfabético (la predeterminada es la primera variable).   El tercero es para transferencias grandes con tablas.
	Los siguientes mensajes permiten al administrador actualizar las variables de un agente, hasta el límite permitido por la especificación del objeto, claro está.  Sigue una solicitud informal que permite a un administrador indicarle a otro las variables que está manejando.   Por último, viene el mensaje enviado de un agente a un administrador cuando ha habido una interrupción.

Actualmente existen 2 versiones del protocolo SNMP (aunque ya se está empezando a extender la tercera).  Seguidamente voy a exponer brevemente algunas de las particularidades más destacadas de cada versión.  

EJEMPLO de CONSULTA SNMP: snmpget(): cálculo de utilización de una interface de un enlace serie

En primer lugar, la consulta debe ir precedida por el comando que se quiere ejecutar.   En nuestro caso, vamos a utilizar el comando snmpget, ya que es el idóneo para preguntar por una serie limitada de variables conocidas. 

El primer parámetro que posee este comando es el identificador de la máquina que se desea consultar.   Como identificador se pude usar tanto el nombre como la dirección IP.   Seguidamente debemos colocar la comunidad a la que pertenecen las variables a consultar.  Este campo se utiliza para restringir el acceso a determinada información.   Por norma general, la comunidad más utilizada es “public”.

Y finalmente se colocan los identificadores de los objetos que se desea consultar.   Estos identificadores siguen la notación SMI vista anteriormente.  

Para calcular la utilización de un enlace, debemos seguir los siguientes pasos. La utilización de un enlace viene determinada tanto para la utilización del interface entrante y la utilización del interface saliente en un router. Por tanto la utilización de un interface se define como:  

(numero de bits procesados)/((tiempo que ha tardado)*velocidad)

es decir los bits mandados, frente a los bits que hubiese podido mandar si la utilización hubiese sido de 1. En este caso, las variables a procesar serían ifInOctets, ifOutOctets y ifSpeed como se ha visto anteriormente.

Los valores de estas variables son incrementales, es decir, que su valor se va incrementando hasta que la variable toma su máximo valor,   cuando se vuelva a incrementar, la variable tomará el valor 0.   Como a nosotros nos interesa el incremento de una muestra a la siguiente, debemos calcular la diferencia entre muestras para saber en cuanto se ha incrementado cada variable.   El cálculo de este incremento no va a ser necesario en todas las variables, ya que el valor de la velocidad de la línea IfSpeed, debe permanecer constante. (A no ser que se produzca un cambio en la configuración del dispositivo, pero en este caso no se presentará el incremento, sino el valor real).

Un ejemplo de su manejo es: 

“snmpget(dominio,@numerosASN1)” ó “snmpget dominio palabras clave separadas por espacios”

Un dominio de un router puede ser 

Name:    institutro.ci.uv.es Address:  147.156.160.1          

Por ejemplo snmpget post.uv.es public system.sysDescr.0 que pregunta por la  variable system.sysDescr.0, siendo dicha notación, correspondiente a “system.variable.puerto”, es decir consulta la variable sysDescr dentro del objeto system, en la interfaz 0 del dispositivo a monitorizar. En el caso de puerto=0, se refiere a la propia máquina local.

Por tanto con SNMP se ha de implementar una consulta de las siguientes variables:
ifInOctets, ifOutOctets y ifSpeed. Un ejemplo de dicha consulta es

snmpget ronmbre_router public ifInOctets.1 ifOutOctects.1

para hacer una consulta para obtener en decimal las variables ifInOctets y ifOutOctects de la máquina nombre_router, en su interfaz o puerto 1.

En Linux, las consultas se pueden hacer desde programa con la petición al sistema a través de system(“llamada_al_sistema”) definido en  #include <stdlib.h> con  int system (const char * string).

8.3.6 SNMPv2
	
El SNMPv2 es un intento de solucionar las deficiencias que con el paso del tiempo han ido surgiendo en la primera versión.  Estas deficiencias están causadas básicamente, por el intento de mantener la v1 lo más simple posible, además de por el incremento en la complejidad en las redes de ordenadores, y la necesidad de un protocolo más sofisticado.  La aparición de esta segunda versión no estuvo exenta de polémica, ya que al intentar mejorar deficiencias como, la falta de seguridad en las transmisiones, se llego a un protocolo demasiado complicado, por lo que ha sido revisado en varias ocasiones.  Las características más destacables que se añaden en esta segunda versión son:

1.	Seguridad:   La primera versión no era segura, ya que se enviaba el nombre de la comunidad en texto llano, por lo que era posible hacer cambios en la configuración de un dispositivo por cualquier persona que tuviese acceso a la red. En la segunda versión se incorporan técnicas de encriptación para intentar solucionar este problema.
2.	Operaciones con grandes volúmenes:  La segunda versión incorpora el PDU GetBulkRequest.  Este PDU proporciona a las estaciones administradoras la posibilidad de trabajar con grandes cantidades de datos, de una sola vez.  Esto es especialmente importante a la hora de recuperar grandes tablas,  ya que con el comando GETNEXT se recogía una fila en cada llamada.  Este comando llena el buffer de respuesta hasta su capacidad máxima, con lo que el tráfico por la red disminuye al disminuir el número de peticiones necesarias para obtener una tabla
3.	Nuevo formato para los eventos:  Los traps en la primera versión tenían un formato diferente al de cualquiera de los otros comandos (GET, SET o GETNEXT).  En la segunda versión se unifica este formato, siendo el mismo para un trap que para un comando de petición.
4.	Comunicación administrador-administrador:   Un nuevo PDU que se añade es el Inform_Request PDU, con este se facilita la comunicación entre diferentes estaciones administradoras, permitiendo la existencia de jerarquías que son necesarias en sistemas muy complejos.  Este estilo de administración reduce el trafico de administración y sobre todo la cantidad de información a transmitir.
5.	Tipos de datos de 64 bits:  Los avances a nivel físico, exigían la aparición de nuevos tipos de datos más eficaces. 
6.	Mejoras en las adquisiciones:  En la primera versión, cuando una de las variables en la VBL de un comando GET fallaba, hacia que todo el comando fallara, por lo que debía eliminarse esta variable de la lista, y volverse a consultar.  En SNMPv2 este procesamiento es automático, y el error se indica en el valor de retorno de la variable.

Figura 8.8: Esquema de red con RMON monitorizando otros segmentos.

8.3.7 RMON y monitorización remota

SNMP gestiona dispositivos individuales, pero no permite diagnosticar fallos en un red remota u otro segmento de red. Para ello, el software de monitorización debe trasladarse a cada segmento de red.

Esto se puede resolver mediante el uso de agentes en los segmentos remotos de red, utilizando equipos especiales o bien ordenadores de propósito general, llamados sondas RMON (Remote MONitor). Una de las mejoras principales de SNMP se denomina Monitoreo Remoto (RMON) como puede verse en la figura 8.8.

Las extensiones de RMON a SNMP brindan la capacidad para observar la red como un todo, aunque esté distribuida, en contraste con el análisis de dispositivos individuales, declarándose para ello una MIB especial para guardar información de monitorización de un segmento de red diferente. La MIB asociada es 1.3.6.1.2.1.16

Las sondas RMON recopilan información y tiene la misma función que un agente SNMP, transmitiendo la información periódicamente. Además, pueden procesar la información a enviar a la estación de administrador.

La RMON está localizada en cada segmento de red y pueden introducirse en un host, en un switch, en un router o en un dispositivo específico para ello. Además, permite añadir redundancia a la administración de la red, ya que RMON permite volcar los datos a varias consolas de administración. La RMON1 trabaja en información de capa 1 y 2. La RMON2 trabaja en información de capa 3 y superiores.