Unidad 6.unlocked PDF

Unidad 6: Servicios y protocolos de aplicación Informática VI
UNIDAD 6: SERVICIOS Y PROTOCOLOS DE APLICACIÓN
CONTENIDO
6.1 El servicio DNS – El sistema de nombres - Servidores DNS e Internet – Dominios – Zonas -
Servidores de nombres – Registros de recursos – Formato de los registros de recursos DNS –
Servidores de nombres: primario, secundario y maestro – Archivos de zona – Transferencia de
zona – Notificación DNS - Servidores de reenvío (forwarders) y servidores esclavo – El
almacenamiento en cache - Resolución de nombres – Obtención del nombre del host dada la
dirección IP – Formato del mensaje DNS – Respuestas de consultas – Actualización dinámica –
Seguridad para el servicio DNS – Seguridad en la transferencia de datos – Seguridad de los datos
almacenados – Autenticación de los datos – RR especiales KEY, SIG, NXT- Como se firma una
zona – Generación de claves – Configuración del servidor DNS de reenvío – El formato de la
consulta y respuesta DNSSEC – Crear un esquema de seguridad global – Navegación desde el
punto de confianza – Rotación de las claves KSK y ZSK – Configuración del servicio DNS y
DNSSEC.
6.2 El protocolo DHCP – Terminología DHCP – Protocolo DHCP – Diferencias entre BOOTP y
DHCP - Re-utilización de una dirección de red previamente asignada – El formato del mensaje
DHCP – Agente rele DHCP – Como funcionan los agentes de retransmisión - Planificación de
redes DHCP – Servidores DHCP – Clientes DHCP – Opciones de DHCP – Configuración de un
servidor DHCP – Actualización dinámica con el servidor DNS.
6.3 El protocolo HTTP – Mensajes entre cliente y servidor – Tipos de conexiones cliente servidor
– Cabeceras del protocolo – Estructura de los mensajes HTTP – Caches de páginas y servidores
Proxy – Cookies – Sitios virtuales – Directorios virtuales – Configuración de un servidor HTTP.
6.4 El protocolo FTP – Terminología FTP – El modelo FTP – Transferencia de datos – Modos de
transmisión – El cliente FTP – El servidor FTP – Configuración e un servidor FTP.
6.5 El servicio de Correo Electrónico – El agente de transferencia de mensajes – El agente de
distribución de mensajes – El agente de mensajes del usuario – Formato de un mensaje de correo
electrónico – Protocolo Simple de Transmisión de Correo (SMTP) – Protocolo SMTP desde un
cliente Telnet hacia un servidor SMTP – Configuración de un servidor SMTP.
6.6 Protocolo IMAP – Comunicación entre cliente y servidor – Atributos del mensaje de correo –
Partes del mensaje – Estados de una conexión IMAP – Comandos de cliente – Configuración de un
servidor IMAP4.
6.7 Protocolo POP3 – Comandos POP3 – Configuración del servicio.
6.8 Especificaciones MIME – Campos de cabecera de un mensaje – Ejemplos.
6.9 El protocolo Telnet – El Terminal Virtual de Red – Opciones negociadas – Simetría de las
conexiones – Transmisión de datos – Ordenes Telnet – Aplicaciones de Telnet .
6.10 Administración de redes – Gestión de redes en Internet – Base de información de gestión –
Estructura de información de gestión – El estándar ASN.1 – El protocolo SNMP – La seguridad en
SNMP.
1
Autor: Ing. Oscar R. Espeche
OBJETIVOS DE LA UNIDAD
Al finalizar esta unidad, usted estará en condiciones de alcanzar los siguientes objetivos:
• Reconocer los servicios que prestan las computadoras a programas cliente

• Identificar los protocolos de red que se emplean en dichos servicios.
• Reconocer los distintos programas y protocolos que intervienen en un determinado
servicio.
• Reconocer problemas de seguridad que manifiestan determinados servicios.
• Establecer las pautas para definir el comportamiento de determinado servicio.
• Identificar el ámbito adecuado para cada servicio.
2
CONTENIDOS DE LA UNIDAD
En esta unidad se estudiarán los servicios más importantes en una red TCP/IP, más precisamente
en el ámbito de Internet.
Los servicios y protocolos que se explicarán son los siguientes:
1. El servicio DNS
2. El protocolo DHCP
3. El protocolo HTTP
4. El protocolo FTP
5. El servicio de Correo Electrónico
6. Protocolo IMAP
7. Protocolo POP3
8. Especificaciones MIME
9. El protocolo Telnet
10. Administración de redes
3
ESQUEMA CONCEPTUAL
El servicio DNS
El protocolo DHCP
El protocolo HTTP
El protocolo FTP
El servicio de Correo Electrónico
PROTOCOLO TCP/IP
Protocolo IMAP
Protocolo POP3
Especificaciones MIME
El protocolo Telnet
Administración de redes
4
INTRODUCCIÓN
En esta unidad veremos en detalle las aplicaciones servidoras y protocolos que ya se anunciaron en
la presentación de la capa de aplicación del modelo OSI.
5
6.1 El servicio DNS

Es el servicio que permite resolver o convertir nombres de dominio DNS en direcciones IP y
viceversa.
A mediados de los 70, la ARPANET era una comunidad pequeña y amistosa de unas cientos de
máquinas. Un solo archivo, HOSTS.TXT, contenía toda la información que se necesitaba saber
sobre esas máquinas: contenía un mapeo de nombre a dirección para cada máquina en la
ARPANET.
El archivo /etc/hosts (se usa normalmente en LINUX para resolver nombres de computadoras en
direcciones IP) se obtenía entonces del archivo HOSTS.TXT (el cual tenía información adicional
que no era necesaria).
Sin embargo, cuando la ARPANET se cambió a los protocolos TCP/IP, la población de la red
explotó, y con ello se presentaron los siguientes problemas:
• La carga y el tráfico de red para la máquina que contenía las tablas que hacían posible el
mapeo de nombres a direcciones IP se volvió inmanejable.
• Colisiones de nombres. El NIC (organismo encargado de administrar la creación de
nombres) no podía garantizar que alguien asignara el mismo nombre a máquinas distintas
(Esto se debe a que con el método del HOSTS.TXT se tenía un dominio plano, es decir, sin
jerarquías).
• Consistencia: Mantener la consistencia del archivo a lo largo de una red en crecimiento se
hacía cada vez más difícil (Por ejemplo, cuando el archivo HOSTS.TXT llegaba a una
máquina muy lejana ya era obsoleto).
Este método se tornaba ineficiente a medida que aumentaban el número de máquinas. Es allí donde
entra DNS (Domain Name System, Sistema de Nombres de Dominio).
El Sistema de nombres de dominio (DNS) es un conjunto de protocolos y servicios sobre una red
TCP/IP que permite a los usuarios de la red utilizar nombres amigables jerárquicos cuando se
busca a otros hosts, en lugar de tener que recordar y usar sus direcciones IP.
En la actualidad, este sistema se usa en Internet y en casi todas las intranets de las empresas
privadas cuyos sistemas operativos estén configurados para trabajar con el protocolo TCP/IP. Si
alguna vez ha utilizado un explorador WEB, una aplicación de Telnet, un programa de FTP o
cualquier otro programa de TCP/IP parecido de Internet, entonces probablemente haya usado un
servidor DNS.
La función más conocida de los protocolos DNS es la asignación de nombres amigables a
direcciones IP. Por ejemplo, si la dirección IP del sitio FTP de Microsoft es 157.55.100.1, la
mayoría de la gente llega a este equipo especificando ftp.microsoft.com y no la dirección IP, que
es menos amigable. Además de ser más fácil de recordar, el nombre es más fiable (es como una
marca registrada) ya que las otras direcciones de las computadoras (mac address y direcciones IP)
son temporarias aunque sean estáticas.
Antes de la implementación de DNS, la utilización de nombres de equipos que fueran amigables se
realizaba a través del uso de archivos planos como HOSTS, que contenían una lista de nombres y
sus direcciones IP asociadas. En Internet, este archivo se administraba de forma centralizada y cada
6
administración descargaba periódicamente una nueva copia. A medida que fue creciendo el
número de equipos en Internet, esta solución se complicó demasiado y surgió la necesidad de algo
mejor. Esta solución mejor se convirtió en DNS.
Según el Dr. Paul Mockapetris, el diseñador principal de DNS, el objetivo original del diseño de
DNS era reemplazar este engorroso archivo HOSTS, administrado de forma singular, por una base
de datos distribuida ligera que permitiera la existencia de un espacio jerárquico de nombres, la
distribución de la administración, tipos de datos extensibles, tamaño de base de datos virtualmente
ilimitado y un rendimiento razonable.
DNS se asigna a la capa 7 del modelo OSI y puede usar UDP o TCP como protocolo subyacente.
Los resolver (programa del sistema operativo encargado de resolver los nombres de las
computadoras a solicitud de los programas de aplicación) envían consultas UDP primero a los
servidores, para obtener un mejor rendimiento, y sólo acuden a TCP si los datos devueltos están
truncados.
La implementación más conocida del protocolo DNS ‘BIND’ se programó en Berkeley,
originalmente, para el sistema operativo UNIX BSD 4.3. El nombre ‘BIND’ significa Berkeley
Internet Name Domain (Dominio de nombres de Internet de Berkeley). Las especificaciones
principales de DNS se definen en las Peticiones de comentarios (Requests for Comments, RFC)
974, 1034 y 1035.
El Sistema de Nombres
Un sistema de nombres de dominio (DNS) consta de una base de datos de nombres distribuida. Los
nombres de la base de datos DNS establecen una estructura lógica de árbol conocida como espacio
de nombres del dominio. Cada nodo o dominio del espacio de nombres del dominio tiene un
nombre y puede contener sub-dominios.
Los dominios y sub-dominios se agrupan en zonas para permitir la administración distribuida del
espacio de nombres (las zonas se describen más adelante en esta sección).
El nombre del dominio identifica la posición del dominio en la jerarquía lógica de DNS respecto de
su dominio principal, al separar cada rama del árbol con un punto ‘.’. En la Figura se muestran
varios dominios superiores, entre los que se encuentra el dominio IUA y un host llamado ‘www’
dentro del dominio íua.edu.ar´. Si alguien quisiera contactar con ese host, usaría el Nombre de
dominio completo (FQDN) www.iua.edu.ar.
7
Servidores DNS e Internet

El Centro de información de la red Internet (Internet Network Information Center,
http://www.internic.com) administra la raíz de la base de datos DNS en Internet. Los dominios
superiores (top level) se han asignado a organizaciones y países. Estos nombres de dominio siguen
el estándar internacional 3166. Para los países se usan abreviaturas de dos y de tres letras, y se han
reservado varias abreviaturas para que las usen las organizaciones, como se muestra en los
siguientes ejemplos.
Nombre dominio DNS Tipo de organización
com Comercial (por ejemplo, microsoft.com para Microsoft Corporation)
edu Educacional (por ejemplo, iua.edu.ar para el Instituto Universitario
Aeronáutico)
gov Gubernamental (por ejemplo, rosada.gob para la Casa Rosada)
int Organizaciones internacionales (por ejemplo, otan.int para la OTAN)
mil Operaciones militares (por ejemplo, ejército.mil para el Ejército)
net Organizaciones de redes (por ejemplo, nsf.net para NSFNET)
org Organizaciones no comerciales (por ejemplo, fidonet.org para FidoNet)
Dominios
Cada nodo del árbol de una base de datos DNS, junto con todos los nodos por debajo del mismo, se
llama un dominio. Los dominios pueden contener host (equipos) y otros dominios (sub-dominios).
Por ejemplo, el dominio Microsoft, microsoft.com, podría contener a la vez equipos, como
ftp.microsoft.com, y sub-dominios, como dev.microsoft.com, que a su vez podría contener host,
como por ejemplo ntserver.dev.microsoft.com.
Zonas
Una zona es alguna parte del espacio de nombre DNS, almacenado como un conjunto de registros
de una base de datos, en un archivo de zona. Puede configurarse un único servidor DNS para
administrar uno o múltiples archivos de zona. Los archivos de zona no contienen necesariamente
todo el árbol (es decir, todos los sub-dominios) bajo el dominio raíz de la zona. En la Figura, que
se muestra a continuación, se ofrece una comparación entre dominios y zonas. En este ejemplo,
microsoft.com es un dominio pero el dominio completo no está controlado por un archivo de zona.
Parte del dominio está realmente dividido en un archivo de zona distinto para dev.microsoft.com.
Es muy importante que comprenda la diferencia entre una zona y un dominio. Una zona es un
archivo físico compuesto de varios registros de recurso que definen uno o varios sub-dominios. Un
dominio es un nodo del espacio de nombres DNS y todos los sub-dominios que se encuentran por
debajo. Podríamos hacer una semejanza entre el árbol de dominios y un árbol de directorios. Los
dominios serian los directorios; los sub-dominios, los sub-directorios; y los hosts , los archivos.
8
Servidores de nombres (Servidores DNS)

Los servidores DNS almacenan las zonas, y son conocidos como Servidores de nombres. Los
servidores de nombres suelen ser responsables de una o más zonas. El servidor de nombres se dice
que tiene autoridad sobre esas zonas.
Cuando se configura un Servidor de nombres DNS, se indica cuáles son los restantes Servidores de
nombres DNS que mantienen zonas de sub-dominios que se encuentran en el mismo dominio. De
esa forma se establece la relación padre-hijo de las diferentes zonas que conforman un dominio.
Registros de recursos
Una base de datos DNS o zona, se compone de uno o varios archivos de zonas utilizados por el
servidor DNS. Cada zona mantiene un conjunto de registros de recursos estructurados.
Formato de los registros de recursos DNS
Todos los registros de recursos tienen un formato definido que utiliza los mismos campos de nivel
superior, según se describe en la tabla siguiente.
9
Campo Descripción
Propietario Indica el nombre de dominio DNS o dirección IP que posee un registro de recursos.
Para la mayor parte de los registros de recursos, este campo es opcional. Indica el
espacio de tiempo utilizado por otros servidores DNS para determinar cuánto tarda
la información en caché en caducar un registro y descartarlo.
Por ejemplo, la mayor parte de los registros de recursos que crea el servicio del
servidor DNS heredan el TTL mínimo (predeterminado) de 1 hora desde el registro
de recurso de inicio de autoridad (SOA) que evita que otros servidores DNS
Tiempo de
almacenen en caché durante demasiado tiempo.
vida (TTL)
En un registro de recursos individual, puede especificar un TTL específico para el
registro que suplante el TTL mínimo (predeterminado) heredado del registro de
recursos de inicio de autoridad. También se puede utilizar el valor cero (0) para el
TTL en los registros de recursos que contengan datos volátiles que no estén en la
memoria caché para su uso posterior una vez se complete la consulta DNS en
curso.
Contiene texto nemotécnico estándar que indica la clase del registro de recursos.
Clase Por ejemplo, el valor "IN" indica que el registro de recursos pertenece a la clase
Internet.
Contiene texto nemotécnico estándar que indica el tipo de registro de recursos. Por
Tipo ejemplo, el texto nemotécnico "A" indica que el registro de recursos almacena
información de direcciones de host. Este campo es obligatorio.
Datos Un campo, de longitud variable y obligatorio con información que describe el
específicos del recurso. El formato de esta información varía según el tipo y clase del registro de
registro recursos.
A continuación se describen algunos registros que son los más comunes.
Registro tipo A
Descripción: registro de recursos de direcciones de host (A). Asigna un nombre de dominio DNS
a una dirección de 32 bits de Protocolo Internet (IP) versión 4
Sintaxis: propietario clase ttl A dirección IPv4
Ejemplo: www.iua.edu.ar IN A 200.200.200.200
Registro de tipo AAAA
Descripción: registro de recursos de direcciones de host IPv6 (AAAA). Asigna un nombre de

dominio DNS a una dirección de 128 bits del Protocolo Internet (IP) versión 6.
Sintaxis: propietario clase ttl AAAA dirección IPv6
Ejemplo: ns.pepe.com IN AAAA 4321:0:1:2:3:4:567:89ab
Registro de tipo ATMA
Descripción: registro de recursos de direcciones en Modo de transferencia asincrónica (ATMA,

10
Asynchronous Transfer Mode address). Asigna un nombre de dominio DNS del campo propietario
a una dirección ATM a la que hace referencia el campo dirección Atm.
Sintaxis: propietario ttl clase ATMA dirección Atm
Ejemplo: atm-host ATMA 47.0079.00010200000000000000.00a03e000002.00
Registro tipo CNAME
Descripción: registro de recursos de nombres canónicos (CNAME). Asigna un nombre de

dominio DNS alternativo o alias, del campo propietario a un nombre de dominio DNS principal o
canónico especificado en el campo nombre Canónico. El nombre de dominio DNS principal o
canónico utilizado en los datos es obligatorio y debe resolverse en un nombre de dominio DNS
válido del espacio de nombres.
Sintaxis: propietario ttl clase CNAME nombre Canónico
Ejemplo: nombrealias.pepe.com. CNAME nombreverdadero.pepe.com
Registro tipo ISDN (RDSI)
Descripción: registro de recursos de la Red digital de servicios integrados, RDSI (ISDN,

Integrated Services Digital Network). Asigna un nombre de dominio DNS a un número de teléfono
RDSI. Los números de teléfono utilizados con este registro deben seguir el estándar de numeración
telefónica internacional ITU-T E.163/E.164, que es compatible con los planes actuales de
numeración telefónica internacional ya en uso.
Sintaxis: propietario ttl clase ISDN direcciónRDSI direcciónSub
Ejemplo: mi-isdn-host.pepe.com. ISDN 141555555539699 002
Registro de tipo MB
Descripción: registro de recursos de buzón (MB). Asocia el nombre de buzón de dominio,

especificado en el campo propietario, a un nombre de host de servidor de correo
nombreHostBuzón. El nombre de host del buzón debe ser el mismo que el de un registro de
recursos de direcciones de host (A) válido utilizado ya por un host en la misma zona. Además, el
host especificado debe tener un buzón de dominio que acepte correo para el propietario
especificado.
Sintaxis: propietario ttl clase MB nombreHostBuzón
Ejemplo: mailbox.pepe.com. MB mailhost1.pepe.com
Registro de tipo MG
Descripción: registro de recursos del grupo de correo (MG). Se utiliza para agregar buzones de
dominio, cada uno especificado por un registro de recursos de buzón (MB) en la zona actual, al
grupo de correo de dominio identificado por propietario en este registro de recursos. Los nombres
utilizados en el campo nombreBuzón deben ser idénticos a los registros de recursos de buzón (MB)
válidos ya presentes en la zona actual
Sintaxis: propietario ttl clase MG nombreBuzón
Ejemplo: administrator.pepe.com. MG mailbox1.pepe.com mailbox2.pepe.com
11
Registro de tipo MX
Descripción: registro de recursos del agente de intercambio de correo (MX) (servidor de correo
MTA). Permite localizar al ruteador (intercambiador de correo) de correo MTA de un dominio
determinado. El nombre del servidor se especifica en hostIntercambiadorDeCorreo. Permite
localizar el intercambiador de correo para el correo (Ej. Dirección Juan@pepe.com) enviado con
nombre de dominio que se especifica en el campo propietario. El valor de preferencia de 2 dígitos
indica el orden preferido cuando se especifican varios hosts intercambiadores. Cada host
intercambiador debe tener su correspondiente registro de recursos de direcciones de host (A) en
una zona válida.
Sintaxis: propietario ttl clase MX preferencia hostIntercambiadorDeCorreo
Ejemplo: pepe.com. MX 10 mailserver1.pepe.com
Registro de tipo NS
Descripción: se usa para asignar un servidor de nombres DNS a un dominio determinado. El

nombre de dominio DNS se especifica en el campo propietario. El nombre del servidor DNS se
especifica en el campo nombreServidorNombreDominio.
Sintaxis: propietario ttl IN NS nombreServidorNombreDominio
Ejemplo: pepe.com. IN NS nameserver1.pepe.com
Registro de tipo PTR
Descripción: registro de recursos de apuntador (PTR). Relaciona una dirección IP en el campo

propietario, a una ubicación en el espacio de nombres DNS según lo especificado por
nombreDominioDestino. A menudo se utiliza en dominios especiales como el árbol de dominio in-
addr.arpa para proporcionar búsquedas inversas de asignaciones de dirección a nombre. En la
mayor parte de los casos, cada registro proporciona información que señala a otra ubicación de
nombre de dominio DNS, como el registro de recursos de direcciones host (A) correspondiente en
una zona de búsqueda directa.
Sintaxis: propietario ttl clase PTR nombreDominioDestino
Ejemplo: 1.0.0.10.in-addr.arpa. PTR host.pepe.com.
Tipo de registro SOA
Descripción: Registro de recursos de inicio de autoridad (SOA). Indica el nombre de origen de la

zona y contiene el nombre del servidor que es el origen principal de información acerca de la zona.
También indica otras propiedades básicas de la zona. El registro de recursos SOA se encuentra
siempre el primero en cualquier zona estándar. Indica el servidor DNS que lo creó originalmente o
que es ahora el servidor principal de la zona. También se utiliza para almacenar otras propiedades
como la información de la versión y las temporizaciones que afectan a la caducidad o renovación
de zonas. Estas propiedades afectan a la frecuencia con que se realizan las transferencias de la zona
entre servidores autorizados de la zona.
En el ejemplo siguiente, el propietario se especifica como "@" y representa al dominio principal u

origen de todos los datos de la zona (ejemplo.microsoft.com.). Se trata de una convención de
nomenclatura estándar para registros de recursos y se utiliza más a menudo en los registros SOA.
12
Sintaxis:
propietario clase SOA servidorNombres personaResponsable (numeroSerie intervaloActualiza
cion intervaloReintento caducidad tiempoDeVidaMinimo)
Ejemplo:
@ IN SOA nameserver.pepe.com. postmaster.pepe.com. (
1 ; serial number
3600 ; refresh [1h]
600 ; retry [10m]
86400 ; expire [1d]
3600 ) ; min TTL [1h]
Registro de tipo X25
Descripción: registro de recursos X.25 (X25): Asigna un nombre de dominio DNS en el campo
propietario al número de dirección de Red pública de datos conmutados (PSDN, Public Switched
Data Network) especificado en númeroPsdn. Los números PSDN que se utilizan con este registro
deben seguir el plan de numeración internacional X.121.
Sintaxis: propietario ttl clase X25 númeroPsdn
Ejemplo pepe.com. X25 52204455506
13
Servidores de nombres: primario, secundario y maestro

Un Servidor de nombres primario – o principales un servidor de nombres que obtiene los
datos de sus zonas, de archivos locales de zona. Los cambios en una zona, como la adición de
dominios o hosts, se realizan en el Servidor de nombres primario. Un Servidor de nombres
secundario obtiene los datos de sus zonas de otro servidor de nombres primario, que tiene
autoridad para esa zona. El proceso de obtención o copia de información de estas zonas (es decir,
copia del archivo de zona) se conoce como una transferencia de zona.
Existen tres razones para tener servidores secundarios en una empresa:
Redundancia: Se necesitan al menos dos servidores de nombres DNS que sirvan cada
zona, uno principal y al menos uno secundario para redundancia. Como en el caso de
cualquier sistema de tolerancia a fallos, los equipos deben ser tan independientes como sea
posible (es decir, redes distintas, etc.).
Ubicaciones remotas: También se debería tener servidores secundarios (u otros servidores
principales para los subdominios) en ubicaciones remotas que tengan un alto número de
clientes. Los clientes no deberían comunicarse a través de enlaces lentos para la resolución
de nombres.
Reducir la carga del principal: También se necesitan servidores secundarios para reducir
la carga del servidor principal.
Puesto que la información de cada zona se almacena en archivos separados, esta designación
principal o secundaria se define a nivel de zona. En otras palabras, un servidor de nombres
determinado puede ser un servidor de nombres principal para ciertas zonas y un servidor de
nombres secundario para otras zonas.
Cuando se define una zona en un servidor de nombres secundario, se debe designar un servidor de
nombres primario donde deberá obtener la información de la zona. El origen de la información de
la zona de un servidor de nombres secundario, se conoce como un Servidor de nombres maestro.
Cuando se inicia un servidor de nombres secundario, se pone en contacto con su servidor de
nombres maestro e inicia una transferencia de zona con ese servidor. También, un servidor
secundario podría ser maestro de otro secundario, cuando el servidor primario no sea accesible o se
encuentre muy distante.
En la mayor parte de implementaciones con versiones anteriores de servidores DNS, este método
de transferencia completa de una zona también se utiliza cuando la zona necesita actualizarse
después de haber experimentado cambios. Para los servidores DNS que ejecutan versiones
modernas, el servicio DNS admite la transferencia de zona incremental; un proceso revisado de
transferencia de zona DNS para cambios intermedios.
14
Archivos de zona
Los archivos de zona constituyen las bases de datos de los servidores DNS que tienen autoridad
sobre la zona. El conjunto de estos archivos de todo el mundo constituyen la base de datos
distribuida DNS mundial.
Tenemos dos tipos de zonas:
• Zonas directas. Permiten obtener la dirección IP en base a un nombre de dominio.

• Zonas inversas. Permiten obtener los nombres DNS en base a una dirección IP.
Se usan archivos separados puesto que no existe una relación biunívoca entre las direcciones y los
nombres. Un nombre puede tener varias direcciones IP y una dirección IP puede tener varios
nombres.
En la siguiente figura vemos un ejemplo de una zona directa.
;
; Archivo de zona para iua.edu.ar
;
; Mínimo indispensable para tener funcionando un dominio
;
@ IN SOA ns.iua.edu.ar. root.ns.iua.edu.ar. (
2002062701 ; Numero de serie, fecha de hoy + n. de
; serie de hoy
28800 ; Tasa de Refresco, en segundos
7200 ; Tasa de Reintento, en segundos
3600000 ; Caducidad para secundario, en segundos
86400 ) ; Tiempo de Validez para Clientes, en segundos
NS ns.iua.edu.ar. ; servidor DNS
MX 10 mail.iua.edu.ar. ; servidor de Correo Primario
MX 20 mail2.iua.edu.ar. ; servidor de Correo Secundario
localhost A 127.0.0.1
ns A 192.168.1.200
mail A 192.168.1.201
mail2 A 192.168.1.202
……………………………………………
……………………………………………
Deben de observarse dos cosas sobre los registros SOA: ns.iua.edu.ar. debe ser una máquina actual
con un registro A. No es legal tener un registro CNAME (alias) para la máquina mencionada en el
registro SOA. Su nombre no necesita ser ns, podría ser cualquier nombre legal de máquina. Ud
debería usar el nombre y dirección IP de su servidor DNS.
El hostmaster de ns.iua.edu.ar deberá tener una dirección de correo como root@ns.iua.edu.ar; esto
es una cuenta de correo, donde la(s) persona(s) que realizan el mantenimiento de DNS deberían
leer con frecuencia el correo. Cualquier email respecto del dominio será mandado a la dirección
aquí indicada. El nombre no tiene por que ser root, puede ser cualquier dirección email legal.
15
El registro de recurso (RR) MX, o Mail eXchanger indica el servidor de correo a donde mandar el
correo dirigido a alguien@ iua.edu.ar.
El número que precede a cada nombre de máquina es la prioridad del RR MX. El RR con el
número más bajo (10) es aquel al que el correo será enviado primero. Si este falla, puede ser
mandado a otro con un número más alto, que será gestor secundario de correo, como
mail2.iua.edu.ar que tiene una prioridad 20 aquí.
En la siguiente figura vemos un ejemplo de una zona inversa.
@ IN SOA ns.iua.edu.ar. root.iua.edu.ar. (

199609206 ; Numero de Serie
28800 ; Tasa de Refresco
7200 ; Tasa de Reintento
604800 ; Caducidad para secundario
86400) ; Validez para Clientes
NS ns.iua.edu.ar.
MX 10 mail.iua.edu.ar.
;
; Servidores
;
200.200.200.1. PTR router.iua.edu.ar.
200.200.200.2. PTR ftp.iua.edu.ar.
200.200.200.3. PTR datos.iua.edu.ar.
200.200.200.4. PTR ns.iua.edu.ar.
200.200.200.5. PTR mail.iua.edu.ar.
;
;
; Estaciones de Trabajo
;
200.200.200.200. PTR ws_177200. iua.edu.ar.
200.200.200.201. PTR ws_177201.iua.edu.ar.
200.200.200.202. PTR ws_177202.iua.edu.ar.
…………………………………………………….
…………………………………………………….
La zona de resolución inversa es la parte de la configuración que parece crear más dolores de
cabeza. Se usa para encontrar el nombre de la máquina a partir de su dirección IP. Existe esta
necesidad cuando por razones de seguridad se desea comprobar que existe dicho nombre y tiene tal
dirección IP.
La resolución inversa puede parecer que sólo es importante para los servidores, o que no tienen
importancia. No es así; muchos servidores de ftp, news, irc e incluso algunos servidores http
(WWW) NO aceptarán conexiones de máquinas de las cuales no son capaces de resolver el
nombre en forma inversa. Por tanto el mapeo inverso de máquinas es de hecho obligatorio.
En base a lo explicado queda para el alumno la configuración completa del servidor DNS que
instalará en su computadora de acuerdo a las características de su red.
16
Transferencia de zona
El servidor secundario o esclavo debe buscar en el servidor primario o maestro los datos de la zona
de la cual el es servidor con autoridad.
Para ello el servidor secundario debe conocer la dirección de red del servidor primario, al cual
recurrirá inmediatamente de ser configurado, y luego en sucesivas búsquedas para actualizar su
archivo de zona de acuerdo a lo establecido en el registro SOA de la zona respectiva.
El servidor secundario se fija en el número de serie del registro SOA y si su versión es inferior a
este, realiza la copia o transferencia de zona completa.
También es posible de acuerdo a la configuración del servidor primario, que este notifique a los
servidores secundarios cuando se realicen modificaciones en la zona. En cuyo caso los servidores
secundarios deberán iniciar la transferencia de la zona completa.
Las transferencias de zona incrementales se describen en el documento Solicitud de comentarios

(RFC, Request for Comments) 1995 como un estándar DNS adicional para replicar zonas DNS.
Cuando un servidor DNS que actúa como origen para una zona y los servidores que copian la zona
de él admiten las transferencias incrementales, se obtiene un método más eficiente para la
propagación de los cambios y las actualizaciones de la zona.
En las implementaciones DNS anteriores, una solicitud de actualización de los datos de la zona
requería una transferencia completa de toda la base de datos de la zona mediante una consulta
AXFR.
Con la transferencia incremental, se puede utilizar un tipo de consulta alternativo (IXFR). Esto
permite al servidor secundario extraer sólo los cambios de la zona que necesita para sincronizar su
copia de la zona con su origen, ya sea una copia principal o secundaria de la zona que mantiene
otro servidor DNS.
Con las transferencias de zona IXFR, primero se determinan las diferencias entre el origen y las
versiones replicadas de la zona. Si se determina que las zonas tienen la misma versión, en función
del valor indicado en el campo de número de serie del registro de recursos de inicio de autoridad
(SOA) de cada zona, no se realiza ninguna transferencia.
Si el número de serie de la zona de origen es mayor que el del servidor secundario solicitante,
solamente se realiza una transferencia de los cambios efectuados en los registros de recursos (RR)
de cada versión incremental de la zona.
Para realizar una consulta IXFR efectiva y enviar los cambios, el servidor DNS de origen de la
zona debe mantener un historial de los cambios incrementales de la zona para utilizarlo al
responder a estas consultas. El proceso de transferencia incremental requiere bastante menos
tráfico en la red y las transferencias de zona se completan mucho más rápidamente.
Una transferencia de zona puede darse en cualquiera de los casos siguientes:
• Cuando vence el intervalo de actualización de una zona

17
• Cuando un servidor maestro notifica los cambios de la zona a un servidor secundario

• Cuando se inicia el servicio Servidor DNS en un servidor secundario de la zona
• Cuando se utiliza la consola DNS (aplicación de órdenes para servidores DNS) en un
servidor secundario de la zona para iniciar manualmente una transferencia desde su
servidor maestro.
Las transferencias de zona siempre se inician en el servidor secundario de una zona y se envían a
sus servidores maestros configurados que actúan como origen de la zona. El servidor maestro
puede ser cualquier otro servidor DNS que cargue la zona, como el servidor principal para la zona
u otro servidor secundario. Cuando un servidor maestro recibe la solicitud para la zona, puede
responder con una transferencia parcial o completa de la zona al servidor secundario.
Como se muestra en la ilustración siguiente, las transferencias de zona entre servidores siguen un
proceso ordenado. Este proceso varía en función de si la zona se ha replicado anteriormente o si se
está realizando la replicación inicial de una zona nueva.
En este ejemplo, se lleva a cabo la siguiente secuencia para un servidor secundario solicitante (el
servidor de destino) de una zona y su servidor de origen (otro servidor DNS que aloja la zona).
1. Durante la nueva configuración, el servidor de destino envía una solicitud de transferencia

inicial de "toda la zona" (AXFR) al servidor DNS principal configurado como su origen
para la zona.
2. El servidor maestro (origen) responde y transfiere toda la zona al servidor secundario
(destino).
18
La zona se entrega al servidor de destino que solicita la transferencia con su versión

establecida mediante el campo Número de serie en las propiedades del registro de recursos
(RR) de inicio de autoridad (SOA). El registro de recursos de inicio de autoridad también
contiene un intervalo de actualización expresado en segundos (de forma predeterminada,
900 segundos o 15 minutos) para indicar el momento en el que el servidor de destino
debería realizar la siguiente solicitud para renovar la zona con el servidor de origen.
3. Cuando el intervalo de actualización vence, el servidor de destino utiliza una consulta de

inicio de autoridad para solicitar la renovación de la zona desde el servidor de origen.
4. El servidor de origen responde a la consulta de su registro de inicio de autoridad.
Esta respuesta contiene el número de serie de la zona en su estado actual en el servidor de

origen.
5. El servidor de destino comprueba el número de serie del registro de inicio de autoridad en

la respuesta y determina cómo renovar la zona.
Si el valor del número de serie de la respuesta de inicio de autoridad es igual a su número

de serie local actual, se deduce que la zona es la misma en los dos servidores y que no es
necesaria una transferencia de zona. A continuación, el servidor de destino renueva la zona
y restablece su intervalo de actualización según el valor de este campo de la respuesta de
inicio de autoridad de su servidor de origen.
Si el valor del número de serie de la respuesta de inicio de autoridad es mayor que su

número de serie local actual, se deduce que la zona se ha actualizado y que es necesaria una
transferencia de zona.
6. Si el servidor de destino deduce que la zona ha cambiado, envía una consulta IXFR al
servidor de origen, que contiene su valor local actual para el número de serie del registro de
inicio de autoridad de la zona.
7. El servidor de origen responde con una transferencia incremental o completa de la zona.
Si el servidor de origen admite la transferencia incremental y mantiene un historial con los

cambios incrementales recientes de la zona para los registros de recursos modificados,
puede responder con una transferencia incremental (IXFR) de la zona.
Si el servidor de origen no admite la transferencia incremental o no posee un historial con

los cambios de la zona, puede responder con una transferencia completa (AXFR) de la
zona.
19
Notificación DNS
Los servidores DNS modernos admiten la notificación DNS; una actualización de la

especificación del protocolo DNS original que facilita un medio para iniciar el envío de
notificaciones a servidores secundarios cuando se producen cambios de zona (RFC 1996).
La notificación DNS implementa un sistema de inserción para notificar a un grupo selecto de

servidores secundarios la actualización de una zona. A continuación, los servidores que han sido
informados pueden iniciar una transferencia de zona, tal y como se ha descrito anteriormente, para
extraer los cambios de zona de sus servidores maestros y actualizar sus réplicas locales de la zona.
Para que los servidores secundarios reciban una notificación del servidor DNS que actúa como su
origen configurado para una zona, cada servidor secundario debe tener primero su dirección IP en
la lista de notificación del servidor de origen.
Además de enviar notificaciones a los servidores de la lista, la consola DNS permite utilizar el
contenido de la lista de notificación como un medio para restringir o limitar el acceso de la
transferencia de zona sólo a los servidores secundarios especificados en la lista.
Esto puede servir de ayuda para impedir que un servidor DNS no aprobado o desconocido intente
extraer o solicitar actualizaciones de zona.
A continuación, se muestra un breve resumen del proceso de notificación DNS típico para las
actualizaciones de zonas:
1. La zona local se actualiza en un servidor DNS que actúa como servidor maestro, es decir,
como origen para la zona en otros servidores. Cuando se actualiza la zona en el servidor
maestro o de origen, también se actualiza el campo de número de serie del registro de
recursos de inicio de autoridad, que indica una versión local nueva de la zona.
2. El servidor maestro envía un mensaje de notificación DNS a otros servidores que forman
parte de su lista de notificación configurada.
3. A continuación, todos los servidores secundarios que reciben el mensaje de notificación
pueden responder mediante la emisión de una solicitud de transferencia de zona al servidor
maestro que envió la notificación.
El proceso de transferencia de zona normal puede continuar tal y como se describió en la sección
anterior.
Use la notificación DNS sólo con los servidores que actúan como servidores secundarios de una
zona.
De forma predeterminada, el servidor DNS sólo permitirá una transferencia de zona a los
servidores DNS autorizados, que son los especificados en los registros de recursos del servidor de
nombres maestro de la zona.
20
Servidores de reenvío (forwarders) y servidores esclavo
Cuando un servidor de nombres DNS recibe una petición de DNS, intenta localizar la información
solicitada dentro de sus propios archivos de zona. Si esto no funciona porque el servidor no tiene
autoridad sobre el dominio solicitado, debe comunicarse con otros servidores de nombres DNS
para resolver la petición.
Teniendo en cuenta que la petición de resolución DNS fuera de una zona local suele requerir la
interacción con servidores de nombres DNS de fuera de la empresa en Internet, puede que desee
activar de forma selectiva, determinados servidores de nombres DNS en su empresa para realizar
esta comunicación de área extensa, con servidores DNS de Internet.
Para solucionar este asunto, DNS ofrece el concepto de servidor de reenvío. Se seleccionan
determinados servidores de nombres DNS para que sean servidores de reenvío para el resto de los
servidores, de tal manera que estos sean los que lleven a cabo la comunicación de área amplia en
Internet.
Todos los demás servidores de nombres DNS de la compañía se configuran para que usen los
servidores de reenvío, mediante la indicación de la dirección IP de dichos servidores, como
servidores de reenvío. Esta configuración se realiza teniendo en cuenta el servidor, no la zona (son
servidores de reenvío para todas las zonas que se desee consultar y no para una en particular) . En
la siguiente figura se muestra ésta situación.
Cuando un servidor configurado como servidor de reenvío recibe una petición DNS que no puede
resolver (a través de sus propios archivos de zona), pasa la petición a sus servidores de reenvío. A
continuación, el siguiente servidor de reenvío realiza la comunicación necesaria para satisfacer la
petición y así sucesivamente. Una vez resuelta la petición original, se devuelve los resultados al
21
servidor que efectuó la petición, que a su vez, devuelve la petición al anterior, hasta llegar al
solicitante original.
Si el servidor de reenvío no puede resolver la consulta, el servidor que realizó la petición, también
tiene la alternativa de resolverla por sí mismo, de forma normal, consultando a otros servidores
DNS, para obtener la dirección del servidor DNS que tiene autoridad sobre la zona donde está
registrado el host de quien se quiere conocer su dirección IP.
Los esclavos son servidores DNS configurados para usar servidores de reenvío solamente y
también para devolver un mensaje de error si el propio servidor de reenvío no es capaz de resolver
la consulta. Los esclavos no intentan ponerse en contacto con otros servidores de nombres cuando
el servidor de reenvío no puede satisfacer la petición, salvo que estén definidos otros servidores de
reenvío a los cuales realizará las peticiones hasta lograr respuesta satisfactoria de alguno de ellos ó
agotar la lista de forwarders.
22
Servidores de almacenamiento temporal (sólo-cacheo)

Aunque todos los servidores de nombres DNS almacenan en la caché las consultas que han
solucionado, los Servidores de almacenamiento temporal (también llamados de sólo-cacheo) son
servidores de nombres DNS cuyo único trabajo es realizar consultas a otros servidores DNS,
almacenar en la caché las respuestas y devolver los resultados. Es decir, no tienen autoridad sobre
ningún dominio y sólo contienen la información que han acumulado en la caché mientras resolvían
consultas. En definitiva, no tienen autoridad sobre zona alguna.
A la hora de decidir cuándo usar estos servidores, tenga presente que, cuando el servidor se inicia
por primera vez, no tiene información acumulada en la caché y tiene que ir generando dicha
información con el tiempo, según vaya atendiendo peticiones.
El almacenamiento en caché
Cuando los servidores DNS procesan las consultas de los clientes mediante la recursividad o la
iteración, descubren y adquieren un almacén significativo de información acerca del espacio de
nombres DNS. A continuación, el servidor almacena en caché esta información.
El almacenamiento en caché aumenta el rendimiento de la resolución DNS para las consultas

subsiguientes de nombres muy utilizados, al tiempo que reduce sustancialmente el tráfico de las
consultas relativas a DNS en la red.
Cuando los servidores DNS realizan consultas en nombre de clientes, almacenan temporalmente en
caché los registros de recursos. Los registros de recursos almacenados en caché contienen
información obtenida de los servidores DNS que tienen autoridad para los nombres de dominio
DNS.
Posteriormente, cuando otros clientes realizan consultas nuevas que solicitan información de un
registro de recursos que coincide con los registros de recursos almacenados en la caché, el servidor
DNS puede utilizar la información de registro de recursos almacenada en la caché para
responderlas.
Cuando la información se almacena en la caché, se aplica el valor Tiempo de vida (TTL) a todos
los registros de recursos almacenados en la caché.
Mientras el tiempo de vida de un registro de recursos almacenado en la caché no caduque, un

servidor DNS puede seguir almacenando el registro de recursos en la caché y utilizándolo de
nuevo al responder a consultas de sus clientes que coincidan con estos registros de recursos.
Al valor de los TTL del almacenamiento en caché, se le asigna el TTL mínimo (predeterminado)
que se utiliza en el registro de recursos de inicio de autoridad (SOA) de la zona de donde proviene
la información del recurso.
De forma predeterminada, el tiempo de vida mínimo es de 3.600 segundos (1 hora), pero se puede
ajustar o, si es necesario, se pueden establecer tiempos de vida individuales de almacenamiento en
caché para cada registro de recursos.
El administrador del servidor de nombres de la zona que contiene los datos originales, decide el
TTL para los datos propios. Cuanto menores sean los valores de TTL se asegurará que los datos del
23
dominio sean más consistentes en la red si este valor cambia a menudo. Sin embargo, esto también
aumentará la carga del servidor de nombres.
En cuanto se almacenan los datos en la caché de un servidor DNS, debe empezar a disminuir el
TTL (es decir, a descontar) del valor original, de forma que pueda saber cuándo eliminar los datos
de su caché. Si llega una consulta que se puede contestar con los datos acumulados, el TTL que se
devuelve con los datos es el tiempo real restante hasta que se eliminen los datos de la caché del
servidor DNS. Los resolver cliente también disponen de cachés de datos y utilizan el valor TTL, lo
que les permite saber cuándo caducan los datos.
24
Resolución de nombres
Un cliente puede realizar dos tipos de consultas a un servidor DNS, recursiva e iterativa.
Mientras se comenta la resolución de nombres, recuerde que un servidor DNS puede ser un cliente
de otro servidor DNS.
Consultas recursivas: En una consulta recursiva, se pide al servidor de nombres que responda con
los datos pedidos, o con un error que indique que el nombre del dominio especificado o los datos
del tipo pedido no existen. El servidor de nombres no puede mandar al solicitante a un servidor de
nombres distinto.
Este tipo de consulta suele realizarla un cliente DNS (un Resolver) a un servidor DNS. Además, si
un servidor DNS está configurado para usar un servidor de reenvío, la consulta de este servidor
DNS a su servidor de reenvío será una consulta recursiva.
Consultas iterativas: En una consulta iterativa, el servidor de nombres consultado devuelve al
solicitante la mejor respuesta que tiene disponible (la dirección IP de un servidor de nombres de
una zona lo más cercana al host en cuestión). Este tipo de consulta la suele realizar un servidor
DNS a otros servidores DNS después de haber recibido una consulta recursiva de un resolver.
En la siguiente figura se muestra un ejemplo de ambos tipos de consultas. La consulta 1/8 es una
consulta recursiva de un resolver de clientes a su servidor DNS, mientras que 2/3, 4/5 y 6/7 son
consultas iterativas del servidor DNS a otros servidores DNS.
Estas consultas iterativas son posibles debido a que cada servidor DNS contiene la dirección IP de
los servidores DNS de sus sub-zonas y de esta manera se materializa el árbol DNS para permitir su
navegación de arriba hacia abajo.
Por ejemplo el servidor DNS root-server (“.”) mantiene en su base de datos la dirección IP del
servidor DNS de la zona .com. Este servidor a su vez mantiene la dirección del servidor DNS de la
zona .empresa.com. Y este servidor finalmente es la autoridad de la zona que contiene a la
dirección IP de la computadora www.empresa.com. Vemos que la clave es disponer de la “punta
del ovillo” o sea de la dirección IP de algún root-server.
La lista de los root-servers (nombres y direcciones IP) se mantiene en un archivo o base de datos
en todo servidor DNS que desee realizar consultas iterativas. En la actualidad hay
aproximadamente (esto esta sujeto a cambios) 13 servidores DNS en el mundo que trabajan como
root-servers. En la figura se muestra un mapa con la ubicación geográfica de estos. Los nombres se
refieren como A-root-server, B-root-server, C…….
25
En la siguiente figura vemos un archivo que normalmente viene con el software de la aplicación
servidora DNS, que contiene el listado de los root-servers.
. 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
;
26
. 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
Cada entrada contiene dos líneas. Las líneas que comienzan con “;” son solo comentarios. La
primera indica que se trata de un registro NS o sea se refiere a un servidor de nombres. En este
caso el dominio propietario es root (“.“ ). La segunda indica que se trata de un registro A que
relaciona el nombre con la dirección IP de este servidor. Este archivo describe los servidores de
nombres del dominio raíz en el mundo. Uno es el primario y el resto son los secundarios. Este
archivo cambiará a lo largo del tiempo y tiene que ser mantenido y actualizado con una cierta
regularidad.
27
28
Obtención del nombre del host dada la dirección IP

¿Qué ocurre si un resolver tiene la dirección IP y quiere saber el nombre del host de una máquina
determinada? En lugar de suministrar un nombre y preguntar por una dirección IP, el cliente
necesita proporcionar la dirección IP y preguntar por el nombre. Puesto que no hay una relación
directa –uno a uno-, en el espacio de nombres DNS, entre los nombres de dominios y las
direcciones IP asociadas que contienen, sólo se puede garantizar una respuesta correcta si se realiza
una búsqueda en profundidad de todos los dominios.
Para solucionar este problema, se ha creado un dominio especial (“in-addr.arpa.”) en el espacio de
nombres DNS. Los nodos del dominio in-addr.arpa reciben su nombre según los números de la
representación en bytes punteada de las direcciones IP (xx.xx.xx.xx).
Pero, puesto que las direcciones IP se vuelven más específicas de izquierda a derecha y que los
nombres de dominio se vuelven menos específicos de izquierda a derecha, al generar el árbol in-
addr.arpa hay que invertir el orden de los bytes de la dirección IP. Con este arreglo, ser puede
conceder la administración de las ramas inferiores del árbol in-addr.arpa de DNS a las empresas
cuando se les asigna su dirección de subred de clase A, B o C.
Una vez generado el árbol del dominio en la base de datos DNS, se agrega un “registro de recurso”
para asociar las direcciones IP a los nombres correspondientes de host. Es decir, para buscar un
nombre de host para la dirección IP 157.55.200.2, el resolver solicitará al servidor DNS un registro
de recurso para 2.200.55.157.in-addr.arpa.
Si esta dirección estuviera fuera del dominio local, el servidor DNS empezaría en la raíz y
resolvería, secuencialmente, los nodos del dominio hasta alcanzar 200.55.157.in-addr.arpa, que
contendría el registro PTR del recurso de 2 (es decir, 157.55.200.2). Existen zonas primarias y
secundarias para acumular estos registros. Se denominan “zonas inversas”.
En el gráfico siguiente se muestra un ejemplo de una consulta inversa iniciada por un cliente DNS
(host-b) para aprender el nombre de otro host (host-a) basándose en su dirección IP, 192.168.1.20.
El proceso de búsqueda inversa que se muestra en este gráfico se produce en los siguientes pasos:
1. El cliente, "host-b", consulta al servidor DNS un registro de recursos de puntero (PTR) que
asigna la dirección IP 15.16.192.152 a "host-a".
29
Ya que esta consulta se realiza en los registros de puntero, el resolver invierte la dirección y
agrega el dominio in-addr.arpa al final de la dirección inversa. De esta manera, forma el
nombre de dominio completo ("15.16.192.152.in-addr.arpa.") que se va a buscar en una
zona de búsqueda inversa.
Una vez localizado, el servidor DNS con autoridad en "15.16.192.152.in-addr.arpa" puede

responder con la información del registro de puntero PTR. Esto incluye el nombre de dominio
DNS para "host-a", lo que completa el proceso de búsqueda inversa.
30
Formato del mensaje DNS
El mensaje DNS tiene cinco secciones como se muestra en la figura.
• El header o encabezamiento contiene información tal como tipo de mensaje, y que

secciones están presente en el mensaje.
• La sección de ¨question¨ o consulta, indica el nombre o dirección que se desea resolver.
Las tres últimas secciones son completadas con registros RR relativos a la consulta.
• La sección änswer¨ o respuesta contiene el RR sobre el cual se consulta.
• La sección äuthority¨ se completa con el RR SOA ó el RR NS de la zona donde se extrae
el RR de la respuesta.
• En la sección ädditional¨ se envía información adicional a la consulta realizada.
HEADER QUESTION ANSWER AUTHORITY ADDITIONAL
Respuestas de consultas
Las consultas en general pueden generar varios tipos de respuestas. Las más habituales son:
• Una respuesta con autoridad

• Una respuesta positiva
• Una respuesta de referencia
• Una respuesta negativa
Una respuesta con autoridad es una respuesta positiva devuelta al cliente y entregada con el bit de
autoridad activado en el mensaje DNS para indicar que la respuesta se obtuvo de un servidor con
autoridad directa para el nombre consultado.
Una respuesta positiva puede estar formada por el registro de recursos consultado o por una lista
de registros de recursos (también llamada RRset) que se ajusta al nombre de dominio DNS
consultado y el tipo de registro especificado en el mensaje de la consulta.
Una respuesta de referencia contiene registros de recursos adicionales no especificados por el

nombre o el tipo de la consulta. Si el proceso de recursividad no se admite, se devuelve al cliente
este tipo de respuesta. Los registros deben actuar como respuestas de referencia útiles que el
cliente puede utilizar para continuar la consulta mediante la iteración.
Una respuesta de referencia contiene datos adicionales como registros de recursos (RR) distintos
de los del tipo consultado. Por ejemplo, si el nombre de host consultado era "www" y no se
encontró ningún registro de recursos de dirección (A) para este nombre en esta zona pero, en su
lugar, se encontró un registro de recursos de CNAME para "www", el servidor DNS puede incluir
esa información cuando responda al cliente.
Si el cliente puede utilizar la iteración, puede hacer consultas adicionales con la información de
referencia en un intento de resolver completamente el nombre por sí mismo.
31
Una respuesta negativa del servidor puede indicar que se encontró uno de los dos resultados
posibles mientras el servidor intentaba procesar y resolver de forma recursiva la consulta
completamente y con autoridad:
• Un servidor con autoridad informó de que el nombre consultado no existe en el espacio de

nombres DNS.
• Un servidor con autoridad informó de que el nombre consultado existe, pero no existen
registros del tipo especificado para ese nombre.
El resolver devuelve el resultado de la consulta, en forma de respuesta positiva o negativa, al

programa solicitante y almacena en caché la respuesta.
Si la respuesta resultante de una consulta es demasiado larga para poderla enviar y resolver en un
sólo paquete de mensaje UDP, el servidor DNS puede iniciar una respuesta de conmutación por
error a través del puerto 53 de TCP para responder al cliente completamente en una sesión
conectada de TCP.
Generalmente, se deshabilita el uso de la recursividad en un servidor DNS cuando los clientes

DNS se limitan a la resolución de nombres contenidos en un servidor DNS específico, como el que
se encuentra en una intranet. También se puede deshabilitar la recursividad cuando el servidor
DNS no puede resolver nombres DNS externos y se espera que los clientes conmuten por error a
otro servidor DNS para la resolución de estos nombres.
Si deshabilita la recursividad en el servidor DNS, no podrá utilizar forwarders dicho servidor.
De forma predeterminada, los servidores DNS utilizan varios tiempos predeterminados cuando
realizan una consulta recursiva y se ponen en contacto con otros servidores DNS. Son los
siguientes:
o Un intervalo de reintento de recursividad de tres segundos. Éste es el tiempo que

espera el servicio DNS antes de reintentar una consulta realizada durante una
búsqueda recursiva.
o Un intervalo de tiempo de espera de recursividad de quince segundos. Se trata del
tiempo que espera el servicio DNS antes de dar como errónea una búsqueda
recursiva que se ha reintentado.
En la mayor parte de los casos, no es necesario ajustar estos parámetros. Sin embargo, si utiliza
búsquedas recursivas en un vínculo WAN de baja velocidad, es posible que pueda mejorar el
rendimiento del servidor y la resolución de la consulta realizando pequeños ajustes en estos
valores.
32
Actualización dinámica
El servicio DNS tradicional es estático en el sentido que las zonas solo se pueden cambiar
mediante intervención manual del administrador en el servidor primario. Sin embargo actualmente
existe la posibilidad de la actualización dinámica o sea la modificación de una zona sin la
intervención del administrador.
La actualización dinámica permite a los equipos cliente DNS (computadora que usa el servicio
DNS) guardar y actualizar dinámicamente sus registros de recursos (los propios del cliente) en un
servidor DNS siempre que se produzcan cambios. Esto disminuye la necesidad de administrar de
forma manual los registros de zona, especialmente para los clientes que mueven o cambian
ubicaciones con frecuencia y utilizan DHCP (servicio de asignación de direcciones IP en forma
dinámica) para obtener una dirección IP.
Los servicios de Cliente y Servidor DNS admiten el uso de actualizaciones dinámicas, tal como
se describe en el documento solicitud de comentarios (RFC) 2136, "Actualizaciones dinámicas en
el Sistema de nombres de dominio".
El servicio Servidor DNS permite habilitar o deshabilitar la actualización dinámica por zonas en
cada servidor configurado para cargar una zona principal estándar o integrada en directorio.
De forma predeterminada, el servicio de Cliente DNS actualizará dinámicamente los registros de

recursos (RR) de host (A) en DNS, cuando esté configurado estáticamente para TCP/IP.
La actualización también puede hacerse con la intervención del servidor DHCP en las redes de
configuración dinámica del protocolo TCP/IP.
Las actualizaciones dinámicas se pueden enviar por cualquiera de las siguientes razones o sucesos
que modifican la configuración de un servidor DHCP:
• Se agregó, quitó o modificó una dirección IP en la configuración de propiedades de TCP/IP

para una de las conexiones de red instaladas.
• Una concesión de dirección IP cambia o renueva con el servidor DHCP cualquiera de las
conexiones de red instaladas. Por ejemplo, cuando se inicia el equipo.
• Cuando se usa un comando para forzar manualmente una actualización del registro de
nombres de clientes en DNS.
• En el inicio, cuando se enciende el equipo.
Cuando uno de los sucesos anteriores activa una actualización dinámica, el servicio Cliente
DHCP (no el servicio Cliente DNS) envía las actualizaciones.
Este proceso se ha diseñado de forma que, si se produce un cambio en la información de la

dirección IP a causa de DHCP, se realicen las actualizaciones correspondientes en DNS para
sincronizar las asignaciones de nombre a dirección para el equipo. El servicio Cliente DHCP
realiza esta función para todas las conexiones de red utilizadas en el sistema, incluidas las
conexiones no configuradas para utilizar DHCP.
33
También se puede utilizar el servidor DHCP para registrar y actualizar los registros de recursos de
punteros (PTR) y de direcciones (A) en nombre de sus clientes habilitados para DHCP.
Este proceso requiere la utilización de una opción de DHCP adicional. Esta opción permite que el
cliente proporcione su nombre de dominio completo (FQDN), así como instrucciones al servidor
DHCP acerca de cómo desea que el servidor procese las actualizaciones dinámicas de DNS (si las
hubiera) en su nombre.
Cuando esta opción la emite un cliente DHCP calificado, los servidores DHCP la procesan y la
interpretan para determinar la forma en que el servidor iniciará las actualizaciones en nombre del
cliente.
34
Seguridad para el servicio DNS
Las extensiones de seguridad realizadas a DNS en DNSSEC (RFC 2535) ofrecen servicios para
realizar la autenticación de origen de datos y la comprobación de integridad. Estos servicios
permiten cifrar firmas digitales (hash de un RR) utilizando claves privadas y enviarlas como
registros de recursos desde servidores DNS que alojen zonas firmadas (compatibles con DNSSEC)
a interpretadores (resolvers) en los que se puedan autenticar los registros de recursos utilizando
claves públicas.
En otras palabras, cada registro de recurso (RR) tiene un registro adicional (registro SIG) que
contiene la firma digital de dicho recurso. Dicha firma digital se comprueba mediante una llave
pública de la zona (ZSK o Zone Signing Key) para verificar la autenticidad e integridad del RR.
Tanto las firmas digitales como las claves públicas se agregan a una zona firmada en forma de
registros de recursos.
El servicio DNSSEC provee mecanismos para proteger la comunicación entre servidores y

mecanismos para proteger los datos contenidos en las zonas de los servidores primarios y
secundarios, o sea en aquellos que tienen autoridad sobre la zona que se desea proteger. En la
figura se muestra en color verde la trayectoria de los datos.
En la figura se muestran las partes afectadas por posibles problemas de seguridad. El servidor DNS
de reenvío es el resolver DNSSEC que permite adquirir datos DNS seguros y proporcionárselos a
los clientes que son resolvers comunes que no trabajan con DNSSEC.
Los casos 2, 3 y 4 tienen que ver con la transferencia de datos y el caso 1 con la seguridad de los
datos almacenados.
Seguridad en la transferencia de datos
Se usa el mecanismo conocido como Transaction Signatures (TSIG) que consiste en definir una
clave secreta que debe ser compartida entre transmisor y receptor. Existen herramientas que
permiten generar las claves. La distribución de las claves debe realizarse mediante medios extraños
35
a DNSSEC por el momento. Por ejemplo mediante una comunicación telefónica o mediante correo
protegido por PGP. Dicha clave debe incluirse en el archivo o base de datos que conforma la
configuración del servidor DNS que tiene DNSEC activada. Esto debe realizarse en ambos
servidores, transmisor (fuente de los datos) y el receptor (servidor primario DNS o secundario
DNS).
Hay que tener en cuenta que los servidores participantes son de la misma empresa y deben estar
autenticados unos con otros, para no permitir la participación de terceros que pueden generar
inseguridades. Debido a que los servidores se reconocen mutuamente no es necesaria la utilización
de criptografía pública. Se emplea la criptografía de clave secreta por ser la mas adecuada en este
caso.
Seguridad de los datos almacenados
Se aplica a la información almacenada. Tanto las claves privadas como las públicas están
asociadas a zonas específicas y no a los servidores DNS que alojen dichas zonas.
Las características de DNSSEC aquí descritas, o en RFC 2535, no son totalmente compatibles con
varios servidores DNS actuales. Por ejemplo, el servidor DNS de Windows Server 2003
proporciona solamente "compatibilidad básica" del protocolo de Extensiones de seguridad de DNS
(DNSSEC) tal como se define en el documento RFC 2535.
Autenticación de los datos
En DNSSEC, cada zona tiene su propia clave pública y privada utilizada para cifrar y descifrar
firmas digitales.
Una zona cifrada o segura es una zona DNS que tiene tanto clave privada como pública. Cuando
un conjunto de registros de recursos (RR) de una zona está firmado con una clave privada, los
interpretadores que contienen la clave pública de la zona pueden autenticar si un RR recibido de la
zona está autorizado.
En realidad la firma digital se aplica a un conjunto de registros (RRSeset) y no a un registro RR

para lograr mayor eficiencia. Sin embargo un RRSeset puede estar constituido por un solo RR.
SE define un RRSeset como el grupo de RRs que tienen un mismo nombre (propietario), misma
clase y mismo tipo.
Todo servidor primario DNS debe generar su par de claves pública y privada que usara para firmar
los RRs de la zona. Dicha clave es la que llamamos ZSK o Zone Signing Key. La clave pública se
publica en la zona correspondiente y la clave privada se guarda en un archivo de máxima
seguridad.
Cuando un servidor DNS responde positivamente a una consulta de un nombre DNS, contesta con
los registros de recursos solicitados y los RR de recursos SIG que corresponden a cada RR. Los
interpretadores que conozcan la clave pública asociada al nombre solicitado reciben el registro de
recurso SIG y utilizan la clave pública para autenticar los registros de recursos.
36
La clave pública de la zona se almacena en un nuevo tipo de registro de recursos, KEY, en el

archivo de zona del servidor primario o secundario.
Se deben proporcionar los registros de recursos KEY al interpretador (resolver) antes de que este
pueda autenticar registros de recursos SIG. La obtención de esta clave pública en el caso más
simple se obtiene fuera de banda o sea por algún mecanismo extraño a DNSSEC. Luego veremos
que en el caso general, la clave ZSK se obtiene mediante el protocolo DNSSEC (tenga en cuenta
que DNSSEC es el mismo protocolo DNS con agregados de seguridad que estamos comentando).
Tenga en cuenta que el resolver o interpretador debe basarse en una llave que provenga de un
mecanismo que le proporcione confianza. En las conexiones 2 y 3 de la figura anterior se establece
un canal seguro mediante el secreto compartido entre los servidores. En el caso 4 (los servidores
no tienen relación de confianza) no existe tal canal seguro. Tampoco se usa PKI (infraestructura de
llave pública) para garantizar que la llave pública en poder del resolver sea la auténtica. Por eso en
el caso más simple debe usarse un medio seguro para la distribución de la clave pública, y hasta
ese momento DNS no lo es. Una vez que el resolver tiene la llave pública recién entonces
comienza el mecanismo DNSSEC.
RR especiales
Existen muchas consideraciones especiales en DNSSEC que utilizan registros de recursos de

DNSSEC de forma diferente al uso convencional de los registros de recursos.
Registro tipo KEY
Descripción: Registro de recurso de clave pública. Contiene una clave pública asociada a una
zona. En la implementación DNSSEC completa, los interpretadores y servidores utilizan los
registros de recursos KEY para autenticar los registros de recursos SIG recibidos de zonas
firmadas. Los registros de recurso KEY, a su vez, están firmados por la zona padre, permitiendo
que cualquier servidor que conozca la clave pública de la zona padre pueda descubrir y verificar
la clave KEY de la zona hija. Los servidores o interpretadores de nombre que reciben registros de
recurso desde una zona firmada, obtienen los registros SIG correspondiente a los RR y, después, el
registro KEY de la zona.
Sintaxis:
propietario clase KEY flags protocolo algoritmo_de_firma_digital clave_pública
Ejemplo: se indica en la siguiente figura
37
Registro tipo SIG

Descripción: Registro de recursos de firma. Firma un RR (realiza un hash del contenido del
recurso y lo cifra con la clave privada de la zona) y un intervalo de validez.
Sintaxis: propietario ttl clase SIG tipo algoritmo num. de rotulos ttl
caducidadFirma expediciónFirma identificadorClave nombreFirmante {firmaDigital}
Ejemplo: se indica en la siguiente figura
Registro tipo NXT

Descripción: Siguiente registro de recursos. Los registros de recursos NXT permiten verificar la
inexistencia de un nombre en una zona, mediante la creación de una cadena de todos los nombres
38
de recursos literales de dicha zona. También indican los tipos de registro de recursos presentes en
un nombre existente.
Sintaxis:
propietario clase NXT NombreDominioSiguiente UltimoTipoRecurso NXT
Ejemplo: dom1.dom.pepe.com. IN NXT ftp.dom.pepe.com. A NXT
Indica que el siguiente registro es el de ftp.dom.pepe.com, y que el presente nombre o propietario

tiene los tipos A y NXT. De esta forma cada registro anuncia el siguiente y de esa forma se
garantiza la coherencia de la zona que permite garantizar la ausencia de un registro.
En las siguientes figuras podemos apreciar la diferencia entre una zona sin firmar y una zona
firmada.
• Zona sin DNSSEC (zona sin firma):
$TTL 100
$ORIGIN my.dom.
@ 100 IN SOA localhost.root.localhost. (

2002050501 ; serial number
100 ; refresh period
200 ; retry refresh this often
604800 ; expiration period
100 ) ; minimum Time To Live (TTL)
my.dom. IN NS ns.my.dom.
secondary.my.dom IN A 192.168.1.1
• Zona con DNSSEC (zona firmada):
my.dom.
100 IN SOA localhost.root.localhost. (
2002050501; serial
10 ; refresh (1 minute 40 seconds)
200 ; retry (3 minutes 20 seconds)
604800 ; expire (1 week)
100 ; minimum (1 minute 40 seconds)
)
100 SIG SOA 3 2 100 20040902093054 (
20040803093054 8987 my.dom.
BIXpbP5zrJxniT/E6gM4kliupdLQqLFJm+VK
DpLbcm1JOjz3nq21cjM= )
100 NS ns.my.dom.
100 SIG NS 3 2 100 20040902093054 (
20040803093054 8987 my.dom.
BIjE6ogFfsY0V8qYoCF+p17ksrnKagiKHIk7
GkL2eA13Gowf7zAh6io= )
100 KEY 256 3 3 (
BM8d6185SU4ba815a6T2s4f8jNK14EOplnQ4
K7jEc5UAs3UT+yiIvps0HC2gyoRvpwVf798r
161zZBdGtoQ3rRqjoJLbHCI+tDKxtk7GbLFV
2bIRBhau7lXbLBf+5ci8id6wvun8nxJjZLaY
8KPFBPD1ocQh3NqZLqefGPoS8XXHcBypHE/c
39
r7ZFjaUqgn8BMzBN4COV6PkbM+bvZFogfsOL
Vt6ToU89fnDztYpMvx5qdDDYG/aLC8kYz95i
GNnc8v76qNrAb1GCccYArZ9TtAwf11mZaqQL
07r5oCbByzdQuo+YY3t+maOWL0DcG2P4snPZ
2rlP2Mf2/AR9qpjUTeNU5SYbIuVaso2wtmFt
r1Y9xlYZqdq6nXcr1+8uknVpJRjWlIXCWoJZ
ktBk38Af6Bp2GX9V
) ; key id = 8987
100 NXT secondary.my.dom NS SOA SIG KEY NXT
100 SIG NXT 3 2 100 20040902093054 (
20040803093054 8987 my.dom.
BEckizFAreqKu8sgrKYSVkMdVJCQKMyF6eY9
4ZIVb5ohuFXIdj8M/Kk= )
secondary.my.dom.
100 IN A 192.168.1.1
100 SIG A 3 5 100 20040902093054 (
20040803093054 8987 my.dom.
BBh+ePXrvgfOoz71V4bmN5cJyCoxOI3mbT3R
9VIqtYWGNYvHbd2kaAE= )
100 NXT my.dom. A SIG NXT
100 SIG NXT 3 5 100 20040902093054 (
20040803093054 8987 my.dom.
BDDwUk/0INxaFlmwbceHDldT4GGhfYUUGIv+
hH7lnPI+5chIS024f+w= )
Como se firma una zona
Firmar una zona consiste en obtener un archivo con las características del mostrado en la figura
anterior. Los pasos a realizar son los siguientes.
• Generar las claves pública y privada de la zona

• Disponer de una zona sin firmar
• Usar una herramienta a la que se le indican los puntos anteriores (no se indica la clave
privada).
De esta forma se obtiene la zona firmada. Como vemos los registros SIG, KEY y NXT son
incluidos por la herramienta. Cuando se debe modificar la zona se procede de la siguiente manera:
• Modificar la zona
• Ejecutar la herramienta indicando el nombre del archivo de zona actualizado.
Algoritmos de cifrado
En la siguiente tabla se muestran los posibles algoritmos de cifrado, indicándose además la

longitud máxima en bites, de la clave.
40
Generación de claves
Cada sistema operativo dispone de herramientas para la generación de claves. A continuación se

muestra el uso del comando dnssec-keygen de Linux para generar una clave ZSK para la zona
my.dom.
# dnssec-keygen -a DSA -b 768 -n ZONE my.dom
Kmy.dom.+003+08987
DSA es el algoritmo de cifrado de clave pública, 768 es la longitud de la clave y my.dom es el

nombre de la zona. En la salida del comando, 003 es el número del algoritmo DSA, 08987 es la
identificación o tag de la clave.
Para ver el contenido del archivo que contiene la clave pública:
# cat Kmy.dom.+003+08987.key
my.dom. IN KEY 256 3 3
BM8d6185SU4ba815a6T2s4f8jNK14EOplnQ4K7jEc5UAs3UT+yiIvps0
HC2gyoRvpwVf798r161zZBdGtoQ3rRqjoJLbHCI+tDKxtk7GbLFV2bIR
Bhau7lXbLBf+5ci8id6wvun8nxJjZLaY8KPFBPD1ocQh3NqZLqefGPoS
8XXHcBypHE/cr7ZFjaUqgn8BMzBN4COV6PkbM+bvZFogfsOLVt6ToU89
fnDztYpMvx5qdDDYG/aLC8kYz95iGNnc8v76qNrAb1GCccYArZ9TtAwf
11mZaqQL07r5oCbByzdQuo+YY3t+maOWL0DcG2P4snPZ2rlP2Mf2/AR9
qpjUTeNU5SYbIuVaso2wtmFtr1Y9xlYZqdq6nXcr1+8uknVpJRjWlIXC
WoJZktBk38Af6Bp2GX9V
El contenido del archivo es exactamente el registro KEY que se incluye en el

archivo de zona. La cadena de caracteres del último párrafo muestra la clave
pública.
Para ver el contenido del archivo de la clave privada:
#cat Kmy.dom.+003+08987.private
Private-key-format: v1.2
Algorithm: 3 (DSA)
Prime(p):
4EOplnQ4K7jEc5UAs3UT+yiIvps0HC2gyoRvpwVf798r161zZBdGtoQ3rRqj
oJLbHCI+tDKxtk7GbLFV2bIRBhau7lXbLBf+5ci8id6wvun8nxJjZLaY8KPFBPD1ocQh
Subprime(q):
zx3rXzlJThtrzXlrpPazh/yM0rU=
Base(g):
3NqZLqefGPoS8XXHcBypHE/cr7ZFjaUqgn8BMzBN4COV6PkbM+bvZFogfsOL
Vt6ToU89fnDztYpMvx5qdDDYG/aLC8kYz95iGNnc8v76qNrAb1GCccYArZ9TtAwf11mZ
Private_value(x):
nVisc+b5n2oXbDF5zpGWSHocgAo=
Public_value(y):
aqQL07r5oCbByzdQuo+YY3t+maOWL0DcG2P4snPZ2rlP2Mf2/AR9qpjUTeNU
41
5SYbIuVaso2wtmFtr1Y9xlYZqdq6nXcr1+8uknVpJRjWlIXCWoJZktBk38Af6Bp2GX9V
Firma de una zona DNS
A continuación veremos el procedimiento de firma de una zona DNS para la aplicación BIND 9
(servicio DNS) de LINUX.
• Incluir en la zona DNS el contenido del archivo .key que contiene la llave pública de la
clave ZSK. Se agrega al final del archivo de zona la sentencia include, con el nombre del
archivo .key como se muestra a continuación.
$TTL 100
$ORIGIN my.dom.
@ 100 IN SOA localhost.root.localhost. (

2002050501 ; serial number
100 ; refresh period
200 ; retry refresh this often
604800 ; expiration period
100 ) ; minimum Time To Live (TTL)
my.dom.
IN NS ns.my.dom.
secondary.my.dom IN A 192.168.1.1
$include Kmy.dom.+003+08987.key
• Ejecutar el comando dnssec-signzone, indicando el nombre de la zona

(my.dom) y el archivo de zona mostrado en la figura anterior (db.my.dom)
# dnssec-signzone -o my.dom db.my.dom
Como resultado de este comando se genera el archivo .signed, db.my.dom.signed que

contiene la zona firmada de acuerdo a la figura que muestra la zona firmada que vimos
anteriormente. De esta forma obtenemos el nuevo archivo de zona que es el que se usara en
DNS o mejor dicho en DNSSEC. El comando anterior se ocupa de ordenar alfabéticamente
la zona e incluir los registros KEY, SIG y NXT.
Configuración del servidor DNS de reenvío
La configuración del servidor DNS de reenvío (caching forwarder) consiste en lo siguiente:
• Habilitar DNSSEC en el servidor DNS

• Incluir en algún archivo o base de datos de configuración, la clave pública de la zona (para
todas las zonas de confianza).
El formato de la consulta y la respuesta DNSSEC
También la transferencia de datos entre cliente y servidor es mas compleja como se muestra en la
siguiente figura cuando tenemos habilitado el DNSSEC. El servidor DNS de reenvio (caching
42
forwarder) es el servidor dns.iua.edu.ar, que actua como resolver DNSSEC y que alimenta con
respuestas DNS a los resolvers DNS de la institución.
Vemos que la clave ZSK se envía con la respuesta siempre que quepa dentro de los límites del
mensaje ya que este está limitado.
Si el resolver no dispone de la clave ZSK o esta no esta actualizada podrá requerir mediante otra
consulta la clave que le hace falta.
43
Crear un esquema de seguridad global
Hasta ahora nuestro DNSSEC se basa en la confianza de la clave ZSK, pero esto trae como
resultado los siguientes inconvenientes.
• En un ambiente seguro se debe confiar solo en algunos servidores que realmente nos
garanticen seguridad, no en todos los servidores DNS.
• Para tener seguridad la longitud de las claves debe ser elevada. Esto trae como
consecuencia el crecimiento de los archivos de zona y lentitud en el servicio DNS.
Para solucionar estos problemas:
• Se crea el concepto de la clave KSK (Key Signing Key) que se usa para firmar claves de
zona o ZSKs. Esta clave es de una longitud máxima (lo que permita el algoritmo) ya que en
esta clave se basa la seguridad. Tiene un tiempo de vida que va de varios meses a varios
años.
• Las claves ZSKs se eligen cortas (mejora la velocidad del servicio y el archivo de zona es
menos voluminoso) y se rotan periódicamente por seguridad (concepto que se conoce como
Key Rollover). Tienen un tiempo de vida de varios días.
• La llave KSK (base de la seguridad) se usa para garantizar seguridad en algún punto del
árbol DNS (lo ideal sería en root) que se conoce como ¨punto de entrada en la cadena de
confianza¨. Ese punto seguro otorga (en forma segura) la clave pública ZSK de la zona hija
firmada por su KSK en la cual se confía. De esta forma se puede navegar en forma segura
el árbol DNS (o DNSSEC) de arriba hacia abajo partiendo de una zona que nos garantice
seguridad con su KSK. Como vemos se está usando el protocolo DNS (o DNSSEC en
realidad) para la distribución de claves públicas KSK (ya que no usamos PKI). De esta
forma también sería posible el uso de DNSSEC para distribuir claves para otros protocolos
como IPSec y SSH por ejemplo. Una vez que se arriba (luego de la navegación desde el
punto seguro) al servidor que tiene autoridad del recurso que se busca, con su KSK
(obtenida de la zona padre) se verifica su ZSK, y con esta ZSK se verifica la firma del
recurso buscado.
• Cada zona crea su propia KSK (pública y privada). Con la clave privada de esta KSK firma
la ZSK pública. En realidad con KSK se firma el conjunto de llaves de una zona que está
formado por su KSK y una o varias ZSK.
• Una vez que la ZSK está firmada, se envía la clave pública de la KSK a la zona padre
donde se guarda en un nuevo registro para tal fin denominado DS (Delegation Signature)
para constituir lo que se denomina ¨delegación de firma¨.
• La zona padre hace lo mismo con sus KSK y ZSK (envía la KSK a su zona padre) y así
sucesivamente hasta alcanzar la zona que se constituye como punto de entrada de la cadena
de confianza.
• La clave pública KSK de esta última zona se distribuye por un mecanismo seguro (fuera
del protocolo DNSSEC) a los resolvers DNSSEC que son clientes de esta cadena de
confianza.
En la siguiente figura se muestra en una forma simplificada las zonas padre e hija en donde se
relacionan los contenidos de los registros DS y KEY (de una KSK). En vez de las claves públicas
se indican los identificadores de estas claves.
44
Vemos que en la zona padre, el registro DS contiene como dato la KSK del dominio kids.net, y el
número 1234 es el identificador de la KSK de la zona hija kids.net.
El registro: SIG key … 1234 kids.net. ….. Indica que se trata de la firma del conjunto de
registros key , y que está firmado por la llave 1234.
A su vez el registro: SIG A (...) 3456 kids.net. Indica que esta firmado por la clave 3456 o sea
esa es la ZSK.
También vemos que el registro: SIG key … 3456 Kids.net. Indica que se trata de la firma del
conjunto de registros key , y que está firmado por por la llave 3456. Como vemos el conjunto de
registros de las claves tiene una firma con cada clave, donde una de ellas es la KSK y el resto son
ZSKs.
Navegación desde el punto de confianza
En la figura se muestra la navegación desde el punto de confianza. Por simplicidad no se muestran

los registros NS que posibilitan las localizaciones de los servidores DNS y los registros A de
dichos servidores que posibilitan la localización de los servidores en Internet.
45
Rotación de las claves KSK y ZSK
Para mayor seguridad también se pueden rotar las claves KSK, pero ello implica una estrategia de
distribución de claves por un método extraño a DNS como se indicó previamente. La ubicación de
las claves en los registros DS es previa al funcionamiento seguro de DNSSEC.
Tanto la rotación de claves ZSK y KSK implica una estrategia adicional para permitir que registros
firmados que todavía están en los caché puedan verificarse tanto con claves ¨viejas¨como con
claves ¨nuevas¨ para no rechazar registros correctos pero firmados con una de las dos llaves y
verificado por la otra.
Esta estrategia debe contemplar la vigencia de las dos claves ¨vieja¨ y ¨nueva¨ en el archivo de
zona por un determinado tiempo (que tiene que ver con los valores de los tiempos de vida de los
recursos y de las claves) con las respectivas firmas (cada recurso se firma con ambas claves). Esto
se hace mediante la herramienta dnssec-signzone.
46
Configuración del servicio DNS y DNSSEC
Veremos a continuación los pasos que debe realizar el administrador del servicio DNS para
configurar el servicio DNS en un servidor de Internet o de una intranet.
Configuración básica TCP/IP
Configurar las propiedades del protocolo TCP/IP que habilitan al servidor conectarse con otras
redes e Internet.
• Dirección IP
• Máscara de sub-red
• Dirección de difusión
• Nombre de Host
• Nombre de dominio DNS al que pertenece
• Dirección IP de un servidor de nombres
• Dirección IP del ruteador por defecto (puerta de enlace)
Configuración del servicio DNS propiamente dicho
• Instalar la aplicación del servicio DNS

• Activar el servidor DNS
• Activar y verificar el archivo de los Root-Servers
• Crear los archivos de zona directa
• Crear los archivos de zona inversa
• Activar/verificar la posibilidad de búsquedas recursivas e iterativas
• Definir la confianza con los servidores secundarios
• Definir las direcciones IP de los forwarders
• Activar/verificar la opción para notificar a los secundarios de cambios en las zonas
• Activar/verificar la actualización dinámica (opcional)
Configuración de DNSSEC:
• Realizar la configuración convencional DNS

• Crear las llaves KSK y ZSK
• Firmar las zonas
• Configurar TSIG con los servidores secundarios
• Enviar en forma segura la llave pública KSK a la zona padre
• Realizar periódicamente la rotación de claves (“key rollover”) de las claves KSK y ZSK.
[1]
Explique en forma resumida en que consiste el Servicio DNS.
47
[2]
Explique la diferencia entre un servidor primario y un secundario
[3]
Explique que es un servidor DNS de solo cache.
[4]
Indique las diferencias entre una zona y un dominio
[5]
Explique que es una zona directa y que es una zona inversa.
[6]
Indique cinco registros de recursos que crea más comunes.
[7]
Explique que es un archivo de zona.
[8]
Explique que es un servidor forwarder y cuando se aconseja su uso.
[9]
Explique que son los root-servers.
[10]
Explique como es posible que un cliente conectado a Internet desde cualquier parte del mundo
pueda obtener la dirección IP de un nombre DNS remoto.
[11]
Explique las diferencias entre consulta recursiva y consulta iterativa.
48
[12]
Explique la diferencia entre DNS y DDNS (DNS dinámico).
[13]
Explique en que se basa la seguridad que ofrece DNSSEC.
[14]
Explique que es una clave ZSK
[15]
Explique que es una clave KSK.
[16]
Explique que significa firmar digitalmente una zona.
[17]
Explique en que consiste una rotación de clave ZSK.
[18]
Explique a que se le llama servidor DNS de reenvío/resolver DNSSEC.
[19]
Resuma en que consiste la configuración de un cliente DNS
[20]
Resuma en que consiste la configuración de un servidor DNS
49
6.2 El protocolo DHCP
DHCP (Dynamic Host Configuration Protocol) son las siglas que identifican a un protocolo
empleado para que los hosts (clientes) en una red puedan obtener su configuración TCP/IP en
forma dinámica a través de un servidor.
Los datos así obtenidos pueden ser: la dirección IP, la máscara de red, la dirección de broadcast,
las características del DNS, entre otros.
El servicio DHCP permite acelerar y facilitar la configuración de muchos hosts en una red
evitando en gran medida los posibles errores humanos. También permite simplificar
administrativamente la actualización de la configuración de los hosts evitando que el administrador
se desplace físicamente ubicando los hosts para su configuración y/o re-configuración.
Con una función similar a la del DHCP, pero con algunas restricciones, existe el BOOTP o
Internet Bootstrap Protocol, el cual permite también la asignación de la configuración de red en
forma dinámica pero a partir de su definición estática para cada cliente en una base de datos en el
servidor. Esta información a diferencia de como se hace usualmente con DHCP no puede ser
renovada.
Básicamente el servicio DHCP/BOOTP funciona de la siguiente forma. Existe un programa

servidor en un host de la red que escucha las solicitudes de los clientes y que en su configuración
almacena tablas de posibles direcciones IP a otorgar además del resto de la información del
protocolo. Cuando un cliente requiere del servicio envía una solicitud en forma de broadcast a
través de la red.
Todos los servidores alcanzados por la solicitud responden al cliente con sus respectivas
propuestas, este acepta una de ellas haciéndoselo saber al servidor elegido, el cual le otorga la
información requerida. Esta información se mantiene asociada al cliente mientras este no desactive
su interfaz de red (posiblemente porque se apague la máquina) o no expire el plazo del ``contrato''
(lease time).
El plazo del ``contrato'' o concesión es el tiempo en que un cliente DHCP mantiene como propios
los datos que le otorgó un servidor. Este se negocia como parte del protocolo entre el cliente y el
servidor. Una vez vencido el plazo del contrato el servidor puede renovar la información del
50
cliente, fundamentalmente su dirección IP, y asignarle otra nueva o extender el plazo, manteniendo
la misma información. El cliente puede solicitar también la renovación o liberación de sus datos.
Terminología de DHCP
Término Descripción
Un ámbito es un conjunto de definiciones de configuración, donde
fundamentalmente se define el intervalo consecutivo de direcciones IP de una red o
rango de direcciones. Normalmente los ámbitos se asocian a una subred física de la
ámbito
red a la que se ofrecen los servicios DHCP. Los ámbitos proporcionan el medio
principal para que el servidor administre la distribución y asignación de direcciones
IP, así como los parámetros de configuración relacionados, a los clientes de la red.
Un superámbito es un agrupamiento administrativo de ámbitos que se puede
utilizar para admitir varias subredes IP lógicas en la misma subred física. Los
superámbitos sólo contienen una lista de ámbitos miembros o ámbitos secundarios
superámbito que se pueden activar juntos. Los superámbitos no se utilizan para configurar otros
detalles acerca de la utilización de los ámbitos. Para configurar la mayor parte de
las propiedades que utiliza un superámbito es necesario configurar individualmente
las propiedades de los ámbitos miembros.
Un intervalo de exclusión es una secuencia limitada de direcciones IP de un
intervalo de ámbito, excluida de las ofertas del servicio DHCP. Los intervalos de exclusión
exclusión aseguran que el servidor no ofrecerá las direcciones de estos intervalos a los
clientes DHCP de la red.
Tras definir un ámbito DHCP y aplicar intervalos de exclusión, las direcciones
conjunto de restantes forman el conjunto de direcciones disponibles del ámbito. El servidor
direcciones puede elegir cualquiera de las direcciones del conjunto para asignarla
dinámicamente a los clientes DHCP de la red.
Una concesión es un período de tiempo especificado por los servidores DHCP y
durante el cual un equipo cliente puede utilizar una dirección IP asignada. Cuando
se realiza una concesión a un cliente, la concesión está activa. Antes de que
concesión caduque la concesión, el cliente suele necesitar renovar la asignación de la
concesión de dirección en el servidor. Una concesión queda inactiva cuando caduca
o cuando se elimina del servidor. La duración de una concesión determina cuándo
caducará y la frecuencia con la que el cliente necesita renovarla en el servidor.
Utilice una reserva para crear una asignación de concesión de dirección definitiva
reserva por parte del servidor DHCP. Las reservas aseguran que un dispositivo de hardware
específico de la subred siempre podrá utilizar la misma dirección IP.
Los tipos de opciones (o simplemente opciones) son otros parámetros de
configuración del cliente que un servidor DHCP puede asignar al proporcionar
concesiones a los clientes DHCP. Por ejemplo, algunas opciones comúnmente
utilizadas incluyen las direcciones IP de las puertas de enlace predeterminadas
tipos de (enrutadores), y servidores DNS. Normalmente, estos tipos de opciones se habilitan
opciones y configuran para cada ámbito. Las herramientas de configuración DHCP también
permiten definir tipos de opciones predeterminadas que utilizarán todos los ámbitos
agregados y configurados en el servidor. La mayor parte de las opciones están
predefinidas a través del documento RFC 2132, pero se puede utilizar una
herramienta DHCP para definir y agregar tipos de opciones personalizadas si es
51
necesario.
Protocolo DHCP
Cuando el cliente DHCP arranca resulta evidente que ignora la configuración de red por lo que
necesita realizar las primeras comunicaciones mediante mensajes de difusión o broadcast. Esta
difusión y el resto de las comunicaciones se basan en 8 tipos de mensajes en DHCP, como se
muestra en la siguiente figura:
Representación simplificada del protocolo DHCP
1. El cliente hace un broadcast de un mensaje DHCPDISCOVER en su subred física. El

mensaje DHCPDISCOVER puede incluir algunas opciones como sugerencias de la
dirección de red, duración del arrendamiento, etc.
2. Cada servidor puede responder con un mensaje DHCPOFFER que incluye una dirección de
red disponible y otras opciones de configuración.
3. El cliente recibe uno o más mensaje DHCPOFFER de uno o más servidores. Elige uno
basándose en los parámetros de configuración ofertados y hace un broadcast de un mensaje
52
DHCPREQUEST que incluye la opción identificadora del servidor para indicar qué
mensaje ha seleccionado.
4. Los servidores reciben el broadcast de DHCPREQUEST del cliente. Los servidores no
seleccionados utilizan el mensaje como notificación e que el cliente ha declinado su oferta.
El servidor seleccionado vincula al cliente al almacenamiento persistente y responde con
un mensaje DHCPACK que contiene los parámetros de configuración para el cliente. La
combinación de las direcciones hardware y asignada del cliente constituyen un
identificador único de su arrendamiento y las usan tanto el cliente como el servidor para
identificar cualquier arrendamiento al que se haga referencia en un mensaje DHCP. El
campo "your IP address" en los mensaje DHCPACK se rellena con la dirección de red
seleccionada.
5. El cliente recibe el mensaje DHCPACK con parámetro de configuración. Realiza un
chequeo final de estos parámetros, por ejemplo con ARP para la dirección de red asignada,
y registra la duración del arrendamiento y el cookie de identificación de éste especificado
en el mensaje DHCPACK. En este punto, el cliente está configurado. Si el cliente detecta
un problema con los parámetros en el mensaje DHCPACK, envía un mensaje
DHCPDECLINE al servidor y reinicia el proceso de configuración. El cliente debería
esperar un mínimo de diez segundos antes de reiniciar este proceso para evitar un exceso de
tráfico en la red en caso de que se produzca algún bucle.
Si el cliente recibe un mensaje, reinicia el proceso de configuración.
6. Al cabo de un tiempo, puede elegir renunciar a su arrendamiento enviando un mensaje

DHCPRELEASE al servidor. El cliente especifica el arrendamiento al que renuncia
incluyendo sus direcciones hardware y de red
A continuación se listan los principales mensajes que se intercambian como parte del protocolo
DHCP y para que se emplea cada uno:
1. DHCPDISCOVER - mensaje de broadcast de un cliente para detectar los servidores.

2. DHCPOFFER - mensaje de un servidor hacia un cliente con una oferta de configuración.
3. DHCPREQUEST - mensaje de un cliente a un servidor para:
a) aceptar la oferta de un servidor determinado y por ende rechazar las otras

b) confirmar la exactitud de la información asignada antes del reinicio del sistema
c) extender el contrato de una dirección IP determinada
4. DHCPPACK - mensaje del servidor hacia un cliente para enviarle la configuración

asignada excluyendo la dirección IP que ya fue aceptada.
5. DHCPNAK - mensaje del servidor al cliente para indicar que la dirección que tiene
asignada es incorrecta (por ejemplo, cuando el cliente cambia de subred) o que el contrato
ha expirado.
6. DHCPDECLINE - mensaje del cliente para el servidor indicando que aún está usando una
dirección determinada.
7. DHCPRELEASE - mensaje del cliente para el servidor para indicar que renuncia a la
dirección otorgada y cancela lo que queda del contrato establecido anteriormente.
8. DHCPINFORM - mensaje del cliente para el servidor para pedir sus parámetros de
configuración excluyendo la dirección IP que ya tiene asignada.
53
Un servidor de DHCP puede identificar a cada cliente a través de dos formas fundamentales:
1. La dirección MAC (Media Access Control) de la tarjeta de red del cliente.

2. Un identificador que le indique el cliente.
Aunque la idea central del servicio DHCP es la dinamicidad de las direcciones IP asignadas no se
excluye la posibilidad de utilizar direcciones fijas para algunos hosts que por sus características lo
requieran, ejemplo de ello son las máquinas proveedoras de disímiles servicios como el correo
electrónico o el DNS. Este tipo de host utilizaría las ventajas del servicio para obtener el resto de
los datos que se pueden proveer mediante DHCP. En otras palabras es posible identificar a ciertos
hosts por sus direcciones MAC y asignarles a estas direcciones fijas ya pre-establecidas.
Diferencias entre BOOTP y DHCP
Hay importantes diferencias en la forma en que BOOTP y DHCP realizan la configuración del
host. La tabla siguiente compara y contrasta las características que varían en los dos protocolos.
BOOTP DHCP
Diseñado antes que DHCP. Diseñado después que BOOTP.
Diseñado para configurar equipos de la red que cambian
Pensado para configurar estaciones de
de ubicación frecuentemente (como los equipos portátiles)
trabajo sin disco con capacidades de
y que tienen discos duros locales y capacidades de inicio
inicio limitadas.
completas.
Las concesiones de direcciones IP de
Las concesiones de direcciones IP de DHCP dinámico
BOOTP dinámico caducan a los 30
caducan a los ocho días de forma predeterminada.
días de forma predeterminada.
Admite un número limitado de
parámetros de configuración de los Admite un conjunto mayor y extensible de parámetros de
clientes llamados extensiones de configuración de los clientes llamados opciones.
proveedor.
Describe un proceso de configuración
de inicio en dos fases, como se muestra
a continuación:
• Los clientes se ponen en

contacto con los servidores
BOOTP para realizar la Describe un proceso de configuración de inicio de una
determinación de direcciones y fase, en el que un cliente DHCP negocia con un servidor
la selección del nombre del DHCP para determinar su dirección IP y obtener otros
archivo de inicio. detalles de configuración inicial que necesita para
• Los clientes se comunican con funcionar en la red.
los servidores del Protocolo de
transferencia de archivos trivial
(TFTP, Trivial File Transfer
Protocol) para transferir el
archivo de imagen de inicio.
54
Los clientes DHCP no requieren que el sistema se reinicie

para volver a crear el enlace o renovar la configuración
Los clientes BOOTP no vuelven a con el servidor DHCP. En su lugar, los clientes entran
crear los enlaces con el servidor automáticamente en estado de renovación del enlace según
BOOTP ni renuevan la configuración intervalos de tiempo establecidos para renovar la
excepto cuando se reinicia el sistema. asignación de la dirección concedida con el servidor
DHCP. Este proceso se produce en segundo plano y es
transparente para el usuario.
Re-utilización una dirección de red previamente asignada
Si el cliente recuerda y desea usar una dirección de red previamente asignada se llevan a cabo los
siguientes pasos:
1. El cliente hace un broadcast de un mensaje DHCPREQUEST en su subred. Este mensaje

incluye la dirección de red del cliente.
2. Los servidores que conozcan los parámetros de configuración del cliente le responden con
un mensaje DHCPACK.
3. El cliente recibe el mensaje DHCPACK con parámetros de configuración. Efectúa un
último chequeo de estos y registra la duración del arrendamiento y el cookie de
identificación de este, especificado en el DHCPACK. En este punto, el cliente está
configurado.
Si el cliente detecta algún problema con los parámetros en el DHCPACK, envía un mensaje
DHCPDECLINE al servidor y reinicia el proceso de configuración solicitando una nueva
dirección de red. Si el cliente recibe un mensaje DHCPNAK, no puede reutilizar la
dirección que solicitó. En vez de eso debe pedir una nueva dirección reiniciando el proceso
de configuración descrito en Asignando una nueva dirección de red. El cliente puede elegir
renunciar a su arrendamiento de la dirección de red al enviar un mensaje DHCPRELEASE
al servidor. Identifica el arrendamiento al que renuncia con el cookie de identificación.
Nota: Un host debería usar DHCP para readquirir o verificar su dirección IP y sus parámetros de
configuración siempre que cambien los parámetros de su red local, por ejemplo en el arranque del
sistema o después de una desconexión de la red local, ya que la configuración de esta puede haber
cambiado sin que lo sepa el host o el usuario.
El formato del mensaje DHCP
A continuación vemos el formato del mensaje DCHP que usa tanto el cliente como el servidor para
intercambiar los mensajes mencionados.
55
Formato del mensaje DHCP
Code: Indica solicitud o respuesta

1 Request
2 Reply
HWtype: El tipo de hardware, por ejemplo:
1 Ethernet
6 IEEE 802 Networks
Length: Longitud en bytes de la dirección hardware. Ethernet y las redes en anillo usan 6,
por ejemplo.
Hops: El cliente lo pone a 0. Cada "router" que retransmite la solicitud a otro servidor lo
incrementa, con el fin de detectar bucles. El RFC 951 sugiere que un valor de 3 indica un
bucle.
Transaction ID: Número aleatorio usado para comparar la solicitud con la respuesta que
genera.
Seconds: Fijado por el cliente. Es el tiempo transcurrido en segundos desde que el cliente
inició el proceso de arranque.
Flags Field: El bit más significante de este campo se usa como flag de broadcast. Todos los
demás bits deben estar a 0; están reservados para usos futuros. Normalmente, los servidores
DHCP tratan de entregar los mensajes DHCPREPLY directamente al cliente usando
unicast. La dirección de destino en la cabecera IP se pone al valor de la dirección IP fijada
por el servidor DHCP, y la dirección MAC a la dirección hardware del cliente DHCP. Si
un host no puede recibir un datagrama IP en unicast hasta saber su propia dirección IP, el
56
bit de broadcast se debe poner a 1 para indicar al servidor que el mensaje DHCPREPLY se
debe enviar como un broadcast en IP y MAC. De otro modo, este bit debe ponerse a cero.
Client IP adress: Fijada por el cliente. O bien es su dirección IP real , o 0.0.0.0.
Your IP Address: Fijada por el servidor si el valor del campo anterior es 0.0.0.0
Server IP address: Fijada por el servidor.
Router IP address: Fijada por el "router" retransmisor si se usa retransmisión BOOTP.
Client hardware address: fijada por el cliente y usada por el servidor para identificar cuál
de los clientes registrados está arrancando.
Server host name: Nombre opcional del host servidor acabado en X'00'.
Nombre del archivo de arranque: El cliente o bien deja este campo vacío o especifica un
nombre genérico, como "router" indicando el tipo de archivo de arranque a usar. En la
solicitud de DHCPDISCOVER se pone al valor nulo. El servidor devuelve el la ruta de
acceso completa del archivo en una respuesta DHCPOFFER. El valor termina en X'00'.
Options: el campo de opciones consiste en parámetros marcados llamados opciones. Allí
se indican las opciones sugeridas por el cliente en una consulta de este o las opciones
ofrecidas por el servidor DHCP en una respuesta de este.
Agente relé DHCP
El computador Agente relé DHCP es un intermediario con protocolo Bootstrap (BOOTP) que re-
transmite mensajes en Protocolo DHCP entre los clientes DHCP y los servidores DHCP ubicados
en distintas redes IP. De esta forma es posible que clientes DHCP emitan su solicitud por difusión
y esta sea retransmitida a otra red mediante el agente de distribución (rele), para alcanzar
finalmente al servidor DHCP. El Agente relé DHCP cumple con la especificación RFC 1542,
"Clarifications and Extensions for the Bootstrap Protocol". En los segmentos de red IP que
contienen clientes DHCP, se requiere un servidor DHCP o un equipo que funcione como Agente
relé DHCP. Normalmente se configura el agente de distribución DHCP en los ruteadores que
comunican las redes con clientes DHCP.
Cómo funcionan los agentes de retransmisión
Un agente de retransmisión retransmite los mensajes DHCP y BOOTP que se difunden en una de
las interfaces físicas a las que está conectado, como por ejemplo un adaptador de red, a otras
subredes remotas a las que está conectado mediante otras interfaces físicas. La siguiente ilustración
muestra cómo el cliente C de la subred 2 obtiene una concesión de dirección DHCP del servidor
DHCP 1 de la subred 1.
57
El cliente DHCP C difunde un mensaje de descubrimiento DHCP/BOOTP (DHCPDISCOVER) en

la subred 2, como un datagrama del Protocolo de datagramas de usuarios (UDP, User Datagram
Protocol) mediante el conocido puerto 67 del servidor UDP (el número de puerto reservado y
compartido para la comunicación entre servidores BOOTP y DHCP).
1. El agente de retransmisión, en este caso un enrutador habilitado para retransmisiones

DHCP y BOOTP, examina en el encabezado del mensaje DHCP/BOOTP el campo de la
dirección IP de la puerta de enlace. Si el campo tiene la dirección IP de origen 0.0.0.0, el
agente lo rellena con la dirección IP del agente de retransmisión o del enrutador y reenvía
el mensaje a la subred remota 1, en la que está ubicado el servidor DHCP.
2. Cuando el servidor DHCP 1 de la subred remota 1 recibe el mensaje, busca en el campo de
dirección IP de la puerta de enlace un ámbito DHCP que pueda utilizar el servidor DHCP
para suministrar una concesión de dirección IP compatible con la dirección de red del
origen.
3. Si el servidor DHCP 1 tiene varios ámbitos DHCP, la dirección del campo de dirección IP
de la puerta de enlace identifica el ámbito DHCP del que ofrecerá una concesión de
dirección IP. Por ejemplo, si el campo de dirección IP de la puerta de enlace tiene la
dirección IP 10.0.0.2, el servidor DHCP comprueba, en el conjunto de ámbitos disponibles,
si existe un intervalo de direcciones que cumpla con la red IP de Clase A que contiene la
dirección de la puerta de enlace como host. En este caso, el servidor DHCP comprobaría si
existe un ámbito de direcciones entre 10.0.0.1 y 10.0.0.254. Si existe un ámbito
coincidente, el servidor DHCP selecciona una dirección disponible del ámbito para
utilizarla en una respuesta de oferta de concesión de dirección IP al cliente.
4. Si el servidor DHCP 1 recibe el mensaje DHCPDISCOVER, lo procesa y envía una oferta
de concesión de dirección IP (DHCPOFFER) directamente al agente de retransmisión
identificado en el campo de dirección IP de la puerta de enlace.
5. A continuación, el enrutador retransmite la oferta de concesión de dirección
(DHCPOFFER) al cliente DHCP. De forma similar, se retransmite un mensaje
DHCPREQUEST desde el cliente al servidor y un mensaje DHCPACK desde el servidor al
cliente, de acuerdo con la RFC 1542.
58
Configuraciones de los agentes de retransmisión
Este ejemplo muestra una configuración de un enrutador. El enrutador ejecuta un agente de

retransmisión que reenvía las solicitudes DHCP entre la subred A y la subred B. Normalmente, el
agente de retransmisión del enrutador, simplemente deberá estar configurado con la dirección IP
del servidor DHCP.
59
Planificación de redes DHCP
Este tema trata los siguientes problemas al planear redes DHCP.
• Cómo determinar el número de servidores DHCP que se deben utilizar

• Cómo admitir clientes DHCP en subredes adicionales
• Planear redes DHCP conectadas mediante enrutadores
• Otras consideraciones acerca del diseño de redes corporativas
Cómo determinar el número de servidores DHCP que se deben utilizar
Puesto que no existe un límite fijo para el número máximo de clientes a los que puede prestar
servicio un servidor DHCP ni para el número de ámbitos que se pueden crear en un servidor
DHCP, los factores principales que hay que tener encuentra para determinar el número de
servidores DHCP que se utilizarán son la arquitectura de la red y el hardware del servidor.
Por ejemplo, en un entorno con una única subred solamente se necesita un servidor DHCP, aunque
quizás desee utilizar dos servidores para crear un clúster de servidores DHCP y así aumentar el
nivel de tolerancia a errores.
Por otra parte, en entornos con varias subredes los enrutadores (con agente DHCP) deben reenviar
de una a otra los mensajes DHCP, por lo que el rendimiento del enrutador puede afectar al servicio
DHCP. En ambos casos, el hardware del servidor DHCP afecta a los clientes.
Para determinar el número de servidores DHCP que se deben utilizar debe tener en cuenta los
siguientes aspectos:
• La ubicación de los enrutadores en la red y si desea disponer de un servidor DHCP en cada

subred. No se olvide de que el servicio DHCP es solicitado por Broadcast que normalmente
queda limitado a la sub-red local.
Si un servidor DHCP se utiliza en más de una red, normalmente es necesario configurar

agentes de retransmisión de DHCP adicionales y, en algunos casos, también tendrá que
utilizar superámbitos.
• La velocidad de transmisión entre los segmentos para los que se proporciona el servicio
DHCP.
Si tiene vínculos WAN o de accesos telefónicos más lentos, normalmente necesitará un

servidor DHCP en ambos lados de estos vínculos para proporcionar el servicio local a los
clientes.
• La velocidad de las unidades del disco del servidor y la cantidad de memoria de acceso
aleatorio (RAM) instalada en el servidor DHCP.
Para optimizar el rendimiento del servidor DHCP se deben utilizar las unidades de disco
más rápidas y la mayor cantidad de memoria RAM posible. Debe evaluar cuidadosamente
60
el tiempo de acceso a disco y los tiempos promedio de las operaciones de lectura y

escritura en disco al planear las especificaciones de hardware del servidor DHCP.
• Restricciones prácticas basadas en la clase de direcciones seleccionada y otros detalles de

configuración del servidor.
Para determinar las limitaciones y las posibilidades del hardware y comprobar si la arquitectura de
la red, el tráfico y otros factores afectan al rendimiento del servidor DHCP puede probar los
servidores DHCP antes de implementarlos en la red de la organización. Las pruebas de hardware y
de configuración también permiten determinar el número de ámbitos que se deben configurar en
cada servidor.
Un plan alternativo para DHCP: configurar servidores de reserva
La mayoría de las redes necesitan un servidor DHCP principal en línea y otro servidor DHCP que
actúa como servidor secundario o de reserva. Si decide no implementar dos servidores DHCP, pero
desea proporcionar cierto nivel de tolerancia a errores, quizá desee considerar la posibilidad de
implementar un servidor DHCP de espera como alternativa.
En la configuración de espera, el servidor DHCP en espera es otro equipo servidor que se instala y
configura de forma idéntica al servidor DHCP principal. En este caso, la única diferencia es que el
servidor en espera y sus ámbitos no están activados para utilizarlos en condiciones normales. Se
configuran ámbitos duplicados, pero no se activan excepto cuando se necesita de forma crítica,
como, por ejemplo, para sustituir el servidor DHCP principal si se detiene o apaga durante un largo
período de tiempo.
Puesto que la solución del servidor en espera requiere prestar una atención especial a su
configuración, así como administrarlo manualmente para asegurar una transición correcta para que
lo utilicen los clientes DHCP, resulta menos recomendable como alternativa que la utilización de
dos o tres servidores DHCP que se repartan de forma equilibrada el uso de los ámbitos activos.
Aceptar subredes adicionales
Para que el servicio DHCP admita subredes adicionales en la red, primero deberá determinar si los
enrutadores utilizados para conectar las subredes próximas pueden admitir la retransmisión de
mensajes BOOTP y DHCP.
Si no se puede utilizar enrutadores para la retransmisión DHCP y BOOTP, puede realizar la

siguiente configuración en cada subred:
• Un equipo configurado para utilizar el componente Agente de retransmisión de DHCP.
Este equipo simplemente reenvía los mensajes entre los clientes de la subred local y un
servidor DHCP remoto, para lo que utiliza la dirección IP del servidor remoto.
• Un equipo configurado como servidor DHCP para la subred local.
Este equipo servidor debe contener y administrar ámbitos y otra información de direcciones
que se puede configurar para la subred local a la que proporciona el servicio.
61
Planear redes DHCP conectadas mediante enrutadores
En redes con enrutadores que utilicen subredes para dividir segmentos de la red, al planear las
opciones de los servicios DHCP se debe tener en cuenta requisitos específicos para que funcione
una implementación completa de los servicios DHCP. Estos requisitos incluyen:
• Al menos un servidor DHCP ubicado en una de las subredes de la red con enrutadores.
• Para que un servidor DHCP admita clientes de otras subredes remotas separadas mediante
enrutadores se debe utilizar un enrutador configurado para la retransmisión DHCP y
BOOTP o un equipo remoto como agente de retransmisión de DHCP y BOOTP para
admitir el reenvío del tráfico DHCP entre las subredes.
La siguiente ilustración muestra una red sencilla con enrutadores en la que está implementado
DHCP.
Otras consideraciones acerca del diseño de redes corporativas
Para una red DHCP corporativa debe:
• Planear las subredes físicas de la red y la ubicación relativa de los servidores DHCP.
• Especificar los tipos de opciones DHCP y sus valores predefinidos para cada ámbito para
los clientes DHCP.
Puede incluir la creación de ámbitos basados en las necesidades de grupos particulares de

usuarios. Por ejemplo, para una unidad que mueva frecuentemente equipos a ubicaciones
diferentes, como un grupo de marketing que utilice equipos portátiles acoplados en
diferentes estaciones, es posible definir una duración de concesión más corta para los
ámbitos relacionados. Así se recopilan las direcciones IP que cambian frecuentemente y se
devuelven al grupo de direcciones disponibles que se pueden utilizar en nuevas ofertas de
concesión.
• Reconocer el efecto que los vínculos más lentos tienen sobre el entorno de WAN.
62
Coloque servidores DHCP y DNS para optimizar el tiempo de respuesta y minimizar el

tráfico de baja velocidad.
Por ejemplo, en el plan de red de una gran compañía la segmentación de la WAN en subredes
lógicas puede coincidir con la estructura física del conjunto de redes. Así, una subred IP puede
actuar como red troncal, que mantiene una dirección de subred IP independiente en relación con
cada subred física.
Recomendaciones
Se recomienda la siguiente implementación de agente relé para obtener el mejor rendimiento en

una red DHCP enrutada. Utiliza dos servidores DHCP que están conectados a dos subredes
diferentes. Los agentes relé que funcionan en cada enrutador utilizado para conectar las subredes
tienen diversos intervalos de retardo (uno está configurado con 4 segundos y el otro no utiliza
retardo). Así se elimina el riesgo de saturación de paquetes DHCP a través de rutas de acceso a la
red seleccionadas aleatoriamente.
Hay importantes cuestiones de diseño que se deben tener en cuenta antes de instalar los agentes
relé en la red.
Cuando hay varios servidores DHCP, se recomienda colocar los servidores en diferentes subredes,
para alcanzar un grado de tolerancia a errores, en lugar de mantenerlos a todos en una subred. Los
servidores no deben tener direcciones IP comunes en sus ámbitos (cada servidor debe tener un
grupo de direcciones únicas). Si el servidor DHCP de la subred local se cierra, las solicitudes se
transmiten a la subred remota. El servidor DHCP de esa ubicación puede responder a las
solicitudes DHCP si mantiene un ámbito de direcciones IP para la subred que realiza la solicitud.
Si el servidor remoto no dispone de un ámbito definido para la subred que realiza la solicitud, no
podrá proporcionar direcciones IP aunque tenga direcciones disponibles de otros ámbitos. Si cada
servidor DHCP tiene un grupo de direcciones para cada subred, podrá proporcionar direcciones IP
a los clientes remotos cuyo servidor DHCP esté desconectado.
63
Servidores DHCP
La configuración de servidores DHCP en una red proporciona las siguientes ventajas:
• El administrador puede especificar parámetros TCP/IP, tanto globales como específicos

para las subredes, de forma centralizada para toda la red.
• No es necesario configurar manualmente los parámetros TCP/IP de los clientes.
• Cuando se mueve un equipo cliente entre subredes, se libera su antigua dirección IP para
poder volver a utilizarla. Cuando se reinicia el equipo en su nueva ubicación, el cliente
vuelve a configurar sus valores de TCP/IP automáticamente.
• La mayoría de los enrutadores pueden reenviar las solicitudes de configuración de DHCP y
BOOTP, por lo que no es necesario disponer de servidores DHCP en cada subred de la red.
Clientes DHCP
Un equipo se convierte en cliente DHCP si la opción de utilizar DHCP está activada en sus
propiedades de TCP/IP. Cuando un equipo cliente se configura para utilizar DHCP, acepta una
oferta de concesión y puede recibir del servidor lo siguiente:
• El uso temporal de una dirección IP que se sabe que es válida en la red a la que se une.
• Parámetros adicionales de configuración TCP/IP, que el cliente utilizará en forma de datos
de opciones.
Además de una dirección IP, los servidores DHCP se pueden configurar para proporcionar datos
opcionales que permiten completar la configuración TCP/IP de los clientes. Algunos de los tipos
de opciones de DHCP más comunes configuradas y distribuidas por el servidor DHCP durante las
concesiones son:
• Las puertas de enlace predeterminadas (enrutadores) que se utilizan para conectar un

segmento de la red a otros segmentos de la red.
• Otros parámetros de configuración opcionales que se asignarán a los clientes DHCP, como
las direcciones IP de los servidores DNS, que el cliente puede utilizar para resolver
nombres de host de la red.
Opciones de DHCP
DHCP proporciona un marco de trabajo interno para pasar información de configuración a los
clientes de la red. Los parámetros de configuración y demás información de control se transportan
en elementos de datos etiquetados almacenados en mensajes de protocolo, que se intercambian
entre el servidor y los clientes DHCP. Estos elementos de datos reciben el nombre de opciones.
La mayor parte de las opciones estándar de DHCP están definidas actualmente en el documento
Solicitudes de comentarios (RFC, Request for Comments) que publica el Grupo de trabajo de
ingeniería de Internet (IETF, Internet Engineering Task Force). El conjunto completo de opciones
estándar de DHCP se describe específicamente en el documento RFC 2132, "Opciones de DHCP y
extensiones de proveedor de BOOTP".
64
Aunque la mayor parte de los servidores DHCP pueden asignar muchas opciones, la mayoría de
los clientes DHCP están diseñados para solicitar o admitir solamente una parte del conjunto
completo de opciones estándar especificadas en RFC.
Configuración de un servidor DHCP
Veremos a continuación los pasos que debe realizar el administrador del servicio DHCP para
configurar el servicio DHCP en un servidor de una intranet.
redes e Internet.
• Dirección IP
• Nombre de Host
Configuración del servicio DHCP
• Definir los ámbitos

• Configurar los rangos de direcciones IP de cada ámbito
• Definir las direcciones de exclusión de cada rango
• Definir las máscaras de su-red de cada ámbito
• Configuración de opciones. Para cada ámbito se configuran las siguientes opciones
mínimas:
o Dirección IP del servidor DNS
o Dirección IP del ruteador por defecto
o Nombre del dominio DNS
o Tiempo de concesión
o Direcciones reservadas para ciertas direcciones MAC
65
Actualización dinámica con el servidor DNS
Veremos algunas alternativas que requieren la actualización dinámica de un servidor DNS

configurado para aceptar actualizaciones dinámicas.
Cambio de nombre de un cliente DHCP
Las actualizaciones dinámicas normalmente se solicitan cuando cambia en el equipo un nombre

DNS o una dirección IP. Por ejemplo, suponga que un cliente llamado "antiguohost" se configuró
con los nombres siguientes:
Nombre de equipo antiguohost

Nombre de dominio DNS del equipo ejemplo.pepe.com
Nombre completo de equipo antiguohost.ejemplo.pepe.com
En este ejemplo, no se configuraron para el equipo cliente, nombres de dominio DNS específicos
de la conexión, en otras palabras el cliente no conoce el nombre del servidor DNS que contiene la
zona con autoridad donde se registra su nombre completo. Más tarde, se cambió el nombre del
equipo de "antiguohost" a "nuevohost", lo que conlleva los cambios de nombre siguientes en el
sistema:
Nombre de equipo nuevohost

Nombre de dominio DNS del equipo ejemplo.pepe.com
Nombre completo de equipo nuevohost.ejemplo.pepe.com
Una vez aplicado el cambio de nombre en el cliente, se debe reiniciar el equipo. Cuando el equipo
reinicia, el servicio Cliente DHCP realiza la siguiente secuencia para actualizar DNS:
1. El servicio Cliente DHCP envía una consulta al servidor DNS por defecto, de tipo
inicio de autoridad (SOA) con el nombre de dominio DNS del equipo.
El equipo cliente utiliza el nombre completo actualmente configurado del equipo (como
"nuevohost.ejemplo.pepe.com") como el nombre especificado en esta consulta.
2. El servidor DNS autorizado para la zona que contiene el nombre completo del cliente
responde a la consulta de tipo SOA.
3. A continuación, el servicio Cliente DHCP intenta ponerse en contacto con el servidor

DNS principal de la zona donde su nombre viejo está registrado.
El cliente procesa la respuesta de la consulta de inicio de autoridad con el fin de determinar

la dirección IP del servidor DNS autorizado como servidor principal para aceptar su
nombre. A continuación envía una solicitud de actualización dinámica al servidor principal.
66
El contenido de la solicitud de actualización incluye instrucciones para agregar registros de

recursos de host (A), y posiblemente de punteros (PTR), para
"nuevohost.ejemplo.pepe.com" y quita estos mismos tipos de registros para
"antiguohost.ejemplo.pepe.com", el nombre que se había registrado previamente.
El servidor también comprueba si se permiten las actualizaciones para la solicitud del

cliente. En las zonas primarias estándar (sin DNSSEC), las actualizaciones dinámicas no se
aseguran, por lo que cualquier intento del cliente de realizar actualizaciones será correcto..
Las actualizaciones dinámicas se envían o actualizan periódicamente. De forma predeterminada,

los equipos envían una actualización una vez cada 7 días aproximadamente (depende del sistema
operativo). Si la actualización no provoca ningún cambio en los datos de la zona, la zona
permanece en su versión actual y no se escribe ningún cambio. Las actualizaciones sólo producen
cambios reales en la zona o aumentan el número de transferencias de la misma si los nombres o las
direcciones cambian realmente.
También, el cliente DHCP puede negociar con el servidor DHCP para que sea este el que registre
el cambio en el servidor DNS.
Observe que los nombres no se quitan de las zonas DNS si pasan a estado inactivo o no se
actualizan en el intervalo de actualización (7 días). DNS no usa un sistema para liberar o desechar
los nombres, aunque los clientes DNS intentan eliminar o actualizar los registros de nombres
antiguos cuando se aplica un nuevo nombre o cambia una dirección.
Cuando el servicio Cliente DHCP registra los registros de recursos de host (A) y de puntero (PTR)
para un equipo, utiliza un período de vida (TTL) predeterminado de almacenamiento en caché de
15 minutos (depende del sistema operativo) para los registros del host. Esto determina durante
cuánto tiempo otros servidores y clientes DNS almacenan en caché los registros de un equipo
cuando se incluyen en la respuesta a una consulta.
Interacción de actualización de un servidor DHCP y de un servidor DNS
Tenemos la siguiente alternativa:
1. El cliente envía al servidor DHCP un mensaje de solicitud (DHCPREQUEST) que incluye

la opción 81 de DHCP. De forma predeterminada, el cliente solicita que el servidor DHCP
registre el registro PTR de DNS, mientras que el cliente registra su propio registro A.
2. El servidor devuelve al cliente un mensaje de confirmación DHCP (DHCPACK) en el que
le otorga una concesión de una dirección IP e incluye la opción 81. Si el servidor DHCP
utiliza las opciones de configuración predeterminadas (actualizar dinámicamente los
registros DNS A y PTR sólo si los clientes DHCP lo solicitan) la opción 81 indicará al
cliente que el servidor DHCP registrará el registro DNS PTR y que el cliente registrará el
registro DNS A.
3. De forma asincrónica, el cliente registra el registro DNS A y el servidor DHCP registra el
registro DNS PTR del cliente.
67
Otra posibilidad es la siguiente:
Los clientes DHCP de ciertas plataformas no admiten directamente el proceso de actualización

automática de DNS y, por lo tanto, no pueden interactuar directamente con el servidor DNS. Para
estos clientes DHCP, las actualizaciones normalmente se tratan como se muestra a continuación:
1. El cliente envía un mensaje de solicitud DHCP (DHCPREQUEST) al servidor. La solicitud

no incluye la opción 81 de DHCP.
2. El servidor devuelve al cliente un mensaje de reconocimiento DHCP (DHCPACK), en el
que le otorga una concesión de dirección IP, sin incluir la opción 81 de DHCP.
3. A continuación, el servidor envía al servidor DNS actualizaciones para el registro de
nombre del cliente, que es un registro de recursos de host (A). El servidor envía también
actualizaciones para el registro de búsqueda inversa del cliente, que es un registro de
recursos de puntero (PTR).
68
[21]
Defina que se entiende por servicio DHCP
[22]
Explique en forma resumida como funciona el protocolo DHCP
[23]
Defina que se entiende por ámbito en el protocolo DHCP.
[24]
Explique en forma resumida la función de un agente de distribución DHCP.
[25]
Realice un dibujo que permita ver la funcionalidad de un ruteador con protocolo DHCP para
proporcionar servicio a varias subredes.
[26]
Describa las opciones básicas de configuración en un servidor DHCP
[27]
Indique en forma resumida como se realiza la actualización dinámica en un servidor DDNS
69
6.3 El protocolo HTTP
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo

protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los
servidores HTTP. La especificación completa del protocolo HTTP 1/0 está en el RFC 1945. Fue
propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución
de información como el World Wide Web.
Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión
TCP/IP, y funciona de la misma forma que el resto de los servicios comunes: un proceso servidor
escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de
conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga
de mantener la comunicación y garantizar un intercambio de datos libre de errores.
HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión

con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un
mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las
operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web
(documento HTML, archivo multimedia o aplicación de scripts) es conocido por su URL.
Las principales características del protocolo HTTP son:
• Toda la comunicación entre los clientes y servidores se realiza a partir de caracteres de 8

bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc.,
respetando su formato original.
• Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado
está identificado por su clasificación MIME.
• Existen tres verbos básicos (hay más, pero por lo general no se utilizan) que un cliente
puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para
enviar información al servidor y HEAD, para solicitar las características de un objeto (por
ejemplo, la fecha de modificación de un documento HTML).
• Cada operación HTTP implica una conexión con el servidor, que es liberada al término de
la misma. Es decir, en una operación se puede recoger un único objeto.
• No mantiene estado. Cada petición de un cliente a un servidor no es influida por las
transacciones anteriores. El servidor trata cada petición como una operación totalmente
independiente del resto.
• Cada objeto al que se aplican los verbos del protocolo está identificado a través de un
puntero conocido como URL.
Los recursos u objetos que actúan como entrada o salida de un comando HTTP están
clasificados por su descripción MIME. De esta forma, el protocolo puede intercambiar
cualquier tipo de dato, sin preocuparse de su contenido. La transferencia se realiza en modo
binario, byte a byte, y la identificación MIME permitirá que el receptor trate adecuadamente
los datos.
Mensajes entre cliente y servidor
El cliente toma la iniciativa de localizar una página en un sitio Web mediante una petición http.
70
La página Web está compuesta por un archivo HTML base, que hace referencia a otros objetos. Se
hace referencia a cada objeto mediante un URL (Universal Resource Locator) o localizador de
recursos universal.
Un objeto puede ser un archivo HTML, una imagen JPEG, un applet JAVA, un archivo de sonido,
etc.
Ejemplo de URL:
El cliente inicia una conexión TCP al servidor, en el puerto 80. El servidor acepta la conexión TCP
del cliente. Cada uno tiene un socket conectado con el otro. Se intercambian mensajes HTTP entre
el navegador y el servidor Web. Se cierra la conexión TCP.
HTTP es “sin estado”. El servidor no mantiene ninguna información de peticiones anteriores del
cliente
Los protocolos que mantienen “estado” son complejos. Debe mantener la historia pasada (estado).
Si el cliente/servidor falla, el estado entre ambos puede volverse incoherente.
Tipos de conexiones cliente servidor
El cliente puede establecer dos tipos de conexiones según como está configurado el servidor:
• Conexión persistente
• Conexión no persistente
71
HTTP no persistente: En cada conexión TCP se envía como máximo un objeto. Es la situación
por defeco de la versión HTTP/1.0.
De acuerdo a lo representado en la figura, se realiza una conexión entre cliente y servidor por cada
objeto de la página.
HTTP persistente: En la misma conexión TCP se pueden enviar varios objetos entre el servidor y
el cliente. Es la situación por defecto en la versión HTTP/1.1. Mediante una conexión se
transfieren todos los objetos de la página.
Tiempos de transferencia de mensajes en una conexión
Se define el tiempo RTT como el tiempo de respuesta a una petición. Veremos las alternativas que
se presentan en conexiones persistentes y no persistentes.
72
En la conexión no persistente se necesitan 2 tiempos RTT por cada objeto.
En la conexión persistente se necesitan 2 RTT en el primer objeto y solo un RTT en los demás
objetos.
73
Se puede optimizar una conexión persistente usando pipelining que significa adelantar la petición
del siguiente objeto como se puede apreciar en la siguiente figura.
Cabe hacer notar que cuando un cliente realiza una conexión con el servidor, se crea un proceso en
este último para hacerse cargo de la petición del cliente. Eso significa que si en un momento dado
acceden 100 clientes simultáneamente, en el servidor se activan 100 procesos.
Con la conexión no persistente el tiempo de atención que un proceso otorga a un cliente es el

necesario para transferir un objeto. Por lo tanto el proceso queda habilitado para atender a otro
cliente. De esta forma se necesitan menos procesos activados simultáneamente y por lo tanto
menos recursos del servidor.
En una conexión persistente, un proceso se tiene que hacer cargo de un cliente durante el acceso a
todos los objetos de la página y recién entonces será liberado para atender a otro cliente. Por lo
tanto se necesitan más procesos y por lo tanto más recursos en el servidor.
Sin embargo con una conexión persistente el cliente es atendido más rápidamente. En la
configuración del servidor se define si trabajará en modo persistente o no.
Cabeceras del protocolo
En realidad, cuando un navegador conecta con un servidor Web remoto no sólo le solicita la
página cuya URL el usuario ha tecleado (o la indicada en el enlace seleccionado con el ratón),
sino que le informa de detalles del navegador, de la página que solicita, etc. Quizás viendo un
ejemplo esto último quede más claro. A continuación se muestra una petición HTTP típica:
GET / HTTP/1.1
74
Host: www.iua.edu.ar
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
text/css,*/*;q=0.1
Accept-Language: es-es, en-us;q=0.66, en;q=0.33
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-15, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
El proceso completo es el siguiente. El usuario teclea www.iua.edu.ar en su navegador (el

prefijo http:// indica el protocolo que habrá de usar el navegador tras conectar con el servidor,
que es el protoclo predeterminado). El navegador realiza una consulta DNS para averiguar la
dirección IP asociada al nombre www.iua.edu.ar, por ejemplo 200.200.200.200. Y entonces
intenta establecer una conexión TCP al puerto 80 (el predeterminado para los servidores Web).
Cuando dicha conexión se ha establecido, el navegador envía la petición HTTP solicitando la

página indicada tecleada por el usuario. Puesto que no se indicó una página en concreto, el
navegador asume que se solicita la página principal, que se representa como /. Como se ve en el
listado anterior, además se envía información adicional.
Nota: Cuando se indica un directorio y no un archivo, el servidor supone por

defecto que se trata de un archivo de nombre predeterminado o documento por
defecto. Si no existe dicho archivo en ese directorio, devuelve un mensaje de
error, a menos que esté habilitada la navegación (browsing) en dicho directorio.
En este caso el servidor devuelve al cliente un listado con los archivos y su-
directorios del directorio apuntado.
Por ejemplo, se informa del navegador en uso (User-Agent) y en qué idioma se prefiere
visualizar la página que se está solicitando (Accept-Language) (esto permite que una Web
albergue los contenidos en varios idiomas, y se le envía al navegador la versión en el idioma que
tenga configurado en sus opciones).
Las cabeceras Accept-Encoding y Accept-Charset y Accept le indican al servidor qué tipos de

contenidos el navegador entiende y sabe representar. Por ejemplo, mientras que el navegador
usado entiende imágenes PNG (image/png), es muy probable que un navegador en modo texto
no, y por lo tanto enviará unas cabeceras acorde con sus capacidades.
De hecho, estas y otras cabeceras son personalizables, de manera que podemos forzar que
nuestro navegador se identifique como otro, para entrar en esos sitios que nos impiden el acceso
por la arbitraria razón de no usar un navegador en concreto.
La pareja de cabeceras Keep-Alive y Connection, sólo está presente en la versión 1.1 del
protocolo HTTP, y permite recibir muchos recursos (páginas HTML, imágenes, etc.) a través de
la conexión TCP persistente. En la versión 1.0 del protocolo HTTP era necesario establecer y
terminar una conexión TCP por cada recurso (no persistente), lo que resultaba ineficiente.
75
Hasta ahora, el servidor sólo sabe que tiene que enviar al navegador remoto la página inicial del
servidor Web asociado a la IP a que se ha conectado. Pero no sería posible tener hospedadas las
páginas de varios sitios en el mismo servidor y usando la misma dirección IP (virtual hosting).
Para ello, la versión 1.1 del protocolo HTTP añadió la obligatoriedad de la cabecera Host (host
header), que indica al servidor las páginas de qué sitio queremos ver, para el caso de que haya
varias asociadas a un servidor Web en la misma dirección IP. Por eso la barra (/) que sigue al
nombre del sitio representa el directorio raíz del sitio (cada sitio en el mismo servidor tiene un
directorio raíz diferente) cuyo nombre se indica como //sitio y que se envía en el campo Host
del encabezado.
El servidor recibe todas estas (y posiblemente más cabeceras, por ejemplo, en el caso de que
haya algún proxy intermedio), las interpreta, y devolverá al navegador una respuesta estándar
HTTP (indicando si la petición tuvo éxito o no), y a continuación la página solicitada. En el caso
de la página principal implícita (/), el servidor tendrá configurado un archivo, normalmente
index.html, que enviará en caso de no especificarse una página en concreto:
HTTP/1.1 200 OK
Date: Sun, 10 Nov 2002 22:50:55 GMT
Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3
FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b
Content-Type: text/html
Age: 130
Connection: close
<-- archivo index.html que contiene la página principal del sitio -->
Se ha recortado la respuesta del servidor Web mostrando solamente la cabecera. Como se ve, en
primer lugar el servidor informa del éxito de la petición (200 OK) y de la versión del protocolo
que conoce (HTTP/1.1). También indica la fecha y hora en el servidor (Date) y la versión y
módulos del servidor Web (Server).
Lo realmente interesante es la cabecera Content-Type, que le dice al navegador el tipo de

contenido que viene a continuación (text/html) seguido del contenido propiamente dicho (el
archivo index.html en el directorio base del servidor Web). Si en lugar de pedir una página en
formato HTML se solicita un recurso binario, como por ejemplo un archivo gráfico, la respuesta
será de la forma siguiente:
HTTP/1.1 200 OK
Date: Sun, 10 Nov 2002 23:15:31 GMT
Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3
FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b
Last-Modified: Fri, 01 Nov 2002 12:23:38 GMT
ETag: "23c32f-171cb-3dc2724a"
Accept-Ranges: bytes
Content-Length: 94667
Content-Type: image/png
Age: 131
76
Una respuesta similar a la primera, pero en este caso se indica que a continuación viene el
contenido de un archivo binario en formato PNG, el tamaño en octetos del archivo, y la fecha de
su última modificación. Esta fecha, y el valor de las etiquetas ETag son usados por los cachés de
protocolo HTTP para decidir si almacenar o no en su memoria y disco el recurso al cual se
refieren, por considerarlo más reciente que la copia que ya tenían (en caso de tenerla). Cuando
alguien vuelve a solicitar ese mismo recurso y la caché ve la petición, devuelve al cliente la
copia almacenada en su memoria, lo cual acelera la carga del recurso y reduce la carga en los
enlaces de la red y en el servidor remoto.
Estructura de los mensajes HTTP
El diálogo con los servidores HTTP se establece a través de mensajes formados por líneas de texto,
cada una de las cuales contiene los diferentes comandos y opciones del protocolo. Sólo existen
dos tipos de mensajes, uno para realizar solicitudes y otro para devolver la correspondiente
respuesta. La estructura general de los dos tipos de mensajes se puede ver en el siguiente
esquema:
Mensaje de solicitud Mensaje de respuesta

Comando HTTP + parámetros Resultado de la solicitud
Cabeceras del requerimiento Cabeceras de la respuesta
(línea en blanco) (línea en blanco)
Información opcional Información opcional
La primera línea del mensaje de solicitud contiene el comando que se solicita al servidor HTTP,
mientras que en la respuesta contiene el resultado de la operación, un código numérico que permite
conocer el éxito o fracaso de la operación. Después aparece, para ambos tipos de mensajes, un
conjunto de cabeceras (unas obligatorias y otras opcionales), que condicionan y matizan el
funcionamiento del protocolo.
La separación entre cada línea del mensaje se realiza con un par CR-LF (retorno de carro más
nueva línea). El final de las cabeceras se indica con una línea en blanco, tras la cual se pueden
incluir los datos transportados por el protocolo, por ejemplo, el documento HTML que devuelve
un servidor o el contenido de un formulario que envía un cliente.
Los siguientes apartados describen con más detalle el contenido de cada una de las secciones de
los mensajes. El conocimiento y empleo de los mensajes HTTP es necesario en las siguientes
situaciones:
• Para diseñar aplicaciones de servidor (scripts PHP, ASP, JSP, CGI, etc., ya que es preciso
construir una respuesta similar a la que el servidor HTTP proporciona al cliente.
• Para diseñar aplicaciones independientes que soliciten información a un servidor
(automatizar la recuperación de documentos o construir robots de búsqueda) se debe
construir una cabecera HTTP con la información de la petición al servidor.
77
Comandos del protocolo
Los comandos o verbos de HTTP representan las diferentes operaciones que se pueden solicitar a
un servidor HTTP. El formato general de un comando es:
Nombre del comando Objeto sobre el que se aplica Versión de HTTP utilizada
Cada comando actúa sobre un objeto del servidor, normalmente un archivo o aplicación, que se
toma de la URL de activación. La última parte de esta URL, que representa la dirección de un
objeto dentro de un servidor HTTP, es el parámetro sobre el que se aplica el comando. Se compone
de una serie de nombres de directorios y archivos, además de parámetros opcionales para las
aplicaciones de scripts, o CGI.
El estándar HTTP/1.0 recoge únicamente tres comandos, que representan las operaciones de
recepción y envío de información y chequeo de estado:
• GET Se utiliza para recoger cualquier tipo de información del servidor. Se utiliza siempre
que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el
servidor HTTP envía el documento correspondiente a la URL seleccionada, o bien activa
una aplicación de servidor (script o CGI), que generará a su vez la información de retorno.
• HEAD Solicita información sobre un objeto (archivo): tamaño, tipo, fecha de
modificación, etc. Es utilizado por los gestores de cachés de páginas o los servidores proxy,
para conocer cuándo es necesario actualizar la copia que se mantiene de un archivo.
• POST Sirve para enviar información al servidor, por ejemplo los datos contenidos en un
formulario. El servidor pasará esta información a un proceso encargado de su tratamiento
(generalmente una aplicación de servidor). La operación que se realiza con la información
proporcionada depende de la URL utilizada. Se utiliza, sobre todo, en los formularios.
Un cliente Web selecciona automáticamente los comandos HTTP necesarios para recoger la
información requerida por el usuario. Así, ante la activación de un enlace, siempre se ejecuta una
operación GET para recoger el documento correspondiente.
El envío del contenido de un formulario utiliza GET o POST, en función del atributo de <FORM
METHOD="...">. Además, si el cliente Web tiene un caché de páginas recientemente visitadas,
puede utilizar HEAD para comprobar la última fecha de modificación de un archivo, antes de traer
una nueva copia del mismo.
Posteriormente se han definido algunos comandos adicionales, que sólo están disponibles en
determinadas versiones de servidores HTTP. La última versión de HTTP, denominada 1.1, utiliza
estas y otras novedades, que se pueden usar, por ejemplo, para editar las páginas de un servidor
Web trabajando en remoto.
• PUT Actualiza información sobre un objeto del servidor. Es similar a POST, pero en este
caso, la información enviada al servidor debe ser almacenada en la URL que acompaña al
comando. Así se puede actualizar el contenido de un documento.
• DELETE Elimina el documento especificado del servidor.
• LINK Crea una relación entre documentos.
78
• UNLINK Elimina una relación existente entre documentos del servidor.
Las cabeceras
Son un conjunto de variables que se incluyen en los mensajes HTTP, para modificar su
comportamiento o incluir información de interés. En función de su nombre, pueden aparecer en los
requerimientos de un cliente, en las respuestas del servidor o en ambos tipos de mensajes. El
formato general de una cabecera es:
Nombre de la variable : Cadena ASCII con su valor
Los nombres de variables se pueden escribir con cualquier combinación de mayúsculas y

minúsculas. Además, se debe incluir un espacio en blanco entre el signo : y su valor. En caso de
que el valor de una variable ocupe varias líneas, éstas deberán comenzar, al menos, con un espacio
en blanco o un tabulador.
Cabeceras comunes para peticiones y respuestas:
• Content-Type: descripción MIME de la información contenida en este mensaje. Es la

referencia que utilizan las aplicaciones Web para dar el correcto tratamiento a los datos que
reciben.
• Content-Length: longitud en bytes de los datos enviados, expresado en base decimal.
• Content-Encoding: formato de codificación de los datos enviados en este mensaje. Sirve,
por ejemplo, para enviar datos comprimidos (x-gzip o x-compress) o encriptados.
• Date: fecha local de la operación. Las fechas deben incluir la zona horaria en que reside el
sistema que genera la operación. Por ejemplo: Sunday, 12-Dec-96 12:21:22 GMT+01. No
existe un formato único en las fechas; incluso es posible encontrar casos en los que no se
dispone de la zona horaria correspondiente, con los problemas de sincronización que esto
produce. Los formatos de Pragma: permite incluir información variada relacionada con el
protocolo HTTP en el requerimiento o respuesta que se está realizando. Por ejemplo, un
cliente envía un Pragma: no-cache para informar de que desea una copia nueva del recurso
especificado.
Cabeceras sólo para peticiones del cliente:
• Accept: campo opcional que contiene una lista de tipos MIME aceptados por el cliente. Se
pueden utilizar * para indicar rangos de tipos de datos; tipo/* indica todos los subtipos de
un determinado medio, mientras que */* representa a cualquier tipo de dato disponible.
• Authorization: clave de acceso que envía un cliente para acceder a un recurso de uso
protegido o limitado. La información incluye el formato de autorización empleado, seguido
de la clave de acceso propiamente dicha. La explicación se incluye más adelante.
• From: campo opcional que contiene la dirección de correo electrónico del usuario del
cliente Web que realiza el acceso.
• If-Modified-Since: permite realizar operaciones GET condicionales, en función de si la
fecha de modificación del objeto requerido es anterior o posterior a la fecha proporcionada.
Puede ser utilizada por los sistemas de almacenamiento temporal de páginas. Es
equivalente a realizar un HEAD seguido de un GET normal.
79
• Referer: contiene la URL del documento desde donde se ha activado este enlace. De esta
forma, un servidor puede informar al creador de ese documento de cambios o
actualizaciones en los enlaces que contiene. No todos los clientes lo envían.
• User-agent: cadena que identifica el tipo y versión del cliente que realiza la petición.
Cabeceras sólo para respuestas del servidor http:
• Allow: informa de los comandos HTTP opcionales que se pueden aplicar sobre el objeto al
que se refiere esta respuesta. Por ejemplo, Allow: GET, POST.
• Expires: fecha de expiración del objeto enviado. Los sistemas de cache deben descartar las
posibles copias del objeto pasada esta fecha. Por ejemplo, Expires: Thu, 12 Jan 97 00:00:00
GMT+1. No todos los sistemas lo envían. Puede cambiarse utilizando un <META
EXPIRES> en el encabezado de cada documento.
• Last-modified: fecha local de modificación del objeto devuelto. Se puede corresponder
con la fecha de modificación de un archivo en disco, o, para información generada
dinámicamente desde una base de datos, con la fecha de modificación del registro de datos
correspondiente.
• Location: informa sobre la dirección exacta del recurso al que se ha accedido. Cuando el
servidor proporciona un código de respuesta de la serie 3xx, este parámetro contiene la
URL necesaria para accesos posteriores a este recurso.
• Server: cadena que identifica el tipo y versión del servidor HTTP. Por ejemplo, Server:
NCSA 1.4.
• WWW-Autenticate: cuando se accede a un recurso protegido o de acceso restringido, el
servidor devuelve un código de estado 401, y utiliza este campo para informar de los
modelos de autentificación válidos para acceder a este recurso.
Códigos de estado del servidor
Ante cada transacción con un servidor HTTP, éste devuelve un código numérico que informa sobre
el resultado de la operación, como primera línea del mensaje de respuesta. Estos códigos aparecen
en algunos casos en la pantalla del cliente, cuando se produce un error. El formato de la línea de
estado es:
Versión de protocolo Código numérico de Descripción del código

HTTP utilizada estado (tres dígitos) numérico
Nota: Dependiendo del servidor, es posible que se proporcione un mensaje de error más
elaborado, en forma de documento HTML, en el que se explican las causas del error y su
posible solución.
Existen cinco categorías de mensajes de estado, organizadas por el primer dígito del código
numérico de la respuesta:
• 1xx: mensajes informativos. Por ahora (en HTTP/1.0) no se utilizan, y están reservados
para un futuro uso.
• 2xx: mensajes asociados con operaciones realizadas correctamente.
• 3xx: mensajes de redirección, que informan de operaciones complementarias que se deben
realizar para finalizar la operación.
80
• 4xx: errores del cliente; el requerimiento contiene algún error, o no puede ser realizado.
• 5xx: errores del servidor, que no ha podido llevar a cabo una solicitud.
Los más comunes se recogen en la siguiente tabla:
Código Comentario Descripción

200 OK Operación realizada satisfactoriamente.
201 Created La operación ha sido realizada
correctamente, y como resultado se ha
creado un nuevo objeto, cuya URL de
acceso se proporciona en el cuerpo de la
respuesta. Este nuevo objeto ya está
disponible. Puede ser utilizado en sistemas
de edición de documentos.
202 Accepted La operación ha sido realizada
correctamente, y como resultado se ha
creado un nuevo objeto, cuya URL de
acceso se proporciona en el cuerpo de la
respuesta. El nuevo objeto no está
disponible por el momento. En el cuerpo
de la respuesta se debe informar sobre la
disponibilidad de la información.
204 No Content La operación ha sido aceptada, pero no ha
producido ningún resultado de interés. El
cliente no deberá modificar el documento
que está mostrando en este momento.
301 Moved El objeto al que se accede ha sido movido
Permanently a otro lugar de forma permanente. El
servidor proporciona, además, la nueva
URL en la variable Location de la
respuesta. Algunos browsers acceden
automáticamente a la nueva URL. En caso
de tener capacidad, el cliente puede
actualizar la URL incorrecta, por ejemplo,
en la agenda de bookmarks.
302 Moved El objeto al que se accede ha sido movido
Temporarily a otro lugar de forma temporal. El
servidor proporciona, además, la nueva
URL en la variable Location de la
respuesta. Algunos browsers acceden
automáticamente a la nueva URL. El
cliente no debe modificar ninguna de las
referencias a la URL errónea.
304 Not Cuando se hace un GET condicional, y el
81
Modified documento no ha sido modificado, se

devuelve este código de estado.
400 Bad Request La petición tiene un error de sintaxis y no
es entendida por el servidor.
401 Unauthorized La petición requiere una autorización
especial, que normalmente consiste en un
nombre y clave que el servidor verificará.
El campo WWW-Autenticate informa de
los protocolos de autentificación
aceptados para este recurso.
403 Forbidden Está prohibido el acceso a este recurso.
No es posible utilizar una clave para
modificar la protección.
404 Not Found La URL solicitada no existe.
500 Internal El servidor ha tenido un error interno, y
Server Error no puede continuar con el procesamiento.
501 Not El servidor no tiene capacidad, por su
Implemented diseño interno, para llevar a cabo el
requerimiento del cliente.
502 Bad Gateway El servidor, que está actuando como proxy
o pasarela, ha encontrado un error al
acceder al recurso que había solicitado el
cliente.
503 Service El servidor está actualmente
Unavailable deshabilitado, y no es capaz de atender el
requerimiento.
Cachés de páginas y servidores proxy
Muchos clientes Web utilizan un sistema para reducir el número de accesos y transferencias de
información a través de Internet, y así agilizar la presentación de documentos previamente
visitados. Para ello, almacenan en el disco del cliente una copia de las últimas páginas a las que se
ha accedido. Este mecanismo, denominado "caché de páginas", mantiene la fecha de acceso a un
documento y comprueba, a través de un comando HEAD, la fecha actual de modificación del
mismo. En caso de que se detecte un cambio o actualización, el cliente accederá, ahora a través de
un GET, a recoger la nueva versión del archivo. En caso contrario, se procederá a utilizar la copia
local.
Un sistema parecido, pero con más funciones es el denominado "servidor proxy". Este tipo de
servidor, una mezcla entre servidor HTTP y cliente Web, realiza las funciones de cache de páginas
para un gran número de clientes. Todos los clientes conectados a un proxy dejan que éste sea el
encargado de buscar en la red las URLs solicitadas por dichos clientes. De esta forma, en caso de
82
que varios clientes accedan a la misma página, el servidor proxy la podrá proporcionar con un
único acceso a la información original.
La principal ventaja de ambos sistemas de cache es la drástica reducción de conexiones a Internet

necesarias, en caso de que los clientes accedan a un conjunto similar de páginas, como suele
ocurrir con mucha frecuencia.
Además, las organizaciones limitan, por motivos de seguridad, los accesos desde su red privada al
exterior y viceversa. Para ello, se dispone de sistemas denominados "cortafuegos" (firewalls), que
son los únicos habilitados para conectarse con el exterior. En este caso, el uso de un servidor proxy
se vuelve indispensable.
En determinadas situaciones, el almacenamiento de páginas en un caché o en un proxy puede hacer

que se mantengan copias no actualizadas de la información, como por ejemplo en el caso de
trabajar con documentos generados dinámicamente. Para estas situaciones, los servidores HTTP
pueden informar a los clientes de la expiración del documento, o de la imposibilidad de ser
almacenado en un caché, utilizando la variable Expires en la respuesta del servidor.
Cookies
Las ‘galletas mágicas’ o simplemente “cookies” son una de las incorporaciones en la nueva
versión del protocolo, HTTP/1.1. Las cookies son pequeños archivos de texto que se intercambian
los clientes y servidores HTPP, para solucionar una de las principales “deficiencias” del protocolo:
la falta de información de estado entre dos transacciones. Recuerde que HTTP es un protocolo sin
estados. Fueron introducidas por Netscape, y ahora han sido estandarizadas en el RFC 2109.
Cada intercambio de información con un servidor es completamente independiente del resto, por lo
que las aplicaciones de servidor necesitan recordar operaciones previas de un usuario (por ejemplo,
los supermercados electrónicos) pueden optar por dos soluciones, que complican bastante su
diseño: almacenar temporalmente en el sistema del servidor un registro de las operaciones
realizadas, con una determinada política para eliminarlas cuando no son necesarias, o bien incluir
esta información en el código HTML devuelto al cliente, como campos HIDDEN de un
formulario.
Las cookies son una solución más flexible a este problema. La primera vez que un usuario accede
a un determinado documento de un servidor, éste proporciona una cookie que contiene datos que
relacionarán posteriores operaciones. El cliente almacena la cookie en su sistema para usarla
después en forma automática, transparente al usuario. En los futuros accesos a este servidor, el
browser podrá proporcionar la cookie original, que servirá de nexo entre este acceso y los
anteriores. Todo este proceso se realiza automáticamente, sin intervención del usuario. El siguiente
ejemplo muestra una cookie generada por el sitio pepe.com.
EGSOFT_ID
191.46.211.13-655193640.29148285
www.pepe.com/
0
2867435528
30124157
83
4206779936
291478284
La información dentro de una cookie se organiza a partir de líneas de texto. El campo más
interesante es la tercera línea. El cliente Web la compara cada URL a la que accede; si se produce
una concordancia entre ambas, se enviará la cookie correspondiente. Es decir, una cookie asociada
a www.pepe.com/shop sólo se enviará con accesos por debajo de la sección /shop, mientras que la
cookie del ejemplo servirá para todo el servidor www.pepe.com. Las cookies pueden tener
asociada una fecha de expiración, a partir de la cual el cliente Web tratará de obtener una nueva
versión.
¿Para qué se pueden utilizar? Su aplicación más inmediata son los sistemas de compra electrónica.
Estos supermercados virtuales necesitan relacionar el contenido de un pedido con el cliente que lo
ha solicitado. Sin cookies, la solución más sencilla es incluir dentro de los documentos HTML el
contenido de las operaciones o pedidos previos, a través de variables ocultas que se envían con los
formularios que llena el cliente. Con ellas es posible relacionar los sucesivos accesos al sistema
con su origen y simplificar la gestión de la aplicación Web.
Otro uso muy interesante son los sistemas personalizados de recepción de información, en los que
es posible construir una página a medida, con información procedente de fuentes muy diversas (ver
por ejemplo my.yahoo.com/ o www.snap.com). En el primer acceso al sistema, se procede al
registro; a partir de él, se genera una cookie que recibe el cliente. En accesos sucesivos, el cliente
enviará la cookie, y el servidor podrá generar una página personalizada con las preferencias del
usuario.
Por último, algunas compañías emplean las cookies para realizar un seguimiento de los accesos a
sus servidores WWW, identificando las páginas más visitadas, la manera en que se pasa de una a
otra sección, etc.
Nota: Para utilizar las cookies, es necesario que los clientes estén preparados para
recogerlas y almacenarlas. Netscape Navigator e Internet Explorer disponen de esta
capacidad. Sin embargo, los servidores no necesitan capacidades especiales, ya que son las
aplicaciones de servidor, las encargadas de su gestión.
Por defecto, los clientes Web reciben y envían cookies sin solicitar confirmación al usuario, pero
es posible recibir avisos de la recepción de cookies, para rechazarlas en caso de no ser de nuestro
agrado. ¿Por qué rechazar las cookies?. Bueno, se pueden utilizar para seguir una pista del tipo de
información que buscamos en Internet, y ofrecer información comercial en función de ello. Sin
embargo, algunos servicios Web como tiendas on-line dependen de ellas para operar
correctamente.
Las cookies tienen un tiempo de vida, que hace que sean descartadas, pasado un cierto tiempo de
actividad. Algunas expiran al salir del cliente Web, pero otras cookies tienen una duración mayor,
por lo que el cliente Web las almacena en un archivo. Netscape utiliza el archivo cookies.txt de su
directorio de instalación, mientras que Microsoft almacena cada uno en un archivo independiente
del caché de páginas.
Las cookies son imprescindibles para operar con determinados servidores de acceso restringido, en
los cuales es preciso seguir un proceso de registro, y posiblemente abonar algún tipo de tasa.
84
Cuando se pierde una de esas cookies, por una reinstalación, fallo del computador o limpieza del
caché de páginas, en algunos casos puede ser posible regenerarla siguiendo un nuevo proceso de
registro en el servidor que la proporcionó, de forma que se relacione algún tipo de información
personal o clave de acceso proporcionado en la primera visita al servidor.
Información de las cookies
Una cookie es simplemente una serie de líneas de texto, con pares variable/valor. Existe un
conjunto predefinido de nombres de variables necesarias para el correcto funcionamiento de las
cookies, pero se pueden crear nuevas variables para cubrir las necesidades de una aplicación
concreta. Las principales variables predefinidas son:
• Domain = conjunto de direcciones Internet para el que es válida la cookie. Se puede dar
una dirección única (www.mitienda.ar) o un rango (.netscape.com).
• Path = fija el subconjunto de URLs para las que sirve esta cookie.
• Version = Permite seleccionar entre diferentes versiones del modelo de cookies.
• Expires = Fecha de expiración de la información. Si no se incluye, los datos son
descartados al finalizar la sesión con el cliente Web. En caso contrario se almacenará en el
disco del cliente. El RFC 2109 ha cambiado esta variable por Max-Age, una duración
relativa en segundos.
Un servidor HTTP envía los diferentes campos de una cookie con la cabecera HTTP Set-Cookie:
Set-Cookie: Domain=www.iua.edu.ar; Path=/; Nombre=Luis; Expires Viernes, 15-Jul-97

12:00:00 GMT
Cuando se accede a una URL que verifica el par dominio/path registrado, el cliente enviará
automáticamente la información de los diferentes campos de la cookie con la nueva cabecera
HTTP Cookie:
Cookie: Domain=www.iua.edu.ar=/; Nombre=Luis
Sitios virtuales
Es posible mantener u hospedar varios sitios en un mismo servidor. Estos sitios se pueden
diferenciar ya sea por tener varias direcciones IP y/o tener diferentes nombres de dominio DNS.
Se debe tener en cuenta que cada nombre de dominio que se pretenda utilizar debe estar registrado
en el servidor DNS que corresponda.
Cada sitio debe ser declarado como “sitio virtual” indicando su dirección IP y/o su nombre de
dominio.
Opcionalmente se deberán declarar otras propiedades del sitio como por ejemplo el nombre o path
del directorio raíz del sitio. De esta forma cada sitio tiene su propio árbol de directorios donde se
guarda el contenido del sitio.
Existe un sitio por defecto que es el que responde en caso de que se acceda al sitio indicando sola
mente la dirección IP. Dicho sitio se conoce como sitio por defecto del servidor.
85
Directorios virtuales
Es posible definir cualquier directorio ya se del mismo servidor o de otra computadora como sub-
directorio del directorio raíz del sitio. Es similar a definir una carpeta compartida. Se deberá definir
el “alias” o sea el path con que se lo ubica desde la red (por ejemplo /profesores, donde / es el
directorio raíz del sitio). También se debe definir el path real del directorio en el sistema de
archivos. Y por último las protecciones y propiedades del directorio.
86
Configuración de un servidor HTTP
Veremos a continuación los pasos que debe realizar el administrador del servicio Web para
configurar el servicio HTTP en un servidor de una intranet o Internet.
redes e Internet.
• Dirección IP
• Nombre de Host
Configuración del servicio HTTP
Veremos solo las configuraciones básicas, ya que la configuración completa es muy compleja por
la diversidad de funciones que se han incluido últimamente a un servidor de Web.
Configuraciones comunes a todos los sitios virtuales:
• Carga de módulos complementarios del servidor HTTP para realizar funciones de

extensión
• Número máximo de clientes simultáneos
• Conexión persistente o no persistente
• Protecciones de ciertos directorios del sistema de archivo
• Dirección IP y puerto donde se instala el servicio por defecto.
• Definición de tipos de archivo MIME
• Dirección de correo del administrador
• Usuario y grupo que otorga los privilegios de acceso a los usuarios anónimos (son los
usuarios que no se identifican como usuarios que disponen una cuenta en el servidor, o sea
la gran mayoría de usuarios que diariamente acceden a las páginas del sitio)
• Directorio raíz del sitio por defecto
• Documento por defecto del sitio por defecto
Configuraciones propias de cada sitio virtual:
• Nombre del sitio (el que debe figurar en el Host header)

• Directorio raíz del sitio
• Documento por defecto
• Directorios virtuales del sitio
• Dirección de correo del administrador del sitio
87
[28]
Resuma las principales características del protocolo HTTP
[29]
Defina que es un URL y de un ejemplo.
[30]
Resuma que es una conexión persistente.
[31]
Indique en que consiste la información contenida en una cabecera HTTP.
[32]
Defina a que se denomina “cookie” en el protocolo HTTP.
[33]
Resuma el uso que normalmente se da a las “cookies"
[34]
Indique a que se llama sitio virtual
[35]
Indique a que se le llama directorio virtual en un sitio HTTP.
[36]
Resuma las principales definiciones de configuración de un servidor HTTP.
88
6.4 El protocolo FTP
Este servicio pertenece a la familia de servicios esenciales de Internet y se usa para la transferencia
de archivos fundamentalmente.
Trabaja como todos los servicios TCP/IP bajo el modelo cliente/servidor. Normalmente todos los
sistemas operativos poseen un cliente FTP para bajar o subir archivos hacia el servidor FTP. Este
protocolo es universal como todos los servicios esenciales TCP/IP y por lo tanto su funcionalidad
no varía con el sistema operativo que lo contiene. Debido a su naturaleza interactiva mediante
comandos, se trata en dos partes: FTP cliente y FTP servidor.
También el comportamiento se diferencia por la identidad del usuario que accede al servicio, ya
que este puede ser un usuario que tenga una cuenta de usuario local en el servidor o ser
simplemente un usuario anónimo que accede con los privilegios de una cuenta predeterminada que
normalmente se llama “anonymous”. En el servidor se relaciona la cuenta ficticia “anonymous”
con una cuenta local que otorga los privilegios a “anonymous”.
Veremos algunas de las características del protocolo FTP de acuerdo a como se define en la
RFC959.
Terminología FTP
En el protocolo FTP se usa la siguiente terminología específica:
ASCII: El conjunto de caracteres ASCII se considera tal y como está definido en el manual de
protocolos de ARPA-Internet. En el FTP los caracteres ASCII se definen como la mitad inferior de
un código de 8 bits (i.e., el bit más significativo es cero).
Controles de acceso: Los controles de acceso definen los privilegios de acceso del usuario para el
uso de un sistema y de los archivos que hay en él. Son necesarios para evitar el uso no autorizado o
accidental de archivos. Es una prerrogativa para un proceso servidor FTP utilizar los controles de
acceso.
Tamaño de byte: Hay dos tamaños de byte interesantes en el FTP: el tamaño lógico de byte del
archivo y el tamaño de byte usado para la transmisión de los datos. El tamaño de byte utilizado
para la transmisión es siempre de 8 bits. Este tamaño no es necesariamente el tamaño de byte con
el que se guardan los datos en un sistema ni el tamaño lógico de byte para la interpretación de la
estructura de los datos.
Conexión de control: La ruta de comunicación entre el USER-PI (intérprete de protocolo del

usuario) y el SERVER-PI (intérprete de protocolo del servidor) para el intercambio de órdenes y
respuestas. Esta conexión sigue el Protocolo Telnet para el diálogo.
Conexión de datos: Una conexión bidireccional sobre la que se transfieren los datos en un modo y
tipo especificados. Los datos transferidos pueden ser una parte de un archivo, un archivo entero o
un cierto número de archivos. La conexión se puede establecer entre un server-DTP (proceso de
transferencia de datos del servidor) y un user-DTP (proceso de transferencia de datos del usuario)
o entre dos server-DTP's.
89
Puerto de datos: El proceso de transferencia pasiva de datos "escucha" en el puerto de datos hasta
que recibe una conexión del proceso de transferencia activa para abrir la conexión de datos.
DTP: El proceso de transferencia de datos (DTP, Data Transfer Process) establece y maneja la
conexión de datos. Puede ser activo o pasivo.
Fin-de-linea (EOL, end-of-line): La secuencia fin-de-linea define la separación entre líneas. La

secuencia consiste en un retorno de carro seguido de un carácter de nueva línea.
EOF (fin-de-archivo, end-of-file): La condición fin-de-archivo que define el final de un archivo

en proceso de transmisión.
EOR (end-of-record, fin-de-registro): La condición fin-de-registro que define el final de un

registro en proceso de transferencia.
Recuperación de errores: Un procedimiento que permite al usuario recuperar el control a partir

de ciertas condiciones de error, como un fallo en el servidor o en el proceso de transferencia. En el
FTP, la recuperación de errores puede implicar el reinicio de la transferencia de un archivo a partir
de un cierto punto.
Órdenes FTP: Un conjunto de órdenes que abarcan la información de control que va desde el
proceso user-FTP al proceso server-FTP.
Archivo: Un conjunto ordenado de datos del computador (incluyendo programas), de longitud

arbitraria, definido de forma única por una ruta.
Modo: El modo en que se trasfieren datos por la conexión de datos. El modo define el formato de
los datos durante la transferencia, incluyendo EOR y EOF. Los modos de transferencia definidos
para FTP se describen en la sección Modos de Transmisión.
NVT: El terminal virtual de red (Network Virtual Terminal) tal y como se define en el Protocolo
Telnet.
NVFS: El sistema de archivos virtual de red (Network Virtual File System). Un concepto que
define un sistema de archivos de red estándar con órdenes estándar y convenciones sobre los
nombres de ruta [pathname].
Página: Un archivo se puede estructurar como un conjunto de partes independientes llamadas

páginas. El FTP soporta la transmisión de archivos discontinuos como páginas indizadas
independientes.
Nombre de ruta [pathname]: El nombre de ruta se define como una cadena de caracteres que
el usuario pasa al sistema de archivos para identificar un archivo. La ruta normalmente contiene
nombres de dispositivos y/o directorios y un nombre de archivo. El FTP no especifica aún un
estándar para indicar una ruta. Cada usuario debe seguir las normas que dictan los sistemas de
archivos implicados en la transferencia para nombrar los archivos.
PI: El Intérprete del Protocolo (Protocol Interpreter). La parte del usuario y del servidor del
protocolo tienen distintos papeles que se implementan como un user-PI y un server-PI.
90
Registro: Un archivo secuencial se puede estructurar en un número de partes contiguas llamadas

registros. El FTP soporta las estructuras de registro, pero un archivo no tiene por qué tener una
estructura de registro.
Respuesta: Una respuesta es un asentimiento (positivo o negativo) enviadapor el servidor al

usuario a través de la conexión de control en respuesta a una orden FTP. La forma general de una
respuesta es un código de terminación seguido de una cadena de texto. Los códigos son usados por
los programas y el texto por las personas.
Server-DTP (server Data Transfer Process): El proceso de transferencia de datos (Data Transfer
Process), en su estado normal de "activo", establece una conexión de datos con el puerto de datos
que está a la espera. Prepara los parámetros para transferir y almacenar y transfiere los datos
cuando así se requiere a través de su PI. El DTP se puede poner en estado "pasivo" para esperar
una conexión, en lugar de iniciarla.
Proceso server-FTP: Un proceso o un conjunto de ellos que realizan la función de transferencia

de archivos en conjunción con el proceso user-FTP y, posiblemente, otro servidor. Las funciones
consisten en un intérprete de protocolo (PI) y un proceso de transferencia de datos (DTP).
Server-PI (server Protocol Interpreter): El intérprete de protocolo del servidor "escucha" en el

puerto L hasta que recibe una conexión de un user-PI y establece una conexión de comunicaciones
para control. Recibe órdenes FTP estándar desde el user-PI, envía respuestas y controla el server-
DTP.
Tipo: El tipo de representación de datos usado para transferir y almacenar los datos. El tipo
implica ciertas transformaciones a la hora de almacenar y enviar los datos. Los tipos de
representación definidos en el FTP se describen en la sección titulada "Estableciendo conexiones
de datos".
Usuario: Una persona o un proceso en su lugar que desea utilizar el servicio de transferencia de
archivos. La persona puede interactuar directamente con el proceso server-FTP, pero se prefiere el
uso de un proceso user-FTP ya que el diseño del protocolo está orientado a su utilización por
autómatas.
User-DTP (user Data Transfer Process): El Proceso de Transferencia de Datos espera a recibir
una conexión en el puerto de datos desde el proceso server-FTP. Si dos servidores están
transfiriendo datos entre ellos, el user-DTP permanece inactivo.
proceso user-FTP: Un conjunto de funciones incluyendo un intérprete de protocolo, un proceso

de transferencia de datos y una interfaz de usuario que juntos realizan la función de transferir
archivos en cooperación con un proceso server-FTP. La interfaz de usuario permite usar un
lenguaje local en el diálogo orden-respuesta con el usuario.
User-PI (user Protocol Interpreter): El intérprete de protocolo de usuario inicia la conexión de

control desde su puerto U hasta el proceso server-FTP, envía órdenes FTP y controla el user-DTP
si es necesario para la transferencia de archivos.
91
El modelo FTP
Teniendo en cuenta las definiciones anteriores, el siguiente modelo representa un diagrama de un

servicio FTP.
NOTAS:
1. La conexión de datos es bidireccional.

2. La conexión de datos no tiene por qué existir todo el tiempo.
En el modelo descrito en la figura, el intérprete de protocolo de usuario (user-PI), inicia la

conexión de control.
La conexión de control sigue el Protocolo Telnet. Las órdenes FTP estándar las genera el user-PI y
se transmiten al proceso servidor a través de la conexión de control. (El usuario puede establecer
una conexión de control directa con el server-FTP, desde un terminal TAC –terminal de control de
acceso como un cliente telnet- por ejemplo, y enviar órdenes FTP estándar, obviando así el proceso
user-FTP.) Las respuestas estándar se envían desde el server-PI al user-PI por la conexión de
control como contestación a las órdenes.
Las órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de
transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema
de archivos (almacenar, recuperar, añadir, borrar, etc.). El user-DTP u otro proceso en su lugar,
debe esperar a que el servidor inicie la conexión al puerto de datos especificado y transferir los
datos en función de los parámetros que se hayan especificado. Se debe aclarar que el puerto de
datos no tiene por qué estar en el mismo computador que envía las órdenes FTP a través de la
conexión de control, pero el usuario o el proceso user-FTP debe asegurarse de que se espera la
conexión en el puerto de datos indicado. También hay que destacar que la conexión de datos se
puede usar simultáneamente para enviar y para recibir.
En otra situación, un usuario puede querer transferir archivos entre dos computadores que no son
locales. El usuario prepara las conexiones de control con los dos servidores y da las órdenes
necesarias para crear una conexión de datos entre ellos. De esta forma, la información de control se
envía por el user-PI pero los datos se transfieren entre los procesos de transferencia de datos de los
servidores. A continuación se muestra un modelo de esta interacción servidor-servidor.
92
El protocolo requiere que las conexiones de control permanezcan abiertas mientras se transfieren
datos. Es responsabilidad del usuario solicitar el cierre de las conexiones de control una vez
termine de usar el servicio, mientras que el servidor es el encargado de cerrarlas. El servidor puede
interrumpir la transferencia de datos si las conexiones de control se cierran sin previa solicitud.
La relación entre FTP y Telnet: El protocolo FTP usa el protocolo Telnet en la conexión de
control. Esto se puede conseguir de dos formas: primera, el user-PI o el server-PI pueden
implementar las reglas del Protocolo Telnet directamente; o, segunda, el user-PI o el server-PI
pueden usar el módulo Telnet que exista en el sistema.
La facilidad de implementación, compartir código y la programación modular, están a favor de la

segunda aproximación. La eficiencia y la independencia abogan por la primera aproximación. En
la práctica, el FTP no depende mucho del protocolo Telnet, por ello la primera aproximación no
necesariamente implica gran cantidad de código.
93
Transferencia de datos
Los archivos sólo se transmiten por la conexión de datos. La conexión de control se usa para
enviar órdenes, que describen la función a realizar, y las repuestas a estas órdenes. Varias órdenes
se refieren a la transferencia de datos entre computadores.
Estableciendo conexiones de datos
La mecánica de transferir datos consiste en preparar la conexión de datos en los puertos apropiados
y elegir los parámetros para la transferencia. El usuario-DTP y los server-DTPs tienen ambos un
puerto por defecto. El puerto por defecto del proceso de usuario es el mismo que el puerto de la
conexión de control (i.e., U). El puerto por defecto del proceso servidor es el puerto adyacente al
puerto de la conexión de control (i.e., L-1).
El proceso de transferencia de datos pasivo que espera el inicio de conexión (que puede ser un
user-DTP o un segundo server-DTP) deberá "escuchar" en el puerto de datos antes de enviar una
orden de petición de transferencia.
Esta orden determina el sentido de la transferencia de los datos. El servidor, una vez recibida la
petición de transferencia, iniciará la conexión de datos al puerto indicado. Una vez establecida la
conexión, la transferencia de datos comienza entre los DTPs, mientras el server-PI envía una
respuesta de confirmación al user-PI.
Todas las implementaciones del FTP deben soportar el uso de los puertos de datos por defecto y
sólo el user-PI puede solicitar un cambio a un puerto diferente.
Conexión de datos
Puertos de la conexión de datos por defecto: Todas las implementaciones del FTP deben
soportar el uso de los puertos de datos por defecto y sólo el user-PI puede iniciar el uso de otros
puertos.
Negociando puertos de datos distintos a los que hay por defecto: el user-PI puede especificar
un puerto de datos diferente por su parte con la orden PORT. El user-PI puede solicitar al servidor
la localización de un puerto en el propio servidor con la orden PASV.
Como una conexión está definida por el par de direcciones, cualquiera de estas acciones es
suficiente para tener una conexión de datos diferente, pero se permite usar ambas órdenes para
utilizar nuevos puertos en los dos lados de la conexión.
94
Modos de transmisión
Otro aspecto a considerar en la transferencia de datos es la elección apropiada del modo de
transmisión. Hay tres modos: uno que formatea los datos y permite reiniciar la transmisión; otro
que además comprime los datos para una transferencia eficaz; y otro que pasa los datos sin apenas
procesarlos.
Todas las transferencia de datos se deben complementar con un fin-de-archivo (EOF, end-of-file)
que se puede indicar explícita o implícitamente cerrando la conexión de datos. Para archivos con
estructura de registro, todos los indicadores de fin-de-registro (EOR) son explícitos, incluyendo el
último. Para archivos transmitidos con estructura de página, se usa una página con el indicador de
última página activado.
Se definen los siguientes modos de transmisión en el FTP:
Modo flujo: Los datos se transmiten como un flujo de bytes. No hay ninguna restricción en el tipo
de representación usado; se permiten estructuras de registro.
Modo bloque: El archivo se transmite como una serie de bloques de datos precedidos por uno o
más bytes cabecera.
Modo comprimido: Hay tres clases de información a enviar: datos normales, enviados en una
cadena de bytes; datos comprimidos, formados por repeticiones o relleno; e información de
control, enviada en una secuencia de escape de dos bytes.
EL modo comprimido es útil para obtener un ancho de banda adicional en transmisiones muy
largas con un costo extra de CPU muy pequeño.
95
El cliente FTP
El cliente FTP es el navegador de Internet para usar desde una interfaz gráfica con el URL:
ftp://nombre_del_sitio/path
Esto es para el usuario anonymosus. Si el usuario tiene una cuenta en el servidor, será:
ftp://nombre_de_la _cuenta,contraseña@ nombre_del_sitio/path

La forma básica universal del cliente FTP es sin embargo mediante el comando “ftp” como
veremos a continuación.
Estudiaremos algunos de los comandos FTP que se pueden ejecutar desde el cliente para
interactuar con el servidor FTP.
Comando ftp
Transfiere archivos a y desde un equipo ejecutando un servicio Servidor de ftp. El comando ftp
puede utilizarse de manera interactiva tipeando ftp en la línea de comandos. Este comando está
disponible sólo si se ha instalado el protocolo TCP/IP. Ftp es un servicio, que, una vez iniciado,
crea un sub-entorno en el que es posible utilizar comandos propios de ftp y desde el que se puede
volver al símbolo del sistema al escribir el sub-comando quit. Cuando se está ejecutando el sub-
entorno ftp, el símbolo del sistema de ftp lo indica.
ftp [-v] [-n] [-i] [-d] [-g] [-s:nombreDeArchivo] [-a] [-w:tamañoDeVentana] [equipo]
Parámetros
-v
Suprime la presentación de las respuestas del servidor remoto.
-n
Suprime el inicio de sesión automático cuando establece la conexión.
-i
Desactiva las peticiones interactivas de datos durante la transferencia de múltiples archivos.
-d
Habilita la depuración y muestra todos los comandos ftp transferidos entre el cliente y el
servidor.
-g
96
Deshabilita el uso de comodines en nombres de archivos, lo que permite utilizar caracteres

comodín (* y ?) en nombres locales de archivos y rutas de acceso. (Consulte el comando
glob en la "Referencia de comandos en pantalla").
-s:nombreDeArchivo
Especifica un archivo de texto que contiene comandos de ftp. Éstos se ejecutan

automáticamente en cuanto se inicia ftp. En este parámetro no se admiten espacios. Utilice
este modificador en lugar de la redirección (>).
-a
Utilice cualquier interfaz local cuando enlace una conexión de datos.
-w:tamañoDeVentana
Suplanta el tamaño de 4096 del búfer de transferencia predeterminado.
computer
Especifica el nombre de equipo o la dirección IP del equipo remoto con el que establece la
conexión. Si especifica el equipo, debe ser el último parámetro de la línea.
Comandos de ftp
Los comandos propios de FTP cliente son los siguientes (hay pequeñas diferencias entre las
plataformas):
Ftp: ! Ftp: glob Ftp: put

Ftp: ? Ftp: hash Ftp: pwd
Ftp: append (anexar) Ftp: help (ayuda) Ftp: quit
Ftp: ascii Ftp: lcd Ftp: quote
Ftp: bell Ftp: literal Ftp: recv
Ftp: binario Ftp: ls Ftp: remotehelp
Ftp: bye Ftp: mdelete Ftp: rename
Ftp: cd Ftp: mdir Ftp: rmdir
Ftp: close Ftp: mget Ftp: send
Ftp: debug (depurar) Ftp: mkdir Ftp: status
Ftp: delete Ftp: mls Ftp: trace
Ftp: dir Ftp: mput Ftp: type
Ftp: disconnect Ftp: open Ftp: user
Ftp: get Ftp: prompt Ftp: verbose
A continuación explicaremos los más importantes:
97
Ftp: !
Salir del subsistema ftp al intérprete de comandos.
Nota
• Este comando se utiliza sin parámetros. Utilícelo cuando haya terminado de usar
comandos ftp y desee volver al intérprete de comandos del sistema operativo local.
Ftp: cd
Cambia el directorio de trabajo en el equipo remoto.
cd directorioRemoto
Parámetro
directorio_remoto
Especifica el directorio del equipo remoto al cual se desea cambiar.
Ftp: dir
Muestra una lista de los archivos y subdirectorios de un directorio remoto.
dir [directorioRemoto] [archivoLocal]
Parámetros
directorio_remoto
Especifica el directorio cuyo contenido desea examinar. Este parámetro debe especificarse
siempre. Si no especifica ningún directorio, se utilizará el directorio de trabajo actual del
equipo remoto.
archivo_local
Especifica un archivo local en el cual se guardará la lista. Si no se especifica este

parámetro, el resultado se presentará en pantalla.
Ftp: Help (Ayuda)
Presenta una descripción de los comandos ftp.
help [comando]
Parámetro
98
comando
Especifica el nombre del comando acerca del cual desea obtener más información. Si no
especifica el parámetro comando, ftp mostrará una lista completa de todos los comandos.
Ftp: lcd
Cambia el directorio de trabajo del equipo local. De forma predeterminada, el directorio de

trabajo es en el que se ha iniciado ftp.
lcd [directorio]
Parámetro
directorio
Especifica el directorio del equipo local al cual se desea cambiar. Si no se especifica el

parámetro directorio, se mostrará el directorio de trabajo actual del equipo local.
Ftp: get
Baja un archivo desde el servidor hacia el directorio local.
get archivo
Ftp: ls
Muestra una lista resumida de los archivos y subdirectorios de un directorio remoto.
ls [directorioRemoto] [archivoLocal]
Parámetros
directorio_remoto
Especifica el directorio cuyo contenido desea examinar. Este parámetro debe especificarse
siempre. Si no especifica ningún directorio, se utilizará el directorio de trabajo actual del
equipo remoto.
archivo_local
Especifica un archivo local en el cual se guardará la lista. Si no se especifica este

parámetro, el resultado se presentará en pantalla.
FTP: mput
Copia archivos locales en el equipo remoto utilizando el tipo actual de transferencia de

archivos.
99
mput archivosLocales [ ...]
Parámetro
archivos_locales
Especifica los archivos locales que se copiarán en el equipo remoto.
Ftp: open
Establece la conexión con el servidor de FTP especificado.
open equipo [puerto]
Parámetros
computer
Especifica el equipo remoto con el cual desea establecer una conexión. El equipo puede
especificarse mediante una dirección IP o un nombre de equipo (deberá haber un archivo
DNS o HOSTS disponible). Si está activada la opción de inicio de sesión automático (valor
predeterminado), ftp también intentará registrar al usuario automáticamente en el servidor
de FTP (para obtener más información acerca de cómo desactivar el inicio de sesión
automático, haga clic en ftp en la lista Temas relacionados).
puerto
Especifica un número de puerto que se utilizará para entrar en contacto con el servidor de
FTP.
Ftp: prompt
Activa o desactiva la aparición de un mensaje de confirmación. Ftp, durante una

transferencia de varios archivos, requerirá confirmación para seleccionar los archivos que
va a recuperar o a almacenar, mientras que los comandos mget y mput transferirán todos
los archivos si esta solicitud de confirmación está desactivada. De forma predeterminada,
esta opción está activada.
prompt
Ftp: put
Copia un archivo local en el equipo remoto utilizando el tipo actual de transferencia de

archivos.
put archivoLocal [archivoRemoto]
Parámetros
100
archivo_local
Especifica el archivo local que se va a copiar.
archivo_remoto
Especifica el nombre que se asignará al archivo en el equipo remoto. Si no se especifica

este parámetro, el archivo adoptará el nombre del archivoLocal.
Ftp: pwd
Muestra el directorio actual del equipo remoto.
pwd
Ftp: quit
Finaliza la sesión FTP con el equipo remoto y sale de ftp.
quit
Ftp: usuario
Especifica un usuario en el equipo remoto.
user nombreDeUsuario [contraseña] [cuenta]
Parámetros
nombre_usuario
Especifica un nombre de usuario con el cual se iniciará una sesión en el equipo remoto.
contraseña
Especifica la contraseña para el nombreDeUsuario. Si este parámetro es necesario, ftp le

pedirá que escriba la contraseña aunque ésta no se haya especificado.
cuenta
Especifica una cuenta con la que se iniciará la sesión en el equipo remoto. Si no se

especifica la cuenta, pero es necesaria, ftp le pedirá que la escriba
Códigos de respuestas
En un diálogo, se responde a cada comando con un código de respuesta y un mensaje, es decir, los
servidores de FTP manejan códigos estándar para dar información al usuario sobre una operación
concreta, por ejemplo ejecutaremos el comando get para bajar un archivo del sitio FTP:
101
ftp> get nombre_del_archivo

--> PORT 128,36,0,22,10,54
200 PORT COMMAND SUCCESSFUL
-- RETR archive
150 Opening ASCII mode data connection for archive (4112 bytes).
226 Transfer complete.
Los códigos de respuestas se componen de tres dígitos. Cada uno tiene un cometido específico:
• Los códigos en el rango de los 200 indican que el comando se realizó con éxito.
• Los códigos en el rango de los 100 indican que se ha comenzado a realizar una acción.
• Los códigos en el rango de los 300 indican que se ha alcanzado con éxito un punto
intermedio
• Los códigos en el rango de los 400 indican errores pasajeros
• Los códigos en el rango de los 500 son realmente malas noticias e indica un error
permanente.
Los dígitos segundo y tercero de un código de respuesta, clasifican la respuesta de forma más
precisa.
102
El Servidor FTP
También en este servicio podemos definir servidores virtuales, o sea instancias de servidor que
responden a nombres diferentes con direcciones IP diferentes pero en la misma computadora.
Es posible definir también directorios virtuales en cada servidor virtual, que no son más que
directorios que se ubican lógicamente en el sitio FTP pero que físicamente están en alguna carpeta
del servidor (no necesariamente debajo del directorio raíz del sitio) o incluso en una carpeta
compartida de otro servidor.
Este servicio presenta una característica de seguridad de acceso a través de contraseña, pero
también puede permitir acceso anónimo, usando una cuenta definida para ese propósito.
Normalmente el nombre de login de esa cuenta es anonymous y la contraseña es la dirección de
correo del usuario.
Configuración de un servidor FTP
Veremos a continuación los pasos que debe realizar el administrador del servicio FTP para
configurar el servicio FTP en un servidor de una intranet o Internet.
redes e Internet.
• Dirección IP
• Nombre de Host
Configuración del servicio FTP.
• Dirección IP: Define la dirección IP donde se instala el servicio

• Puerto TCP: Determina el puerto que está utilizando el servicio. El puerto predeterminado
es el 21. Puede cambiarlo por cualquier número exclusivo de puerto TCP; no obstante, los
clientes deben saberlo de antemano para pedir ese número de puerto o, de lo contrario, no
conseguirán conectarse al servidor.
• Numero máximo de usuarios: Cantidad máxima de usuarios que pueden conectarse
simultáneamente.
• Tiempo de espera de la conexión: Establece el intervalo de tiempo que va a esperar el
servidor antes de desconectar a un usuario inactivo. De esta forma se asegura que todas las
conexiones se cierren si el protocolo HTTP no puede cerrar una conexión.
• Habilitar registro: Activa el registro del sitio FTP, que puede registrar detalles acerca de
la actividad de los usuarios y crear registros en varios formatos
103
• Cuentas de seguridad: controla quién puede utilizar el servidor y especificar la cuenta

empleada para que los clientes anónimos inicien una sesión en el equipo.
• Mensaje de bienvenida: Contenido del texto que se muestra a los clientes cuando se
conectan al servidor FTP. De manera predeterminada, este mensaje está en blanco.
• Mensaje de salida: Presenta este texto a los clientes cuando se desconectan del servidor
FTP. De manera predeterminada, este mensaje está en blanco.
• Mensaje de conexiones máximas: Presenta este texto a los clientes que intentan
conectarse cuando el servicio FTP ya tiene el número máximo permitido de conexiones de
clientes. De manera predeterminada, este mensaje está en blanco.
• Directorio raíz del sitio FTP: Se indica el path del directorio raíz del sitio, que es una raíz
virtual para el usuario anonymous. El usuario anonymous no podrá acceder a un directorio
en el sistema de archivos del servidor que se encuentre por encima de este directorio.
• Protecciones de los directorios del sitio: se indican las protecciones que se aplican a todos
los usuarios que acceden al sitio FTP
• Definición de sitios virtuales: Solo son posibles otros sitios si se les asigna distintas
direcciones IP. En este protocolo no existe el Host header como en HTTP
• Definición de directorios virtuales: Se especifican mediante el alias, path y protecciones.
• Habilitar la carga de archivos hacia el servidor para el usuario anonymous: Es
necesario indicar en forma explícita la habilitación para que el usuario anonymous pueda
subir archivos al servidor.
[37]
Resuma las características básicas del servicio FTP.
[38]
Indique cual es la discriminación básica que se aplica a la conexión de usuarios.
[39]
Indique que significa: acceso anónimo.
[40]
Cual es el tipo de acceso (local o anónimo) que Usted considera más seguro.
[41]
Resuma cuales son las conexiones básicas en el servicio FTP.
[42]
Indique cuales son los procesos que se ejecutan tanto en cliente como en el servidor FTP.
104
[43]
Indique cuales son los modos de transferencia de datos en el protocolo FTP.
[44]
Indique 7 comandos que usted considere como básicos o habituales en una sesión FTP.
[45]
Indique las definiciones básicas que configuran a un servidor FTP.
105
6.5 El servicio de Correo Electrónico
El correo electrónico es posiblemente el servicio más utilizado de todos los que existen
actualmente con arquitectura cliente-servidor. Gracias a este se tiene la posibilidad de comunicarse
rápidamente con todo el mundo desde una estación de trabajo de forma muy simple y barata
incluso con los teléfonos celulares tan difundidos en nuestro medio.
Basta con tener un buzón en un servidor de correo correctamente configurado y una aplicación
cliente (en una forma precaria pero efectiva basta con solo disponer de un programa como telnet
para enviar mensajes a un servidor de correo) para operar con dicho buzón.
Un buzón de correo electrónico no es más que un archivo o un conjunto de ellos agrupados en un

directorio donde se almacenan en cierto formato los mensajes de los usuarios.
El Agente de transferencia de mensajes
Los MTAs (Mail Transport Agent) o agentes para la trasmisión de correo son aquellos programas
servidores que permiten transportar el correo electrónico de una máquina a otra a través de la red.
Como ejemplos de MTAs se pueden citar a Sendmail, Qmail, Postfix, Exchange Server y otros.
Todos hablan el mismo idioma, o sea utilizan un protocolo común para la comunicación: el SMTP
(Simple Mail Transfer Protocol).
El SMTP como su nombre lo indica es un protocolo muy simple orientado a caracteres y que
permite el traslado de los correos tanto desde el cliente al servidor como entre servidores.
Normalmente los servidores de correo utilizan el puerto 25 para comunicarse mediante el SMTP.
Las funciones básicas de protocolo SMTP son las siguientes:
1. Acepta un mensaje entrante en un puerto por defecto (normalmente el puerto 25).

2. Comprueba las direcciones del mensaje.
3. Si son direcciones locales, almacena el mensaje local para después recuperarlo.
4. Si son direcciones remotas, envía el mensaje remoto.
Por tanto, los servidores SMTP son funcionalmente similares a los routers de paquetes.
Normalmente, un mensaje pasará a través de varias pasarelas SMTP antes de llegar a su destino
final. En cada parada, el servidor SMTP evalúa el mensaje y lo almacena o lo envía. También
puede suceder que si el servidor SMTP encuentra un mensaje que no se puede enviar, este
devuelva un mensaje de error al remitente explicando el problema.
El Agente de distribución de mensajes
También entran en juego los MDA's (Mail Delivery Agent) o Agentes de Distribución de Correo
que se encargan de mover el correo dentro de un sistema, es decir, desde un MTA al buzón local
de un usuario, o del buzón hacia un MUA mediante POP3 o IMAP.
106
El Agente de mensajes del usuario
Por otro lado se encuentran los MUAs (Mail User Agents) que son los programas clientes que
posibilitan a los usuarios manipular su mensajería. Estos programas son ejecutados directamente
por los usuarios. Proveen facilidades para escribir los mensajes, enviarlos, descargar y leer los que
llegan, organizarlos en directorios, hacer búsquedas, imprimirlos, mantener un libro de direcciones
electrónicas, etc.
Ejemplos de MUAs en Linux son los progamas: pine, mail, mutt y elm. Para entornos gráficos
están el Netscape Messenger y el kmail del entorno KDE. En la plataforma de Windows está el
conocido Outlook.
También es posible interactuar con páginas Web para la tarea de cliente, que se conoce como Web
Mail. La ventaja de este último es que toda computadora dispone de un navegador que sería el
cliente y se aprovecha la tecnología de multimedios que proporciona un sitio Web.
Para enviar los mensajes, los MUAs se pueden conectar a un MTA determinado utilizando SMTP
o escribir los mensajes directamente en el buzón si este es local.
En cambio para descargar la mensajería un MUA puede hacerlo localmente o emplear alguna
variante de dos protocolos fundamentales: POP (Post Office Protocol) o IMAP (Internet Message
Access Protocol).
Estos se diferencian en que el primero descarga la mensajería en la máquina local y el segundo

permite manipularla directamente en el servidor y descargarla selectivamente.
Un programa servidor de correo no necesariamente acepta conexiones para descargar la mensajería

que él manipula, pues no siempre constituyen el destino final de la misma.
Esta función constituye un servicio adicional, si el sistema además de gestionar el envío de la

mensajería mediante un MTA permite descargarla a un almacén de correo, debe ejecutarse también
un programa servidor de POP o IMAP que brinde dicha funcionalidad. Actualmente en el caso de
POP se emplea su versión 3 conocida como POP3.
En la figura se representa de forma simplificada como funciona el servicio de correo electrónico y

los elementos que intervienen en este proceso.
107
Representación esquemática del servicio de correo electrónico
Formato de un mensaje de correo electrónico
El mensaje de correo electrónico que envía su computadora sigue una norma internacional con el
objeto de ser "legible" para quien lo recibe.
Básicamente un mensaje se divide en tres partes:
• Encabezado ("Header")
• Cuerpo del mensaje
• Archivos adjuntos ("Attachment")
Encabezado: El encabezado del mensaje normalmente no está a la vista de quien lo recibe; no

obstante, la gran mayoría de los programas de correo electrónico (Outlook, Eudora, Pegasus, etc),
permite al usuario examinarlo. En el Outlook Express, Ud. podrá ver el encabezado marcando el
mensaje y buscando en el menú el ítem "Propiedades".
Esta es la estructura básica de un encabezado de e-mail:
Return-Path: <pepe@pepe.com>
Received: from maquina1 (maquina1.pepe.com [192.168.73.129]
by mail.iua.edu.ar (8.9.3/8.9.3) with ESMTP id RAA20801
for <info@iua.edu.ar>; Tue, 29 Aug 2000 17:08:21 -0400
From: "Pepe Pepe" < pepe@pepe.com >
To: < info@iua.edu.ar >
Subject: Importante
Date: Tue, 29 Aug 2000 18:08:21 -0300
Message-ID: <Este_es_el_mensaje…………………………. >
108
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0000_01C011DF.871D08A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-UIDL: 102a4a2c4e95ed6dd5ac92e9f6e1b072
Analizaremos cada una de las líneas relevantes:
Return-Path: pepe@pepe.com
Return-Path es la dirección del remitente. Esta dirección puede ser alterada para evitar detectar el
verdadero remitente.
Received: from maquina1 (isp.pepe.com [192.168.73.129])

by mail.iua.edu.ar (8.9.3/8.9.3) with ESMTP id RAA20801
for <info@iua.edu.ar>; Tue, 29 Aug 2000 17:08:21 -0400
En este caso, maquina1 es el nombre de la computadora que envió el mensaje, e isp.pepe.com

[192.168.73.129] es el nombre y dirección IP del proveedor de Internet utilizado para enviar el
mensaje.
mail.iua.edu.ar (8.9.3/8.9.3) es el nombre del servidor que recibió el mensaje para Ud.
for <info@iua.edu.ar>; Tue, 29 Aug 2000 17:08:21 -0400 es la dirección del

destinatario, más la fecha y hora en que fue despachado.
Las demás líneas tienen que ver con particularidades de los servidores y del software utilizado para
redactar el mensaje.
Cuerpo del mensaje:
Es el mensaje en sí, tal como Ud. lo ve en su pantalla. Puede estar redactado en formato de texto
plano ("Plain Text") y/o HTML, es decir como una página web, lo que permite darle formato al
texto, utilizar un gráfico de fondo, etc.
Archivos Adjuntos ("Attachments"):
La gran mayoría de los programas de correo electrónico actuales tiene la posibilidad de adjuntar al
texto del mensaje, un archivo, usualmente residente en el disco de su computadora. Este archivo
puede ser de cualquier tipo (programa ejecutable (exe), archivo comprimido (zip), imagen gráfica
(GIF, JPG, etc.).
Como consejo general, cuídese de los attachments. Esto significa que nunca debe abrir un archivo
adjunto de cualquier tipo que provenga de un desconocido, ya que aquí es donde puede
transmitirse código malicioso (virus) a su computadora. Si el adjunto proviene de una persona
109
conocida, puede abrirlo, pero siempre con un antivirus actualizado instalado en su máquina. Nunca
abra un archivo adjunto que sea ejecutable en su computadora!!!.
110
Protocolo Simple de Transmisión de Correo (SMTP)
El significado de las siglas de SMTP, como se señaló anteriormente, es Protocolo Simple de

Transmisión de Correo ("Simple Mail Transfer Protocol"). Este protocolo es el estándar de Internet
para el intercambio de correo electrónico. SMTP necesita que el sistema de transmisión ponga a su
disposición un canal de comunicación fiable y con entrega ordenada de paquetes, con lo cual, el
uso del protocolo TCP en la capa de transporte, es lo adecuado.
Para que dos sistemas intercambien correo mediante el protocolo SMTP, no es necesario que exista
una conexión interactiva, ya que este protocolo usa métodos de almacenamiento y reenvío de
mensajes.
Son tres los protocolos que se aplican a un transporte de correo de esta clase. El termino SMTP es
frecuentemente y erróneamente usado para referirse a la combinación del grupo de protocolos
involucrados en el envío de correo electrónico. Esto es porque los tres están estrechamente
relacionados, pero estrictamente hablando SMTP es uno de los tres protocolos. Los tres protocolos
son:
1. Un estándar para el intercambio de correo entre dos computadores (RFC 821,

actualizado mediante el RFC 2821), el cual especifica el protocolo usado para enviar
correo entre "host" TCP/IP. Este estándar es SMTP.
2. Un estándar del formato del mensaje de correo, contenido en dos RFC:
• RFC 822 (actualizado por el RFC 2822) describe la sintaxis del campo de título
o cabecera del correo electrónico y describe la interpretación del grupo de
campos de la cabecera.
• RFC 1049 describe como un conjunto de otros tipos de documentos, que tengan
texto ASCII, y que pueden ser usados en el cuerpo del correo electrónico.
3. Un estándar para el "routing" de correo usando el sistema de nombres de dominio,
descrito en RFC 974 (actualizado por el RFC 2821) .
De todos modos esto es bastante cambiante. Lo cierto es que normalmente se definen varias
especificaciones para tratar partes de una función. En este caso se trata de recibir en mensaje,
interpretarlo y darle salida a un nuevo destino. A todo esto comúnmente se le llama SMTP. Al
servidor que realiza estas funciones se lo llama servidor SMTP.
Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP, el emisor
(servidor que inicia la sesión SMTP) establece una conexión con el receptor (servidor que recibe
petición de establecer sesión SMTP). Esta conexión es unidireccional, es decir, el emisor puede
enviar correo al receptor, pero durante esa conexión, el receptor no puede enviar correo al emisor.
Si el receptor tiene que enviar correo al emisor, tiene que esperar a que finalice la conexión
establecida y establecer otra en sentido contrario, cambiando los papeles de emisor y receptor. Una
vez establecida la conexión, el emisor envía comandos y mensajes.
Los mensajes pueden tener como destino el receptor o un intermediario para llegar a un destino
más lejano. El receptor puede enviar al emisor respuestas y códigos de estado.
Los comandos son cadenas de caracteres que se pueden entender fácilmente y las respuestas son
códigos numéricos seguidos de una explicación del código.
111
Por lo señalado, SMTP está basado en entrega "end-to-end". Esto es diferente del principio guardar
y enviar común en muchos sistemas de mensajería electrónica, donde el mensaje puede pasar a
través de un numero de maquinas intermediarias en su camino al destino final.
Existen aplicaciones que permiten intercambiar correo entre el sistema de mensajería electrónica
TCP/IP SMTP y el sistema de correo localmente usado.
Estas aplicaciones son llamadas "Gateways" de correo o "Bridges" de correo. Enviar correo a
través de un "Gateway" puede alterar la entrega "end-to-end". El protocolo SMTP solo puede
garantizar la entrega al "Gateway" y no al destino final, que está localizado más allá de la red
TCP/IP.
Cuando el "Gateway" es usado, la transmisión "end-to-end" se realiza en varias partes, de "host" a

"Gateway", "Gateway" a "host" o "Gateway" a "Gateway". El comportamiento más allá del
"Gateway" no está especificado por SMTP. En la siguiente figura se observa la comunicación a
través de los "Gateways".
SMTP se basa en el modelo de comunicación que se muestra en la siguiente figura.
En este modelo de comunicación en primera instancia un usuario establece la petición de enviar un

mensaje a través de correo electrónico, luego el Emisor SMTP establece una conexión de dos hilos
con el Receptor SMTP. El Receptor SMTP puede ser la destinación última o un intermediario,
como es el caso del "Gateway".
El Emisor SMTP genera comandos que son contestados por el Receptor SMTP.
112
Los comandos y respuestas son estrictamente definidos por el protocolo, el intercambio de ellos
entre emisor y receptor resultar fácil de comprender.
Todo intercambio de comandos/respuesta/datos (líneas de texto) es delimitado por un CRLF. Toda

respuesta tiene un código numérico al principio de la línea.
A continuación veremos los comandos SMTP para comprender las características de intercambio
de mensajes entre cliente SMTP y servidor SMTP o entre servidores SMTP que intercambian
mensajes.
• DATA • MAIL • SAML

• EHLO • NOOP • SEND
• EXPN • QUIT • SOML
• HELO • RCPT • TURN
• HELP • RESET • VRFY
Como el protocolo es orientado a caracteres, se puede interactuar con el servidor mediante cadena
de caracteres ASCII que corresponden a los comandos SMTP, usando el cliente del protocolo
TELNET.
Vemos a continuación un ejemplo que nos permite enviar un mensaje de correo a un servidor
SMTP solamente mediante el cliente Telnet que siempre está disponible en cualquier computadora.
Este intercambio interactivo de mensajes está automatizado en los programas que usan SMTP para
la comunicación entre cliente SMTP y servidor SMTP o entre servidores SMTP.
Protocolo SMTP desde un cliente Telnet hacia un servidor SMTP
Usamos, en este ejemplo, el comando:
113
telnet sigma.eafit.edu.co 25
Ud. Deberá indicar el nombre de dominio de su servidor de correo saliente (MTA con SMTP).
Par iniciar la conexión con el servidor SMTP en el puerto 25. Habilite el echo local del emulador
de Terminal, para poder ver los comandos que el cliente digita.
Esto les permitirá conectarse al servicio SMTP. Ahora componga manualmente el mensaje de
correo y pruebe algunos comandos que soporta el servidor.
Una vez conectado al servidor de correo, éste le enviará un mensaje de conexión y quedará en
modo de espera a que usted le introduzca comandos. A continuación indicamos el diálogo entre
cliente (transmisor) y servidor (receptor) SMTP. Este diálogo se muestra en la pantalla del cliente
interactivo. Se indica la forma más simple. Es posible indicar encabezados, el asunto, etc.
telnet sigma.eafit.edu.ar 25
220 sigma.eafit.edu.co ESMTP Sendmail 8.11.6/8.11.6; Wed, 24 Apr 2005 10:27
HELO eafit.edu.ar
250 sigma.eafit.edu.ar Hello firewall.ucbcba.edu.ar [166.114.106.8], pleased to
meet you
HELP
214-2.0.0 This is sendmail version 8.11.6
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN AUTH
214-2.0.0 STARTTLS
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation send email to
214-2.0.0 sendmail-bugs@sendmail.org.
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
MAIL FROM: usuario@eafit.edu.ar
250 2.1.0 emontoya@eafit.edu.ar... Sender ok
RCPT TO: userst@dominio.subdominio (especifica el destino)
250 2.1.5 usert@dominio.subdominio Recipient ok
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Hola como estas, esta es una prueba de
correo electrónico.
bla, bla, bla, ...
.
250 2.0.0 g3OFd0s14381 Message accepted for delivery
A continuación se aclara la secuencia interactiva entre cliente y servidor.
114
Cliente Servidor
telnet sigma.eafit.edu.ar 25
220 sigma.eafit.edu.co ESMTP Sendmail
8.11.6/8.11.6; Wed, 24 Apr 2005 10:27
HELO eafit.edu.ar
250 sigma.eafit.edu.ar Hello

firewall.ucbcba.edu.ar [166.114.106.8], pleased
to meet you
HELP
(lista todos los comandos que soporta)
214-2.0.0 This is sendmail version 8.11.6
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN AUTH
214-2.0.0 STARTTLS
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation send email to
214-2.0.0 sendmail-bugs@sendmail.org.
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
MAIL FROM: usuario@eafit.edu.ar (define el origen del correo)
250 2.1.0 emontoya@eafit.edu.ar... Sender ok
RCPT TO: userst@dominio.subdominio (especifica el

destino)
250 2.1.5 usert@dominio.subdominio Recipient ok
DATA
354 Start mail input; end with <CRLF>.<CRLF>
115
(escriba el mensaje, para finalizar digite un punto)

bla, bla, bla, ...
.
250 2.0.0 g3OFd0s14381 Message accepted for

delivery
A continuación se aclaran los comandos SMTP básicos:
DATA: este comando indica al servidor que el texto que va a continuación del comando es ya el
mensaje de correo que debe de llevarse al destinatario indicado por el encabezado del mensaje. El
texto del mensaje debe de estar de acuerdo con el estándar del formato de mensaje de Internet,
descrito en la RFC 2822. Este texto del mensaje debe finalizar con un punto, que tiene que ir
precedido (del comando anterior) y sucedido de los caracteres de retorno carro/avance de línea.
Dentro del texto se reconocen las palabras claves como: from:, to:, subject:, etc. El funcionamiento
es sencillo, se envía el comando y el servidor debería responder con el código de respuesta 354. El
paso siguiente es enviar el texto del mensaje, al término del cual se debería de recibir el código de
respuesta 250.
La tabla siguiente indica los posibles códigos de respuesta que puede recibir este comando:
Código Significado
250 La acción solicitada se ha completado
Comenzar la introducción del correo, acabando con
354
<CRLF>.<CRLF>
421 El servicio no esta disponible
451 Se abandono la acción por un error de procesamiento local
No se produjo la acción por que el disco no tiene espacio de
452
almacenamiento suficiente
500 Error en la sintaxis, no se pudo reconocer el comando
501 Error en la sintaxis de los parámetros del comando
503 Secuencia de comandos incorrecta
552 Abandono de la acción porque se supero la reserva de espacio
554 Se produjo un fallo en la transacción
HELO: este comando es el encargado de iniciar el dialogo SMTP. Este comando tiene como
parámetro un nombre de dominio. El servidor responderá con un código de respuesta 250 seguido
del nombre del servidor.
Los posibles códigos de respuesta a este comando están en la siguiente tabla:

116
Código Significado
504 El parámetro del comando no esta implementado
HELP: este comando hace que el servidor envíe información de ayuda sobre todos los comando o
sobre un comando en concreto.
Código Significado
211 El sistema tiene disponible la ayuda
214 Mensaje de información de ayuda
502 El comando no esta implementado
504 El parámetro del comando no esta implementado
MAIL: este comando indica al servidor el inicio de un mensaje de correo y le indica además quien
es el remitente del mensaje.
Código Significado
452
QUIT: este comando le indica al servidor que el cliente no tiene mas operaciones que realizar y
que se debería cerrar la conexión. El servidor responde OK y seguidamente, cierra la conexión con
el cliente.
Código Significado
221 Se está cerrando la conexión
117
RCPT (destinatario): este comando indica al servidor quien es el destinatario del mensaje que se
está enviando. Si el mensaje debe de ir a varios destinatarios, se pueden expresar separados por
comas.
Código Significado
El usuario no es local, entonces se remite el mensaje a nombre-
251
servidor
450 No ser realizo la acción porque el buzón no esta disponible
452
503 Secuencia de comandos incorrecta
550 La acción no se realizo por que no se ha encontrado el buzón
El usuario no es local, el cliente debería conectarse a nombre-
551
servidor
No se realizo la operación porque la sintaxis del nombre del buzón
553
es incorrecta
118
Configuración de un servidor SMTP
Veremos a continuación los pasos que debe realizar el administrador del servicio SMTP para
configurar un servidor de una intranet o Internet.
redes e Internet.
• Dirección IP
• Nombre de Host
Configuración del servicio SMTP
Limitar el número de conexiones

Demasiadas conexiones simultáneas con el servidor pueden sobrecargar la red y producir un bajo
rendimiento. Especifique el número máximo de conexiones simultáneas al servidor.
Tiempo de espera de la conexión

Utilice esta especificación para configurar el número de minutos que deben transcurrir antes de
que se desconecte a un cliente inactivo.
Nota Si establece un tiempo de espera demasiado bajo, puede que se desconecte

inesperadamente a los usuarios del servidor y, quizás, reciban un mensaje de error. Diez
minutos es el tiempo de espera mínimo recomendado.
Habilitar registro
Active esta opción para crear archivos de registro de transacciones. Los archivos de registro se
utilizan para recopilar datos estadísticos acerca del uso de los servidores y constituyen una
herramienta muy útil para los administradores. Por ejemplo, los archivos de registro pueden
mostrar cuándo se conectan los usuarios, y desde dónde se conectan.
Control de acceso
Para elegir la forma en que el servidor autentica a los usuarios cuando éstos inician una sesión.
Puede permitir el acceso anónimo o solicitar credenciales como el nombre de usuario, la
contraseña y el certificado de seguridad X509.
Restricciones de retransmisión (Relay)

Para restringir a los clientes la retransmisión (ruteo) de mensajes de correo electrónico a través del
servidor, según sus direcciones IP o credenciales de autenticación. Esta restricción es muy
importante para evitar que terceros no autorizados usen el servidor para hacer circular Spam por
Internet. El problema reside en que dicha función de retransmisión deteriora el desempeño del
119
servidor cuando debe atender a una gran cantidad de correo, que en realidad no interesa al
propietario del servidor.
Limitar el tamaño del mensaje a (KB)

Utilice esta opción para impedir que los usuarios envíen mensajes de correo electrónico demasiado
grandes. Si un usuario intenta enviar un mensaje de correo electrónico mayor que el tamaño
máximo de mensaje especificado, se devolverá al remitente como mensaje no entregado con una
leyenda que indique tal problema.
Correo Saliente
Utilice esta configuración para controlar los intervalos en los que el servidor virtual intentará
entregar mensajes de correo electrónico que no se han podido entregar. También puede especificar
cuándo notificar a los usuarios que los mensajes están retrasados y cuándo dejar de intentar la
entrega de mensajes.
Tiempo de espera de caducidad

Para especificar un periodo de tiempo antes del cual no se intentará la entrega de un mensaje de
no entrega (NDR) al remitente, debido a la imposibilidad de colocar el correo en el destinatario.
Aunque el tiempo óptimo puede variar según la confiabilidad de la red, el valor predeterminado es
2 días.
Seguridad saliente
Configurar las opciones de seguridad para conexiones con otros servidores del Protocolo simple de
transferencia de correo (SMTP). Puede conectarse con otros servidores SMTP de forma anónima o
bien utilizar autenticación y cifrado.
Número máximo de saltos

Limitar el número máximo de saltos que los mensajes pueden realizar hasta llegar al servidor de
destino. Los mensajes pueden viajar a través de varios servidores de Protocolo simple de
transferencia de correo (SMTP) antes de llegar al servidor virtual. Cada vez que esto ocurre, el
servidor SMTP intermedio agrega al encabezado del mensaje una línea de texto, que hace
referencia al salto. El máximo número predeterminado de saltos es 15, aunque el número óptimo
depende de la topología de la red.
Nombre de dominios que son locales para este servidor

Se deben definir los nombres DNS para los cuales se consideran que son para este servidor local.
En otras palabras se debe definir los nombres o alias del correo local. Por ejemplo si un nombre
de alias es zz.com, entonces todos los mensajes con direcciones del tipo xx@zz.com son tomados
como locales para este servidor. O sea que si este servidor que tiene un alias zz.com debe colocar
el mensaje xx@zz.com en un mailbox local.
Host inteligente (“smart host”)

Escribir el FQDN de un host inteligente (servidor SMTP, encargado de distribuir el correo) para su
uso con el servidor SMTP. Si especifica el FQDN de un host inteligente, todos los mensajes de
correo electrónico salientes se retransmitirán a través del host inteligente. El caso típico es el de un
servidor SMTP de una intranet que no tiene conexión con Internet. Debe usar un “smart host”
conectado a Internet para que sea este el que resuelva los nombres DNS y reenvíe el correo a los
destinatarios.
120
Servidores SMTP de reenvío para mensajes de dominios remotos

Definir los nombres o direcciones IP de servidores de reenvío SMTP a los que se reenviarán
correos dirigidos a determinados dominios DNS. Por ejemplo definir que los mensajes al dominio
pepe.com se reenviarán al host xx.yy.net.
Ruteo
Vemos que como ruteador de correo el servidor SMTP tiene tres opciones para reenviar los
mensajes entrantes, con una dirección del tipo xx@dominio.com, según el siguiente orden de
prioridad:
1. Al host inteligente
2. Al servidor SMTP que se obtiene de la tabla de servidores de reenvío de dominios
remotos
3. Al servidor SMTP que se obtiene de la consulta DNS por el tipo MX que
corresponde al dominio remoto dominio.com.
4. A un mailbox local
Tenga en cuenta que 1 y 2 son opcionales.
Realizar búsqueda DNS inversa en los mensajes entrantes

Defina si el servidor debe resolver automáticamente a un nombre de host la dirección IP de origen
de los mensajes de correo electrónico entrantes. El nombre de host se adjuntará a los encabezados
de los mensajes de correo electrónico. Esta opción se realiza por una cuestión de seguridad.
[46]
Explique en forma resumida las funciones básicas de un servicio de correo.
[47]
Realice un dibujo que muestre las relaciones entre los módulos o funciones básicas de un servicio
de correo.
[48]
Indique cuales son las partes básicas de un mensaje de correo electrónico.
[49]
Escriba la secuencia básica de comandos SMTP que permiten enviar un correo electrónico.
[50]
Indique 8 definiciones de configuración de un servidor de correo SMTP.
121
6.6 Protocolo IMAP

El Protocolo de Acceso a Mensajes de Internet, versión 4rev1 (IMAP4rev1) permite a un cliente
acceder y manipular los mensajes de correo electrónico contenidos en un servidor que actúa como
Agente de Distribución de Mensajes (MDA).
IMAP4rev1 nos permite manipular los archivos contenedores de mensajes, llamadas comúnmente
"buzones", con una funcionalidad equivalente a la que obtenemos con los contenedores de
mensajes locales.
IMAP4rev1 también ofrece la posibilidad de que un cliente "offline", establezca una

sincronización con el servidor.
IMAP4rev1 ofrece además, operaciones para crear, borrar, y renombrar estos buzones;
comprobación de nuevos mensajes; lectura del contenido; borrado permanente de mensajes;
establecimiento y borrado de banderas; búsqueda genérica; y recuperación selectiva de atributos de
mensaje, textos, y porciones de texto.
IMAP4rev1 no especifica un medio de distribución de correo; esta función es desempeñada por el

protocolo de transferencia de correo como SMTP.
IMAP4rev1 se ha diseñado para mantener la compatibilidad con los protocolos anteriores

partiendo desde [IMAP2] y los protocolos IMAP2bis no publicados. A lo largo del tiempo de vida
de IMAP4rev1, algunos aspectos del protocolo inicial han quedado obsoletos.
El protocolo IMAP4rev1 confía en la existencia de un flujo de datos estable, como los

suministrados por TCP. Cuando utilizamos TCP, un servidor IMAP4rev1 escucha en el puerto
143.
Una conexión IMAP4rev1 consiste en el establecimiento de una conexión de red cliente/servidor,

un reconocimiento inicial por parte del servidor, y una serie de comunicaciones cliente/servidor.
Estas comunicaciones consisten en un comando de cliente, datos del servidor, y una respuesta por
parte del servidor de transferencia completada.
La comunicación entre cliente y servidor se realiza en forma de líneas; es decir, cadenas que
terminan con un CRLF.
Comunicación entre cliente y servidor
El comando de cliente da comienzo a una operación. A cada comando de cliente se le asigna un

prefijo consistente en un identificador (normalmente una cadena corta de caracteres
alfanuméricos, p.ej. A0001, A0002, etc.) llamado "etiqueta". El cliente asigna a cada comando una
etiqueta diferente.
Un argumento del comando está formado de un número de octetos, los argumentos del comando
requieren una realimentación por parte del servidor. El servidor envía una respuesta de solicitud de
continuación del comando si este está preparado para recibir los octetos (si es lo adecuado) y el
recordatorio del comando. Esta respuesta viene precedida del token"+".
122
En caso de que el servidor detecta un error en el comando, envía una respuesta de transacción
errónea con la etiqueta que corresponde al comando para rechazar el comando, y con ello evita que
el cliente envíe más información del comando.
Es posible que el servidor envíe una respuesta de transacción completa para otros comandos (si
hay varios comandos en progreso), o datos no etiquetados. Esto indica que la comunicación no
tiene que ser obligatoriamente sincrónica. En cualquier caso, la solicitud de continuación de
comando está todavía pendiente; el cliente actúa de manera adecuada a la respuesta, y lee otra
respuesta del servidor. En todos los casos, el cliente DEBE enviar un comando completo antes de
inicializar un nuevo comando.
Atributos del Mensaje de Correo
Además del texto del mensaje, cada uno de los mensajes posee una serie de atributos. Estos
atributos se pueden recuperar individualmente o en conjunción con otros atributos o textos del
mensaje. Veremos algunos de los atributos más representativos.
Números del Mensaje: Para tener acceso a los mensajes en IMAP4rev1 se utilizan uno de los
siguientes números; el identificador único o el número de secuencia del mensaje.
Identificador Único (UID): Asignamos a cada mensaje un valor de 32 bit, que junto con el valor
de vigencia de identificador único obtenemos un valor de 64 bit, con lo cual garantizamos que
hacemos referencia al mensaje en concreto y no a cualquier otro presente en el buzón. Los
identificadores únicos se asignan en el buzón en orden ascendente; de forma que cualquier mensaje
que llegue al buzón recibirá un UID mayor que el identificador asignado al mensaje recibido justo
antes que él.
Al contrario que los números de secuencia de mensaje, los identificadores únicos no son
necesariamente contiguos. Los identificadores únicos también permanecen a lo largo de sesiones
diferentes. Esto permite al cliente re-sincronizar su estado partiendo desde una sesión previa con el
servidor. (p.ej. clientes "offline" o desconectados).
Número de secuencia de mensaje: Posición relativa desde 1 al número de mensajes en el buzón.

Esta posición DEBE estar ordenada ascendentemente por identificador único. Conforme se añadan
nuevos mensajes, se le asignará a cada uno un número de secuencia de mensaje que sea una unidad
mayor que el número total de mensajes presentes previamente en el buzón.
Fecha y hora interna del mensaje en el servidor: Esta no es la fecha y hora de la cabecera, sino
que es una fecha y una hora que refleja el momento de recepción del mensaje.
Tamaño de mensaje: Número de octetos del mensaje
Partes del mensaje
Además de ser capaz de recuperar todo el texto de un mensaje, IMAP4rev1 permite la

recuperación de fragmentos del texto completo del mensaje. En concreto, es posible recuperar la
cabecera del mensaje, el cuerpo del mensaje o una sección del cuerpo.
123
Estados de una conexión IMAP
Una conexión IMAP4rev1 puede encontrarse en cuatro estados. La mayoría de los comandos son
válidos únicamente en ciertos estados. Es un error de protocolo de parte del cliente intentar
ejecutar un comando mientras este no se encuentra en el estado apropiado.
Estado no autentificado: En este estado, el cliente debe suministrar credenciales de

autentificación antes de que la mayoría de los comandos puedan ser aceptados. Este estado se
alcanza cuando comienza la conexión.
Estado autentificado: En este estado, el cliente está autentificado y debe seleccionar un buzón
antes de que se le permita utilizar cualquier comando que afecte a los mensajes contenidos en el
mismo.
Estado seleccionado: En este estado, se ha seleccionado un buzón al que acceder. Este estado se
alcanza cuando la selección del buzón es aceptada.
Estado desconexión: En este estado, la conexión está en proceso de finalización, y el servidor

cerrará la conexión. Este estado puede alcanzarse como resultado de la petición del cliente o por
decisión unilateral del servidor.
Comandos de cliente
En esta sección se detallan los comandos IMAP4rev1. Los comandos se organizan en función del
estado en el cual está permitida su ejecución. Existen comandos que puedan utilizarse en varios
estados.
Veremos algunos ejemplos de comandos que le permiten al cliente realizar tareas en el servidor.
En los ejemplos se indicará con “C” el envío del cliente, y con “S” la respuesta del servidor.
Comando CAPABILITY: El comando CAPABILITY solicita un listado de todas las aptitudes de

que dispone el servidor.
Ejemplo:
C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4
S: abcd OK CAPABILITY completado
Comando AUTHENTICATE: En el estado no autentificado, el comando AUTHENTICATE o

LOGIN establece la autentificación y nos introduce en un estado autentificado. El comando
AUTHENTICATE ofrece un mecanismo global para una gran variedad de técnicas de
autentificación, mientras que el comando LOGIN hace uso del par nombre de usuario tradicional y
contraseña de texto plano.
El comando AUTHENTICATE indica un mecanismo de autentificación al servidor. Si el servidor

soporta dicho mecanismo de autentificación, lleva a cabo una transacción de protocolo de
autentificación e identifica al cliente. Es posible manejar un mecanismo de protección opcional
para sucesivas interacciones del protocolo. Si no está soportado dicho mecanismo de
autentificación, el servidor debería rechazar el comando AUTHENTICATE enviando una
respuesta NO, no etiquetada.
124
Ejemplo:
S: * OK KerberosV4 IMAP4rev1 Servidor
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C:BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT+n
ZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFdwuQ1MWiy
6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 autentificación conseguida.
Comando LOGIN: El comando LOGIN identifica el cliente al servidor y se hace cargo de la

clave en texto plano autentificando al usuario.
Ejemplo:
C: a001 LOGIN JUAN CONTRASEÑA

S: a001 OK LOGIN completado
Comando SELECT: El comando SELECT selecciona un buzón de correo para que en un futuro
se pueda tener acceso a los mensajes que este contiene.
Ejemplo:
C: A142 SELECT INBOX

S: * 172 EXISTS (existen 172 mensajes en la bandeja de entrada)
S: * 1 RECENTS: * OK [UNSEEN 12] (El mensaje 12 es el primer mensaje no
visto)
S: * OK [UIDVALIDITY 3857529045] UIDs válido
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limitado
S: A142 OK [READ-WRITE] SELECT completado
Comando EXAMINE: El comando EXAMINE es idéntico al comando SELECT y devuelve la

misma salida; sin embargo, el buzón de correo seleccionado se establece como de solo lectura. No
se permiten modificaciones en el estado permanente del buzón de correo, incluyendo el estado por-
usuario.
Veremos a modo de ejemplo en forma simplificada otros comandos no menos importantes.
Comando CREATE: El comando CREATE crea un buzón de correo con el nombre especificado.
Comando DELETE: El comando DELETE borra el buzón de correo que posea el nombre
especificado.
Comando CLOSE: El comando CLOSE elimina de manera permanente todos los mensajes del
buzón que tengan la bandera \Deleted activa.
125
Comando FETCH: El comando FETCH recupera datos asociados a un mensaje contenido en el

buzón. Por ejemplo cabeceras (headers) del mensaje, cuerpo del mensaje (body), etc.
126
Configuración del servidor IMAP4

El servidor MDA que usa IMAP debería instalarse conjuntamente con un servidor SMTP para que
pueda recibir los mensajes en el puerto 25. IMAP debería instalarse en el puerto 143 para recibir
las peticiones de los clientes que solicitan acceso al almacén de buzones para las tareas descriptas
anteriormente.
Configuración del servicio IMAP
Los servidores del servicio MDA están preconfigurados de tal manera de prestar el servicio de
acuerdo al protocolo IMAP. Normalmente solo hace falta crear los buzones de los usuarios y
protegerlos de acuerdo a las restricciones de acceso del servidor que controla el acceso a la
información que se mantiene en los buzones.
[51]
Defina las funciones básicas del protocolo IMAP4.
[52]
Indique que tipo de operaciones se pueden realizar mediante el protocolo IMAP4.
[53]
Resuma las características básicas de una conexión cliente/servidor mediante el protocolo IMAP4.
[54]
Indique que partes del mensaje se pueden discriminar en una lectura del contenido del mismo.
[55]
Indique que son los atributos de un mensaje.
[56]
Indique que relación existe entre los estados de una conexión y los comandos del protocolo
IMAP4.
[57]
Resuma la función de cuatro comandos de cliente IMAP4.
127
6.7 Protocolo POP3
Un protocolo sencillo y muy usado para bajar correo electrónico de un buzón remoto, es el
protocolo de oficina postal (post office protocol, POP3). El objetivo del POP3 es obtener correo
electrónico del buzón remoto y almacenarlo en la maquina local del usuario para su lectura
posterior. Se emplea principalmente en conexiones con MODEM en las que el tiempo de conexión
cuesta dinero. De las posibilidades que el protocolo POP3 permite, los clientes de correo POP3
suelen ofrecer las siguientes facilidades operativas
• Bajar todos los mensajes y borrarlos del servidor

• Bajar solo los mensajes no leídos y no borrar ninguno del servidor
El inconveniente principal es que, si se ha recibido un mensaje largo, habrá que esperar a que el
agente lo traiga desde el buzón para poder ver de qué se trata. Este es un problema de como los
agentes usan el POP, no del protocolo en si mismo.
Es un protocolo mucho más simple que IMAP.
Principio de funcionamiento
Inicialmente, el equipo servidor inicia el servicio POP3 escuchando el puerto TCP 110. Cuando un
equipo cliente quiere hacer uso del servicio, establece una conexión TCP con el equipo servidor.
Cuando la conexión se ha establecido, el servidor POP3 envía un saludo. El cliente y el servidor
POP3 a partir de entonces intercambian órdenes y respuestas (respectivamente) hasta que se cierre
o interrumpa la conexión.
Las órdenes en el protocolo POP3 consisten en una serie de palabras claves sin diferenciar
mayúsculas de minúsculas, posiblemente seguidas de uno o más argumentos. Todas las órdenes
terminan con un par CRLF (Carriage Return Line Feed, Retorno de Carro Nueva Línea). Las
órdenes y sus argumentos están compuestos de caracteres ASCII imprimibles, separados de sus
argumentos por un sólo carácter espacio. Las órdenes tienen tres o cuatro caracteres de longitud.
Cada argumento puede tener hasta 40 caracteres.
Las respuestas en el POP3 están formadas por un indicador de estado y una palabra clave,
posiblemente seguida de información adicional. Todas las respuestas están terminadas por un par
CRLF. Las respuestas pueden tener hasta 512 caracteres de longitud, incluyendo el CRLF del final.
Una sesión POP3 pasa por varios estados durante su periodo de vida. Una vez abierta la conexión
TCP y tras enviar el servidor POP3 el saludo, la sesión entra en la fase de AUTORIZACIÓN. En
esta fase, el cliente debe identificarse ante el servidor POP3.
Una vez que el cliente lo realiza con éxito, el servidor adquiere los recursos asociados con el buzón
del cliente, y la sesión entra en la fase de TRANSACCIÓN. En esta fase, el cliente solicita la
actuación al servidor POP3.
Tras el envío por el cliente de la orden QUIT, la sesión entra en la fase de ACTUALIZACIÓN. En
esta fase, el servidor POP3 libera cualquier recurso adquirido durante la fase de TRANSACCIÓN,
y dice adiós. En ese momento se cierra la conexión TCP.
128
Un servidor POP3 puede tener un contador de inactividad para cerrar la conexión. Ese contador
debe de ser de al menos 10 minutos de duración. La recepción de cualquier orden durante el
intervalo debería bastar para reiniciar el contador. Cuando el contador se agota, la sesión NO entra
en fase de ACTUALIZACIÓN: el servidor debería cerrar la conexión TCP sin eliminar ningún
mensaje ni enviar ninguna respuesta al cliente.
Sesión de ejemplo POP3
S: <espera de conexión POP3 por el puerto 110>

C: <abrir conexión en el puerto 110>
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb (autenticar con contraseña
encriptada)
S: +OK mrose's mailbox has 2 messages (320 octets)
C: STAT (pide el resúmen del mailbox)
S: +OK 2 320
C: LIST (pide el listado de los mensajes)
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1 (solicita el mensaje 1)
S: +OK 120 octets
S: <el servidor POP3 envía el mensaje 1>
S: .
C: DELE 1 (marca al mensaje 1 como eliminado)
S: +OK message 1 deleted
C: RETR 2 (solicita al mesaje 2)
S: +OK 200 octets
S: <el servidor POP3 envía el mensaje 2>
S: .
C: DELE 2 (marca al mensaje 2 como eliminado)
S: +OK message 2 deleted
C: QUIT (cierra la sesión)
S: +OK dewey POP3 server signing off (mailbox empty)
C: <cierre de la conexión>
S: <espera de la siguiente conexión>
Comandos POP3
A continuación veremos en forma resumida, alguno de los comandos más importantes.
PASS (Clave): señala al servidor la clave de la cuenta de usuario indicada por el comando USER.
Si la clave no es correcta o la casilla no pasa al estado de bloqueo exclusivo, se produce un error.
La sintaxis de este comando es la siguiente:
PASS clave
129
QUIT: se puede usar cuando el servidor está en estado de autorización y en estado de transacción.
Si se usa cuando está en estado de autorización, la sesión finaliza y se interrumpe la conexión. Si
se usa cuando está en estado de transacción, se cierra la sesión y el servidor pasa a estado de
actualización. La sintaxis de este comando es la siguiente:
QUIT
USER: le proporciona al servidor el identificador o nombre de la cuenta de usuario. Si ese

identificador existe, devuelve un código de operación correcta, de lo contrario, devuelve un código
de fallo.
USER nombre
DELE (Eliminar): marca como eliminado un mensaje, pero en realidad el servidor no lo elimina
hasta que no pasa al estado de actualización, con lo que no se pierde en el caso de que la conexión
fallase o que se deseara quitarle la marca de eliminar. Cada mensaje que está en la casilla del
servidor POP tiene asignado un número, que lo identifica. La sintaxis es la siguiente para este
comando:
DELE numero_mensaje
LIST: recupera información acerca del tamaño que ocupa un mensaje determinado o todos los
mensajes. En el caso de que se aplique sobre un solo mensaje, el servidor responde con una línea
indicando el número del mensaje y el tamaño. Si se refiere a más de un mensaje, el servidor
responde enviando una línea por cada mensaje que incluye el número y tamaño correspondiente. El
final de estas líneas es un punto y seguido por los caracteres #13#10. La sintaxis de este comando
es:
LIST numero_mensaje
NOOP (No operación): es un comando de no operación. Cuando se envía, el servidor responde

con un OK. Se utiliza para mantener activa la sesión. La sintaxis del comando es la siguiente:
NOOP
RETR (Recuperar): permite recuperar o solicitar que el servidor envíe un mensaje determinado.
El mensaje se solicita enviando el número del mensaje a continuación del comando. Este número
de mensaje no puede corresponder a un mensaje con marca de borrado. El servidor responde a la
petición enviando el texto del mensaje, que finaliza cuando le llega al cliente un punto seguido de
los caracteres de retorno de carro/avance de línea (#13#10). La sintaxis del comando es:
RETR numero_mensaje
RSET (Reiniciar): anula la marca de borrado de todos los mensajes en la casilla. No se puede
eliminar la marca de borrado de un mensaje en concreto, tiene que ser de todos. La sintaxis es la
siguiente:
RSET
130
STAT (Estado): permite obtener un resumen del contenido de la casilla. El servidor responde a
este comando enviando el número de mensajes que hay en la casilla, sin contar aquellos que están
marcados como borrados, y el volumen o tamaño en bytes de la casilla. Estos dos datos los
devuelve separados por espacios. La sintaxis de este comando es:
STAT
APOP (entrar en el sistema con contraseña encriptada): es una alternativa a los comandos
USER y PASS. El comando APOP necesita de dos parámetros, uno es un identificador de cuenta y
el otro es la clave encriptada. Al conectarse al servidor POP, éste envía una marca de tiempo. Junto
con esta marca de tiempo, se aplica un algoritmo para encriptar la contraseña. Este algoritmo se
encuentra definido en el RFC 1321. Este método de autentificación POP es útil para aquellos
usuarios que se conectan frecuentemente a sus servidores de correo, evitando de esta manera, que
la clave de la cuenta viaje frecuentemente por la red sin encriptar. La sintaxis de este comando es
la siguiente:
APOP nombre clave_encriptada
TOP: permite al cliente de correo leer la parte del encabezado del mensaje y un numero de líneas
del cuerpo o núcleo del mensaje. Este comando se suele utilizar cuando se desea conocer los
mensajes sin leerlos. La sintaxis de este comando es:
TOP numero_mensaje numero_lineas_del_cuerpo
Formato de los Mensajes
Es el mismo que maneja el protocolo IMAP.
Configuración del servicio POP3
Las consideraciones son las mismas que para el servicio IMAP
[58]
Resuma el objetivo básico del protocolo POP3.
[59]
Explique brevemente la secuencia de estados en una sesión básica del protocolo POP3.
[60]
Enliste la secuencia de comandos para acceder al buzón, leer un resumen de los mensajes del
buzón, leer el primer mensaje, marcar como leído dicho mensaje y salir de sesión con el protocolo
POP3.
131
6.8 Especificaciones MIME
SMTP tradicional es adecuado para la transmisión de mensajes de texto en inglés, pero es

inadecuado para texto en otro idioma o para datos no textuales. A continuación se mencionan dos
métodos para superar estas limitaciones.
El primero es Extensión de correo de Internet multipropósito (MIME), definido en RFC 1521 y

RFC 1522. Este protocolo, especifica un mecanismo para codificar texto y datos binarios dentro de
los límites del desarrollo de correo electrónico. Pero también es adoptado por otros servicios que
trabajan con contenido multimedial como el protocolo HTTP.
MIME soluciona los siguientes problemas del correo electrónico:
• Mensajes en idiomas con acentos (por ejemplo español, francés y alemán).

• Mensajes en idiomas sin alfabetos (por ejemplo, chino y japonés).
• Mensajes que no contienen texto (por ejemplo, imágenes, audio y video).
• Mensajes combinados de los anteriores (por ejemplo texto, una foto y una canción).
El segundo es Extensión de servicios SMTP (o ESMTP), el cual define un mecanismo para

extender la capacidad de SMTP más allá de los límites impuestos por RFC 821. Existen tres RFC
que describen Extensión de servicios SMTP. El primero de ellos es RFC 1651, el cual es un
estándar para que el Receptor SMTP informe al Emisor SMTP que servicios extendidos soporta.
RFC 1651 modifica RFC 821 para permitir a un cliente SMTP pedir que el servidor responda con
una lista de servicios extendidos que soporta en el comienzo de una sesión SMTP. Si el servidor
SMTP no soporta RFC 1651, envía una respuesta en conformidad con las reglas de RFC 821. Si el
servidor soporta RFC 1651, éste responde con una lista de servicios extendidos que soporta. Los
otros dos RFC definen extensiones específicas.
MIME y Extensión de servicios SMTP son cercanos y complementarios más que estándares
excluyentes [18]. Desde el estándar MIME, se permiten mensajes para ser declarados como
consistentes de datos de 8-bit más que de datos de 7-bit, debido a que los mensajes no pueden ser
transmitidos por agentes SMTP que estrictamente se ajusten a RFC 821(especifica ASCII de 7-
bit).
Cuando un cliente SMTP intenta enviar datos de 8 bits a un servidor que no soporta esa extensión,
el cliente SMTP debe codificar el contenido del mensaje a una representación de 7 bits o retornara
un error permanente del servidor.
RFC 822 define un protocolo de representación de mensaje que considera detalles específicos
sobre la cabecera y cuerpo del mensaje, como texto en EE.UU.-ASCII. El conjunto de
documentos, comúnmente llamado Extensión de correo de Internet multipropósito o MIME,
redefine el formato de mensajes para permitir cuerpos de mensajes textuales y no textuales con un
conjunto de caracteres diferentes a EE.UU.-ASCII de 7 bits.
El protocolo MIME surge por la incapacidad que tiene el RFC 822 para representar todos los datos
que se desean transmitir a través de correo electrónico. Desde un principio RFC 822 define el
formato normal de mensajes textuales en Internet (define sintaxis de cuerpo y cabecera). Su éxito
ha sido tal que se utiliza más allá de los límites de Internet y más que el transporte por Internet
132
SMTP, definido por RFC 821. Cuando el formato se ha usado en forma más extensa, se ha
observado un aumento de las limitaciones para la comunidad de usuarios.
RFC 822 especifica un formato para los mensajes de texto, y como tal, no considera mensajes
multimediales que incluyan audio o imágenes. Incluso, en el caso de texto, RFC 822 es inadecuado
para las necesidades de usuarios, cuyos idiomas requieren el uso de un conjunto de caracteres más
rico que EE.UU.-ASCII de 7 bits. Puesto que RFC 822 no especifica mecanismos para correo que
contiene audio, texto de idiomas asiático, vídeo, o el texto de la mayoría de los idiomas europeos,
se necesitan las características técnicas adicionales que proporciona MIME.
Una de las limitaciones notables del sistema de correo basado en RFC 821/822 es que limita la
longitud del mensaje de correo electrónicos a líneas relativamente cortas (Ej. 1000 caracteres o
menos). Esto obliga a los usuarios a convertir cualquier dato no textual a la representación de
caracteres de bytes de 7-bits EE.UU.-ASCII antes de invocar un UA (Agente del Usuario, un
programa con el que los usuarios humanos envían y reciben correo).
Las limitaciones de RFC 822 quedan aún más claras en el momento que se diseñan "Gateways"
para permitir el intercambio de mensajes del correo entre máquinas clientes RFC 822 y máquinas
clientes X.400. X.400 especifica mecanismos para la inclusión de información no textual en los
mensajes del correo electrónicos.
Las normas actuales para la conversión de mensajes X.400 a mensajes RFC 822 especifican que
cualquier contenido no textual X.400 debe ser convertido a un formato especial (IA5Text), de lo
contrario debe ser desechado y debe notificarse al usuario RFC 822 que el desecho ha ocurrido.
Campos de cabecera de un mensaje
La especificación MIME define 5 nuevos campos en la cabecera del mensaje, que se muestran a
continuación junto con la explicación de su valor. Estos campos permiten definir un formato que
posibilita la mezcla de contenidos. Especialmente se define un delimitador para separar
contenidos.
MIME-Version: Indica al agente de usuario receptor del mensaje que esta tratando con un
mensaje MIME. El valor identifica la versión del MIME (actualmente la 1.0). Se considera que
cualquier mensaje que no contenga una cabecera MIME-Versión: es un mensaje de texto que
únicamente contiene código ASCII de 7 bits y se procesa como tal.
Content-Description: El valor contiene una cadena ASCII que especifica el contenido del
mensaje MIME en pocas palabras. Esta cadena es útil para que el destinatario sepa si vale la pena
descodificar y leer el mensaje o no.
Content-Id: Valor que contiene un identificador unívoco del mensaje. Usa el mismo formato que
la cabecera estándar Message-Id.
Content-Transfer-Encoding: Valor que le indica al agente de usuario receptor la manera en que

está codificado el cuerpo del mensaje para su correcta interpretación. Se proporcionan cuatro
esquemas estándar, aunque es posible especificar una codificación definida por el usuario.
133
7bit: Es la codificación más sencilla. Los caracteres ASCII usan 7 bits y pueden
transportarse directamente mediante el protocolo de correo electrónico, siempre y cuando
ninguna línea exceda 1000 caracteres.
8bit: Igual que la codificación anterior pero los caracteres ASCII usan 8 bits. Esta
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. Los
mensajes que usan esta codificación aún deben adherirse a la longitud máxima de linea
estándar.
base64: Los archivos binarios arbitrarios usan 8 bits, pero no respetan el límite de 1000
caracteres por línea. No se da ninguna garantía de que los mensajes en binario llegaran
correctamente, pero mucha gente los envía de todos modos. La manera correcta de
codificar mensajes binarios es usar codificación base64. En este esquema, se dividen
grupos de 24 bits en unidades de 6 bits, enviándose cada unidad como carácter ASCII de 7
bits.
quoted-printable: En el caso de mensajes que son casi completamente ASCII de 7 bits,

pero con algunos caracteres del ASCII extendido, la codificación base 64 es ineficiente. En
cambio, se usa una codificación conocida como codificación entrecomillada imprimible.
Simplemente es ASCII de 7 bits, con todos los caracteres por encima del 127 codificados
como un signo "=" igual seguido del valor del carácter en dos dígitos hexadecimales.
Content-Type: Valor especifica la naturaleza del cuerpo del mensaje. Hay muchísimos valores
distintos, pero todos siguen el formato tipo/subtipo. Observe que el tipo y el subtipo se separan
mediante una diagonal. Ambos, tanto el tipo como el subtipo, deben indicarse explícitamente, pues
no se proporcionan valores predeterminados. Una lista reducida de tipos y subtipos comunes se da
a continuación:
text/plain, text/html: El tipo texto 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. La combinación text/html es para mostrar
paginas web escritas en html.
image/gif, image/jpeg: El tipo image 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 los subtipos oficiales son GIF y JPEG, pero sin duda hay muchos más.
video/mpeg, audio/Basic: El tipo video es para imágenes en movimiento. El único formato

de video definido hasta ahora es el diseñado por el grupo de expertos de imágenes en
movimiento (moving picture experts group, MPEG). Note que el tipo video solo incluye la
información visual, pero no la pista de sonido. Si debe transmitir una película con sonido,
tal vez sea necesario transmitir las partes de video y de audio por separado. El tipo audio es
para sonido.
multipart/alternative, multipart/mixed, multipart/related: El tipo multipart permite que

el mensaje tenga varias partes independientes, con el comienzo y el final de cada parte
claramente delimitados. La combinación multipart/alternative indica que cada parte
134
contiene el mismo mensaje pero codificado en diferentes formatos. El agente de usuario

elegirá la que prefiera. La combinación multipart/mixed indica que las diferentes partes son
diferentes, sin ninguna estructura adicional impuesta. La combinación multipart/related
indica que las partes son diferentes pero relacionadas, por lo que hay que hacer una
interpretación conjunta de las mismas
En MIME aparece la idea de mandar un mensaje compuesto por múltiples partes, y cada una de
ellas a su vez de múltiples partes. Aparece por tanto una estructura recursiva que permite la
generación de combinaciones complejas de varias partes. Veamos el siguiente ejemplo:
From: mabel@hotmail.com
To: florencia@yahoo.com
Subject: Queria decirte ...
MIME-Version: 1.0
Message-Id: <0704760941.AA00747@abc.com>
boundary=qwertyuiopasdfghjklzxcvbnm
--qwertyuiopasdfghjklzxcvbnm
Content-Type: text/plain
Feliz cumpleaños para ti,

Feliz cumpleaños para ti, querida Florencia
Feliz cumpleaños para ti.
Content-Type: audio/basic;
directory="tmp";
name="aniversario.snd"
Content-Transfer-Encoding: base64
MIIC1DCCAn6gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBgDELMAkGA1UEBhM
CRVMx
DzANBgNVBAgUBkVzcGHxYTESMBAGA1UEBxMJQ2FzdGVsbG9uMQ0wCwYDV
QQKEwMX
aXN1MR0wGwYDVQQDExRNYW5vbG8gTW9sbGFyIEdhcmNpYTEeMBwGCSqGSIb
3DQEJ
ARYPbW9sbGFyQG5pc3Uub3JnMB4XDTAwMTEyMzA4MTIxOVoXDTAwMTIyMzA
4MTIx
OVowgYAxCzAJBgNVBAYTAkVTM
--qwertyuiopasdfghjklzxcvbnm--
En el mensaje anterior se transmite una felicitación de cumpleaños como texto y como canción.
Observe como la cabecera Content-Type aparece en tres lugares distintos. En el nivel superior, esta
cabecera indica que el mensaje tiene varias partes, y que cada una contiene el mismo mensaje
codificado en diferentes formatos. Las partes están delimitadas por dos guiones seguidos de una
cadena, definida por el usuario, especificada en el parámetro boundary. Los estándares
135
recomiendan que esta cadena sea única en el mundo. El final de las distintas partes se marca con
dos guiones seguidos de la cadena boundary seguida de otros dos guiones.
En las dos partes la cabecera Content-Type indica el tipo y el subtipo de la parte. En la primera
parte indica que sigue un texto sin formato en ASCII de 7 bits. En la segunda parte indica que
sigue un archivo de audio. Observe como en esta parte también se requiere una cabecera Content-
Transfer-Encoding para indicar la codificación adecuada para el sonido. Si el receptor tiene
capacidad de audio, el agente de usuario decodificara y ejecutara el archivo de sonido
aniversario.snd.
Algunos ejemplos de MIME
Ejemplo 1:
From: pepe@pepe.com
Subject: Pruebas-(S)MIME
To: alguno@pepe.com
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Este es un mail MIME simple
Ejemplo 2:
From: pepe@pepe.com
To: alguno@pepe.com
MIME-Version: 1.0
boundary=linux.00.sáb.dic..9.13:11:01.CET.2000
--linux.00.sáb.dic..9.13:11:01.CET.2000
Es una alternativa de texto
--linux.00.sáb.dic..9.13:11:01.CET.2000
Content-Disposition: inline
<html>Alternativa <b>HTML</b>
--linux.00.sáb.dic..9.13:11:01.CET.2000-
Ejemplo 3:
From: pepe@pepe.com
136
To: alguno@pepe.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
--linux.00.sáb.dic..9.13:25:31.CET.2000
Este mail lleva una pequeña imagen
--linux.00.sáb.dic..9.13:25:31.CET.2000
Content-Type: image/gif;
name="sound2.gif"
R0lGODlhKwAmAPf/AP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+Z
YgoK0
sWrab651h9lK8jghUd+stdKID/Jlxgi+NlX32ugRrnCFSjxUd8gO1GaUEPzWWFTgl54MQ
g/VEm
2qkpPIdACFN7tkeqKMSVmBbAJEnZaRiOKF8CEJc4AhY4rtijth0kBhtppguDTAlQTSgV
Fhs+O
Ga0VgXwjGCILZ8TPFSwsV+JTUVY6EkkH54PILFuaNp0+UUTklAyv0fsWxl6BlU8X+
wTyZF
dj5YgkSSXdY7NYY5FF8JFtJQmUWrXxLPRBAQEAOw==
--linux.00.sáb.dic..9.13:25:31.CET.2000-
Ejemplo 4:
From: pepe@pepe.com
To: alguno@pepe.com
MIME-Version: 1.0
--linux.00.sáb.dic..9.13:25:33.CET.2000
--linux.11.sáb.dic..9.13:25:33.CET.2000
Alternativa de texto
--linux.11.sáb.dic..9.13:25:33.CET.2000
137
<html>Alternativa <b>HTML</b>
--linux.11.sáb.dic..9.13:25:33.CET.2000-
--linux.00.sáb.dic..9.13:25:33.CET.2000
name="sonido.gif"
YgoK0
g/VEm
Fhs+O
wTyZF
--linux.00.sáb.dic..9.13:25:33.CET.2000-
Ejemplo 5:
From: pepe@pepe.com
To: alguno@pepe.com
MIME-Version: 1.0
--linux.00.sáb.dic..9.13:25:39.CET.2000
Un texto
--linux.00.sáb.dic..9.13:25:39.CET.2000
name="imagen2.gif"
R0lGODlhKwAnAPf/AP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzJ
kAmZ
kAZpkAM5kAAGb//2b/zGb/mWb/Zmb/M2b/AGbM/2bMzGbMmWbMZmbMM2bMAG
aZ/2aZ
zAAAmQAAZgAAM+4AAN0AALsAAKoAAIgAAHcAAFUAAEQAACIAABEAAAD
uAADd
138
AAC7AACqAACIf/RAiw4d2uQ/VvlWdFR7uW5HsmlZy55N2269qjwRBcK3gi5tgn4FC5
SrD1w
/uB1XELW8Fvc9mA9/UHXmZ2nqHOgPK4OqhuxHt+GmFYWuJtaYfvh4KJZdIYK05Vf
0ghUW
--linux.00.sáb.dic..9.13:25:39.CET.2000
Content-Type: text/x-vcard;
name="mm.nisu.vcard"
Content-Disposition: attachement;
filename="mm.nisu.vcard"
este es un = attachment
--linux.00.sáb.dic..9.13:25:39.CET.2000-
Ejemplo 6 (anidamiento simple):

From: pepe@pepe.com
To: alguno@pepe.com
MIME-Version: 1.0
--linux.00.sáb.dic..9.16:21:34.CET.2000
--linux.11.sáb.dic..9.16:21:34.CET.2000
Primer bloque con imagen
--linux.11.sáb.dic..9.16:21:34.CET.2000
name="sound2.gif"
YgoK0
g/VEm
Fhs+O
wTyZF
139
--linux.11.sáb.dic..9.16:21:34.CET.2000-
--linux.00.sáb.dic..9.16:21:34.CET.2000
--linux.22.sáb.dic..9.16:21:37.CET.2000
Segundo bloque con imagen
--linux.22.sáb.dic..9.16:21:37.CET.2000
name="world2.gif"
R0lGODlhKwAnAPf/AP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzJ
kAmZ
kAZpkAM5kAAGb//2b/zGb/mWb/Zmb/M2b/AGbM/2bMzGbMmWbMZmbMM2bMAG
aZ/2aZ
zAAAmQAAZgAAM+4AAN0AALsAAKoAAIgAAHcAAFUAAEQAACIAABEAAAD
uAADd
AAC7AACqAACIf/RAiw4d2uQ/VvlWdFR7uW5HsmlZy55N2269qjwRBcK3gi5tgn4FC5
SrD1w
/uB1XELW8Fvc9mA9/UHXmZ2nqHOgPK4OqhuxHt+GmFYWuJtaYfvh4KJZdIYK05Vf
0ghUW
--linux.22.sáb.dic..9.16:21:37.CET.2000-
--linux.00.sáb.dic..9.16:21:34.CET.2000-
[61]
Indique cual es el objetivo del protocolo o especificación MIME.
[62]
Indique concretamente cuales son las mejoras que introduce el protocolo MIME en el contenido de
los mensajes de correo electrónico.
[63]
Indique cual es el objetivo de los campos MIME en una cabecera de correo SMTP.
[64]
Indique en forma resumida como se organizan los campos o partes de un mensaje MIME.
140
[65]
En la siguiente cabecera SMTP/MIME identifique la línea que contiene la definición de un

límite de contenidos:
From: mabel@hotmail.com
To: florencia@yahoo.com
Subject: Queria decirte ...
MIME-Version: 1.0
Message-Id: <0704760941.AA00747@abc.com>

Feliz cumpleaños para ti, querida Florencia
Feliz cumpleaños para ti.
Content-Type: audio/basic;
directory="tmp";
name="aniversario.snd"
MIIC1DCCAn6gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBgDELMAkGA1UEBhM
CRVMx
DzANBgNVBAgUBkVzcGHxYTESMBAGA1UEBxMJQ2FzdGVsbG9uMQ0wCwYDV
QQKEwMX
aXN1MR0wGwYDVQQDExRNYW5vbG8gTW9sbGFyIEdhcmNpYTEeMBwGCSqGSIb
3DQEJ
ARYPbW9sbGFyQG5pc3Uub3JnMB4XDTAwMTEyMzA4MTIxOVoXDTAwMTIyMzA
4MTIx
OVowgYAxCzAJBgNVBAYTAkVTM
[66]
En el ejemplo anterior señale la línea que define un límite de contenido.
[67]
En el ejemplo anterior señale la línea que define el cierre de un límite de contenido.
141
6.9 El protocolo Telnet
El propósito del protocolo TELNET es proporcionar un servicio de comunicaciones orientado a

bytes de 8 bit general y bidireccional.
El principal objetivo es permitir un método estándar para comunicar entre sí terminales y procesos
orientados a terminal. Está previsto que el protocolo se pueda usar también para comunicaciones
terminal-terminal ("enlace") y comunicaciones proceso-proceso (computación distribuida).
El protocolo TELNET se basa en tres ideas principales: primera, el concepto de un "Terminal

Virtual de Red" (NVT, Network Virtual Terminal); segunda, el principio de opciones negociadas;
y tercera, una visión simétrica de terminales y procesos.
El Terminal Virtual de Red
El Terminal Virtual de Red (NVT, Network Virtual Terminal) es un dispositivo bidireccional de

caracteres. El NVT tiene una impresora y un teclado. La impresora responde a los datos que llegan
y el teclado produce los datos de salida que se envían a través de la conexión TELNET y, si se
desea, también a la impresora del NVT. Los "ecos" (caracteres tipeados en teclado que aparecen en
la pantalla) no deberían recorrer la red (aunque existen opciones para activar el modo de operación
de eco "remoto", no es obligatorio implementar esta opción). El código usado es USASCII de siete
bits en un campo de ocho bits. Cualquier conversión de códigos u otras consideraciones que surjan
son problemas locales y no afectan al NVT.
Un NVT es un dispositivo imaginario que proporciona una representación normalizada intermedia

de un terminal real. Esto elimina la necesidad para los computadores "servidor" y "usuario" de
guardar información de las características del terminal del otro y de las convenciones para
manejarlo. Ambos mapean (relacionan) las características del dispositivo local para que a través de
la red parezca un NVT y ambos pueden asumir un mapeado similar en el otro extremo. Se pretende
que el NVT sea algo intermedio entre ser muy restringido (que no proporciona a los computadores
lo suficiente como para mapear sus códigos de caracteres locales), y ser demasiado exigente
(penalizando a los usuarios con terminales modestos).
El computador "usuario" es aquel al que el terminal físico está normalmente conectado y el

computador "servidor" es el que normalmente proporciona algún servicio. Desde otro punto de
vista, aplicable incluso en comunicaciones terminal-terminal o proceso-proceso, el computador
"usuario" es aquel que inicia la comunicación donde se encuentra el usuario que interactúa con el
servidor.
Opciones negociadas
El principio de opciones negociadas tiene en cuenta el hecho de que muchos computadores querrán
proporcionar servicios adicionales a los disponibles en un NVT y muchos usuarios tendrán
terminales sofisticados y querrán disponer de servicios sofisticados en lugar de los mínimos.
La estrategia básica para el uso de opciones es hacer que una parte (o ambas) inicien la petición de
activar alguna opción. El otro lado puede entonces aceptar o rechazar la petición. Si la petición se
acepta, tiene efecto inmediato; si se rechaza, el aspecto asociado de la conexión queda tal y como
se especifica para un NVT. Claramente, una parte siempre puede rehusar activar una opción y
142
nunca debe rehusar desactivar alguna opción ya que ambos lados deben estar preparados para
soportar un NVT.
Simetría de las conexiones
En la medida de lo posible, el protocolo TELNET se ha hecho simétrico entre el servidor y el

usuario para que de forma natural se adapte a conexiones usuario-usuario y servidor-servidor. Se
espera, pero no se requiere en absoluto, que las opciones fomenten la simetría. En cualquier caso,
se acepta explícitamente que la simetría es un principio operativo más que una regla inamovible.
Transmisión de datos
Aunque una conexión TELNET a través de la red es intrínsecamente bidireccional (full-dúplex), se

debe ver al NVT como un dispositivo unidireccional (half-dúplex) operando en modo línea. A no
ser que se negocien opciones indicando lo contrario, se aplican las condiciones por defecto a la
transmisión de datos por la conexión TELNET.
Cuando se usa para acceso remoto de usuarios a un computador (acceso desde un terminal
remoto) a este protocolo se le asigna el puerto servidor 23 (27 en octal).
Estructura de las órdenes en Telnet
La comunicación entre cliente y servidor se maneja con órdenes internas, que no son accesibles
por los usuarios. Todas las órdenes internas de Telnet consisten en secuencias de 2 ó 3 bytes,
dependiendo del tipo de orden.
Órdenes básicas de Telnet
El objetivo primario del protocolo Telnet es la provisión de una interfaz estándar para hosts sobre
una red. Para permitir la conexión entre hosts con distintos sistemas operativos, el protocolo Telnet
define una representación estándar para algunas funciones:
IP: Interrumpir proceso

AO: Abortar salida
AYT: Estás ahí (Are You There)
EC: Borrar carácter
EL: Borrar línea
SYNCH: Sincronismo
Aplicaciones de Telnet
Veremos algunas de las aplicaciones de Telnet.
Terminal virtual
Mediante Telnet es posible crear una sesión de Terminal en un servidor desde un host cliente de tal
manera que se pueda acceder al intérprete de comandos como es la práctica habitual en UNIX o
Linux. En otras palabras, un “usuario” accede a los servicios de un intérprete de comandos.
143
En el servidor UNIX existirá un servidor Telnet en el puerto 23 que espera una conexión de algún
cliente Telnet. Una vez establecida la conexión, el servidor solicita la identificación del usuario.
Una vez que este se registra exitosamente, el servidor lo conecta con el intérprete de comandos
respectivo del servidor. A partir de allí, el usuario podrá ejecutar los comandos en el host remoto
como si estuviera trabajando localmente.
Conectarse con el cliente Telnet al servidor POP3.
Es posible conectarse con Telnet al puerto 110 para peticionar comandos al servidor POP3 como
vemos en el siguiente ejemplo
1.Conectarse:
telnet servidorPOP3.pepe.com 110
2.Identificarse:
user nombreDeUsuario
pass contraseña
3.Ver la lista de mensajes:
list
stats
4.Leer un mensaje:
retr mensajeNúmero
top mensajeNúmero númeroDeLíneas
5.Borrar un mensaje:
dele mensajeNúmero
rset
144
6.Terminar la sesión:
quit
Conectarse con el cliente Telnet al servidor SMTP
1. Conectarse:
Telnet servidorSMTP.com 25
2. Saludar:
helo nombre de dominio
3. Enviar un mensaje:
mail from: ricardo@delRemite.nte

rcpt to: oscar@delDestinata.rio
data
4. Añadir cabeceras:
subject: elAsunto
from: miNombre
to: elNombreDelOtro
5. Escribir el cuerpo del mensaje:
Este_es_el_mensaje …………….
6.
Terminar la sesión:
quit
[68]
Indique cual es el objetivo del protocolo Telnet.
[69]
Defina que se entiende por NVT en el protocolo Telnet.
[70]
De un ejemplo de la aplicación del protocolo Telnet.
145
6.10 Administración de redes

Corresponde servicio básico que se usa en redes TCP/IP para administrar dispositivos de red en
forma remota.
En el mundo actual, en el que la informática gira en torno al concepto de red, el trabajo de los
administradores de sistemas es muy complejo. Su misión consiste en mantener en funcionamiento
recursos tales como encaminadores (routers), concentradores (hubs), servidores, así como cada
dispositivo crítico que conforma la red.
Hay gran cantidad de motivos por los cuales un administrador necesita monitorizar entre otros:
• La utilización del ancho de banda

• El estado de funcionamiento de los enlaces
• La detección de cuellos de botella
• Solucionar problemas en el cableado
• Administrar la información de encaminamiento entre máquinas
La monitorización de la red es también un buen punto para comenzar el estudio de los problemas
de seguridad.
Por ejemplo, en la gestión de un hub, SNMP podría desconectar automáticamente los nodos que
estén corrompiendo la red, o se podrían establecer alarmas para alertar al administrador de la red
cuando en un dispositivo el tráfico de datos supere el umbral establecido, o se podrían buscar IPs
duplicadas, etc.
En muchos casos, la red de una organización está enlazada mediante costosos enlaces a redes de
área extensa (WAN) o con la Internet, y cuyos costos dependen del volumen de tráfico.
Es muy importante mantener un registro estadístico del tráfico que circula por estos enlaces. Ésta
situación es bastante común en los enlaces X.25, y son todavía de uso corriente. La tarificación de
este tipo de líneas se realiza en función del número de paquetes enviados y recibidos.
Otros tipos de enlaces, como los punto a punto (Frame relay), son de tarifa plana. En éstos la
compañía telefónica ha de garantizar un ancho de banda, el cual es importante monitorizar.
La organización ISO ha creado un modelo de gestión de red estructurado en cinco áreas:
Gestión de rendimiento: tiene por objetivo mejorar el rendimiento de la red mediante la

optimización de los dispositivos y su accionar. Por ejemplo interactuar sobre una tabla de ruteo
para optimizar el tráfico de paquetes.
Gestión de fallos: trata sobre la gestión de dispositivos para reaccionar frente a fallos producidos.
Gestión de configuración: Permite la configuración remota de dispositivos.
Gestión de cuentas: Gestiona la admisión y restricción acceso a usuarios de la red.
146
Gestión de seguridad: gestiona métodos y definiciones de seguridad como gestión de claves,

control de acceso a los recursos, etc.
Infraestructura para la gestión
Intervienen los siguientes componentes fundamentales:
Entidad gestora: es una aplicación con control humano que supervisa y controla el desempeño de
los dispositivos que con su comportamiento modifican el comportamiento de la red.
Dispositivo gestionado: Son los dispositivos de red sensibles a la gestión centralizada por el
gestor.
Base de datos de la información gestionada: Se entiende por información gestionada, aquella

que indica o mide el comportamiento de los dispositivos monitorizados y controla los dispositivos
comandados en forma remota.
Agente de gestión: es un proceso que se ejecuta en un dispositivo gestionado, para relacionarlo

interactivamente con el gestor remoto.
Protocolo de gestión: es el que posibilita el diálogo entre el gestor y el dispositivo gestionado.
En la figura se muestra una red con los dispositivos gestionados y los gestores.
La descripción anterior sobre gestión de red es bastante global y se aplica a varios estándares de
gestión de redes. A fines de la década de los 80 apareció el protocolo SNMP con el propósito de
147
ser independiente del hardware, de la plataforma y de las aplicaciones. En las siguientes sesiones
trataremos específicamente el protocolo SNMP y otros estándares relacionados.
Gestión de redes en Internet
El entorno de gestión estándar de Internet se ocupa de las siguientes cuestiones, mediante normas
que interactúan pero que se mantien independientes entre si, y al mismo tiempo se aplican a
sistemas heterogéneos que interactúan:
Definición de los objetos de gestión de red: también conocidos como objetos MIB. Los
elementos que referencian la gestión, son objetos que se almacenan en una base de datos virtual
conocida como base de información de gestión (MIB).
Cada objeto contiene información de distinto tipo que permite medir o conocer el estado de un
dispositivo como también actuar sobre él para ejercer el control remoto.
Los objetos MIB definen la información de gestión que mantiene un dispositivo. MIB define la
información que intercambian gestores y gestionados. Los objetos que están relacionados se
agrupan en módulos. Existen módulos estándar definidos por normas y módulos propietarios
definidos por fabricante de dispositivos.
Lenguaje de definición de datos: conocido como SMI o estructura de información de gestión

(Structure of Management Information), que define los tipos de datos, un modelo de objetos, y
reglas para representar la información de gestión. SMI define el formato de los datos que se
intercambian el gestor y los gestionados. También podemos decir que SMI define el formato de los
objetos MIB.
El protocolo SNMP: permite el intercambio de datos y comandos entre el gestor y los

gestionados. Es el que define el diálogo entre el gestor SNMP y los agentes SNMP.
Base de información de gestión (MIB)
Es una base de datos distribuida que almacena los objetos administrables de la red. Estos objetos
pueden ser consultados o modificados mediante el protocolo SNMP. Los objetos se especifican
utilizando la construcción SMI OBJECT-TYPE, y son agrupados en módulos utilizando el
constructor MODULE-IDENTITY.
La IETF se ocupa de definir módulos para dispositivos genéricos de red y de esa forma generó
alrededor de 100 módulos MIB basado en los estándares.
Un problema que se tuvo que resolver es referente al nombre de los objetos para evitar todo tipo de
ambigüedad en sistemas heterogéneos que interactúan. Para resolver dicho problema se adoptó el
entorno de definición de objetos de la ISO denominado ASN.1 o Notación de Sintaxis Abstracta
Uno. ASN.1 es un lenguaje de definición de objetos que complementa al lenguaje SMI
fundamentalmente en definiciones de transferencia de objetos y en la adopción de un esquema de
nombres de objetos universal que puede ser adoptado por cualquier sistema. De esta forma se
obtiene la solución para el caso en que interactúen sistemas heterogéneos. En la siguiente figura se
representa el árbol de definición de objetos ASN.1.
148
SMI a través de ASN.1, define un esquema jerárquico de nombres de “objetos de información”

que se representan mediante un árbol que comienza en su máximo nivel con el nodo ”.” llamado
“root”, y por debajo de él otros sub-árboles. Aquellos objetos que no contengan a otros objetos se
definen como objetos “hojas”. En la siguiente figura se muestra el árbol de objetos SMI.
El espacio de nombres ISO (sub-árbol) está situado dentro del espacio de nombres SMI/ASN.1
junto con otros árboles de otros estándares de otras organizaciones. Dentro del espacio de nombres
ISO hay una rama específica para la información MIB. Dentro de esta rama MIB, los objetos están
a su vez jerarquizados en su-árboles para los distintos protocolos y aplicaciones, de forma que esta
información puede representarse unívocamente.
149
En la figura se puede apreciar el espacio de nombres del MIB del TCP/IP, que está situado dentro
del árbol SMI/ASN.1, justo bajo el espacio del sub-árbol "mgmt". La jerarquía también específica
el número para cada nivel.
Lo que se representa en la parte inferior del árbol de la figura anterior, son los módulos MIB.
Cada nodo contenedor de módulos está administrado por el IETF para el caso de módulos IETF, o
por empresas propietarias que homologan sus respectivos objetos que permiten la gestión de sus
productos. En la siguiente figura se muestran algunos módulos MIB definidos por la IETF.
En la siguiente figura se puede apreciar la rama del árbol que corresponde a Internet.
Vemos a la rama de módulos privados en donde se puede apreciar el nodo asignado a la empresa
CISCO.
150
Volviendo al caso específico de los módulos MIB, podemos agregar que la versión MIB-II se
encuentra definida en el RFC-1213. En ella se clasifica la información que un dispositivo puede
mantener, en diez categorías. Cualquier variable ha de estar en una de estas categorías.
Categoría Información
system Información del host del sistema de encaminamiento
interfaces Información de los interfaces de red
addr-translation Información de traducción de direcciones
ip Información sobre el protocolo IP
icmp Información sobre el protocolo ICMP
tcp Información sobre el protocolo TCP
udp Información sobre el protocolo UDP
egp Información sobre el protocolo (Exterior Gateway)
transmission No hay objetos definidos para este grupo
snmp Información de actividad SNMP
A continuación se resumen algunos ejemplos de objetos de cada grupo. La lista completa está
definida en el RFC 1213.
• Grupo de sistema
o sysDescr - Descripción completa del sistema(version, HW, OS)
o sysObjectID - Identificación que da el distribuidor al objeto
o sysUpTime - Tiempo desde la última reinicialización
o sysContact - Nombre de la persona que hace de contacto
o sysServices - Servicios que ofrece el dispositivo
• Grupo de interfaces
o ifIndex - Número de interfaz
o ifDescr - Descripción de la interfaz
o ifType - Tipo de la interfaz
o ifMtu - Tamaño máximo del datagrama IP
o ifAdminisStatus - Status de la interfaz
o ifLastChange - Tiempo que lleva la interfaz en el estado actual
o ifINErrors - Número de paquetes recibidos que contenían errores
o ifOutDiscards - Número de paquetes enviados y desechados
• Grupo de traducción de direcciones
o atTable - Tabla de traducción de direcciones
o atEntry - Cada entrada que contiene una correspondencia de dirección de red a
dirección física
o atPhysAddress - La dirección física dependiente del medio
o atNetAddress - La dirección de red correspondiente a la dirección física
• Grupo IP
o ipForwarding - Indicación de si la entidad es una pasarela IP
o ipInHdrErrors - Número de datagramas de entrada desechados debido a errores en
sus cabeceras IP
151
o ipInAddrErrors - Número de datagramas de entrada desechados debido a errores en

sus direcciones IP
o ipInUnknownProtos - Número de datagramas de entrada desechados debido a
protocolos desconocidos o no soportados
o ipReasmOKs - Número de datagramas IP reensamblados con éxito
o ipRouteMask - Máscara de subred para el encaminamiento
• Grupo ICMP
o icmpInMsgs - Número de mensajes ICMP recibidos
o icmpInDestUnreachs - Número de mensajes ICMP "destino
inalcanzable"(destination unreachable) recibidos
o icmpInTimeExcds - Número de mensajes ICMP "time exceeded"(tiempo excedido)
recibidos
o icmpInSrcQuenchs - Número de mensajes ICMP "source quench(desbordamiento
del emisor) recibidos
o icmpOutErrors - Número de mensajes ICMP no enviados debido a problemas en
ICMP
• Grupo TCP
o tcpRtoAlgorithm - Algoritmo que determina el timeout para retransmitir octetos
para los que no se ha recibido reconocimiento
o tcpMaxConn - Límite en el número de conexiones TCP que puede soportar la
entidad
o tcpActiveOpens - Número de veces que las conexiones TCP han efectuado una
transición directa del estado SYN-SENT al estado CLOSED
o tcpInSegs - Número de segmentos recibidos, incluyendo aquellos con error
o tcpConnRemAddress - La dirección IP remota para esta conexión TCP
o tcpInErrs - Número de segmentos desechados debido a errores de formato
o tcpOutRsts - Número de resets generados
• Grupo UDP
o udpInDatagrams - Número de datagramas UDP entregados a usuarios UDP
o udpNoPorts - Número de datagramas UDP recibidos para los que no existía
aplicación en el puerto de destino
o udpInErrors - Número de datagramas UDP recibidos que no se pudieron entregar
por razones otras que la ausencia de la aplicación en el puerto de destino
o udpOutDatagrams - Número de datagramas UDP enviados por la entidad
• Grupo EGP
o egpInMsgs - Número de mensajes EGP recibidos sin error
o egpInErrors - Número de mensajes EGP con error
o egpOutMsgs - Número de mensajes EGP generados localmente
o egpNeighAddr - La dirección IP del vecino de esta entrada EGP
o egpNeighState - El estado EGP del sistema local con respecto a la entrada EGP
vecino
Esta no es la definición completa del MIB pero sirve de ejemplo de los objetos de cada grupo.
La definición de un elemento concreto MIB implica la especificación del tipo de dato que puede
contener. Normalmente, los elementos de un MIB son enteros, pero también pueden almacenar
cadenas de caracteres o estructuras más complejas como tablas.
152
Los objetos administrables son los nodos hoja del árbol MIB. Un objeto puede tener más de una
instancia (valor), como por ejemplo un objeto tabla. Para referirse al valor contenido en un objeto,
se ha de añadir el número de la instancia. Cuando sólo exista una instancia del objeto, está es la
instancia cero.
Por ejemplo, el objeto ifNumber de la categoría "interfaces" es un entero que representa el número
de interfaces de red presentes en el dispositivo; mientras el objeto ipRoutingTable de la categoría
"ip" contiene la tabla de encaminamiento del dispositivo.
Hay que utilizar el número de la instancia para leer el valor de un objeto. En este caso, el número
de interfaces presentes en un encaminador puede ser observado mediante la instancia ifNumber.0.
En el caso de ser un objeto tabla, se ha de utilizar el índice a la tabla como último número para
especificar la instancia (fila de la tabla).
Es importante constatar que la mayor parte del software necesita el punto raíz (.) para localizar el
objeto en el MIB. Si no se incluye el punto raíz, se asume que el path es relativo desde
.iso.org.dod.internet.mgmt.mib-2.
De esta forma, el objeto ifNumber de la categoría "interfaces" se puede llamar:
• .iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber
• el equivalente numérico: .1.3.6.1.2.1.2.1
• la instancia es: .iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber.0
• el equivalente numérico: .1.3.6.1.2.1.2.1.0
Estructura de información de gestión (SMI)
SMI es un lenguaje que se utiliza para definir la información de gestión (objetos MIB) de una red.
Este lenguaje es necesario para asegurar que la sintaxis y semántica de los datos de gestión de la
red estén bien definidos y no sean ambiguos. SMI define primero los tipos de datos básicos y luego
las construcciones de las definiciones de objetos MIB.
La RFC 2578 especifica los tipos de datos básicos de SMI. También SMI adopta las definiciones
de ASN.1. En la siguiente tabla, a modo de ejemplo, se muestran los 11 tipos de datos básicos de
la RFC 2578.
Tipo de datos
INTEGER
OCTET STRING
Counter
OBJECT IDENTIFIER
NULL
SEQUENCE
SEQUENCE OF
IpAddress
153
NetworkAddress
Gauge
TimeTicks
Opaque
Además de los tipos básicos, el lenguaje SMI define objetos mediante construcciones de alto nivel.
A modo de ejemplo se indica a continuación la definición del objeto snmpORLastChange
mediante el constructor OBJECT-TYPE.
snmpORLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"El valor de sysUpTime en el momento
del cambio más reciente en el valor
o estado de cualquier instancia de
snmpORID."
También se definen grupos de objetos o módulos mediante el constructor MODULE-IDENTITY,

como se muestra a continuación.
fizbin MODULE-IDENTITY
LAST-UPDATED "9210070433Z"
ORGANIZATION "IETF SNMPv2 Grupo de trabajo"
CONTACT-INFO
" Marshall T. Rose
Postal: Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186,
US
Tel: +1 415 968 1052
Fax: +1 415 968 2510
E-mail: mrose@dbc.mtview.ca.us "
DESCRIPTION
"Módulo MIB para entidades SNMPv2."
REVISION "9210070433Z"
DESCRIPTION
"Versión inicial de este módulo MIB."
::= { snmpModules 1 }
El estándar ASN.1
ASN.1 (Abstract Syntax Notation number One) es un estándar internacional que tiene como
objetivo especificar los datos usados en protocolos de la telecomunicación. Es un lenguaje
computacional de gran alcance y complejo: fue diseñado para modelar eficientemente la
comunicación entre los sistemas heterogéneos.
La Notación de Sintaxis Abstracta Uno (ASN.1) es una notación que se utiliza para describir los
mensajes que se intercambian entre si los programas de aplicación. Proporciona una descripción
154
del alto nivel que libera a los diseñadores de protocolos de tener que centrarse en los detalles de los
bits y bytes del mensaje.
Inicialmente describían los mensajes de E-mail dentro de los protocolos de ISO (Open Systems
Interconnection). ASN.1 ha sido adoptado desde entonces para el uso por una amplia gama de
otros usos, por ejemplo en la gestión de la red, E-mail seguro, telefonía celular, control del tráfico
aéreo, y voz y vídeo sobre el Internet.
ASN.1 define las reglas de codificación estandardizadas que describen los bits y bytes de los
mensajes, mientras están en tránsito entre los programas que se comunican.
Ni ASN.1 ni sus reglas de codificación están condicionadas con la estructura de la arquitectura

particular de la computadora, del sistema operativo, del lenguaje o del programa en uso, y se
utilizan en lenguajes de programación, incluyendo Java, C++, C o COBOL.
Los documentos formales de los estándares en ASN.1 y sus reglas de codificación son publicados
por el International Telecommunications Union Telecommunications (ITU-T) y por el
International Standards Organization (ISO) / International Electrotechnical Commission (IEC).
Aunque los estándares son muy directos y exactos en sus definiciones, no son fáciles de leer.
El protocolo SNMP
El participante principal del sistema de gestión de red es el protocolo llamado Simple Network
Management Protocol (SNMP). Diseñado en los años 80, su principal objetivo fue el integrar la
gestión de diferentes tipos de redes mediante un diseño sencillo y que produjera poca sobrecarga
en la red.
SNMP opera en el nivel de aplicación, utilizando el protocolo de transporte UDP de TCP/IP, por lo
que ignora los aspectos específicos del hardware sobre el que funciona. La gestión se lleva a cabo
a nivel de IP, por lo que se pueden controlar dispositivos que estén conectados en cualquier red
accesible desde la Internet, y no únicamente aquellos localizados en la propia red local.
Evidentemente, si alguno de los dispositivos a controlar no funciona correctamente, no será posible

su monitorización ni re-configuración.
El protocolo SNMP está compuesto por dos elementos: el agente (agent), y el gestor (manager). Es
una arquitectura cliente-servidor, en la cual el agente desempeña el papel de servidor y el gestor
hace el de cliente.
El agente es un programa que ha de ejecutase en cada dispositivo de red que se desea gestionar o
monitorizar. Ofrece un interfaz a todos los elementos que se pueden configurar. Estos elementos se
almacenan en unas estructuras de datos jerárquicos, llamadas "Management Information Base"
(MIB).
El gestor es el software que se ejecuta en la estación encargada de monitorizar y controlar la red, y

su tarea consiste en consultar los diferentes agentes que se encuentran en los servidores y
dispositivos de encaminamiento de la red, mediante los datos MIB que estos han ido obteniendo.
En la siguiente figura se muestra un esquema de gestión de una red.
155
Vemos que en cada dispositivo que interviene en la administración consta de una base de datos
MIB. También notamos la presencia de un gestor intermedio que se ocupa de gestionar una parte
de la red para descentralizar la función de gestión. Sin embargo dicho gestor es a su vez gestionado
por el gestor de mayor jerarquía que se muestra en la parte superior de la figura.
Hay un comando especial en SNMP, llamado trap, que permite a un agente enviar datos que no
han sido solicitados de forma explícita al gestor, para informar de eventos tales como: errores,
fallos en la alimentación eléctrica, etc.
En esencia, el SNMP es un protocolo muy sencillo puesto que todas las operaciones se realizan
bajo el paradigma de carga-y-almacenamiento (load-and-store), lo que permite un juego de
comandos reducido.
Un gestor puede realizar sólo dos tipos diferentes de operaciones sobre un agente: leer o escribir
un valor de una variable en el MIB del agente.
Estas dos operaciones se conocen como petición-de-lectura (get-request) y petición-de-escritura

(set-request). Hay un comando para responder a una petición-de-lectura llamado respuesta-de-
lectura (get-response), que es utilizado únicamente por el agente.
156
La posibilidad de ampliación del protocolo, está directamente relacionado con la capacidad del
MIB de almacenar nuevos elementos. Si un fabricante quiere añadir un nuevo comando a un
dispositivo, como puede ser un encaminador, tan sólo tiene que añadir las variables
correspondientes a su base de datos (MIB).
Casi todos los fabricantes implementan versiones agente de SNMP en sus dispositivos:
encaminadores, hubs, sistemas operativos, etc.
Un mensaje de SNMP consiste en un identificador de la versión, un nombre de la comunidad

SNMP y un PDU ("protocol data unit"). Toda implementación de SNMP debe soportar las cinco
PDUs siguientes:
• GetRequest: Recuperar los valores de un objeto del MIB. Del gestor al agente.
• GetNextRequest: Obtener la siguiente instancia de una lista. Del gestor al agente.
• SetRequest: Alterar los valores de un objeto del MIB. Del gestor al agente.
• InformRequest: Pedir información a otro gestor. De gestor a gestor.
• GetBulkRequest: Obtener múltiples datos de una tabla. Del gestor al agente.
• GetResponse: Respuesta de GetRequest, GetNextRequest, GetBulkRequest,
InformRequest y SetRequest.
• Trap: Capacidad de los elementos de red para generar eventos como la inicialización.,
reinicio o fallo en el enlace del MA. Hay siete tipos de traps definidos en el RFC 1157:
coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss y
enterpriseSpecific.
Los formatos de estos mensajes son los siguientes:
En la figura se muestra el formato de un mensaje SNMPv1 como ejemplo. Los campos varían
según el tipo de mensaje.
La seguridad en SNMP
SNMPv1 ofrece muy poco soporte para la autentificación. Tan sólo ofrece el esquema de dos
palabras clave (two-passwords). La clave pública permite a los gestores realizar peticiones de
valores de variables, mientras que la clave privada permite realizar peticiones de escritura.
157
A estas palabras clave se les llama en SNMP communities. Cada dispositivo conectado con una red
gestionada con SNMP, ha de tener configuradas estas dos communities.
Es muy común tener asignando por defecto el valor "public" al community público, y "private" al
privado. Por lo que es muy importante cambiar estos valores para proteger la seguridad de tu red.
En la última versión de SNMP denominada SNMPv3 se incluyen normas de seguridad que

confieren a este protocolo capacidades de cifrado y autentificación.
[71]
Indique cinco razones para realizar el monitoreo de los dispositivos de red.
[72]
Explique en forma resumida las tareas de gestión en una red.
[73]
Explique en forma resumida los elementos que intervienen en una gestión de red bajo protocolo
TCP/IP.
[74]
Explique con detalle, lo que Ud entiende por objeto de gestión de red en una administración
SNMP.
[75]
Explique en forma resumida el estándar de definición de datos para objetos MIB.
[76]
Explique en forma resumida que es el protocolo SNMP.
[77]
Explique que es el estándar ASN.1.
158
RESPUESTA A LAS ACTIVIDADES DEL PROCESO

1)
El servicio DNS permite resolver nombres DNS en direcciones IP y viceversa. Se basa en un
esquema de nombres jerárquico y en una base de datos jerárquica distribuida que contiene los
nombres y direcciones IP, permitiendo una administración distribuida y una navegación desde la
raíz que permite acceder a todas las ramas del árbol. Las computadoras que administran y
materializan dicho árbol, almacenando a las bases de datos, se denominan servidores DNS.
2)
Un servidor primario admite actualizaciones estáticas y/o dinámicas de las zonas que contiene. Un
servidor secundario solamente puede copiar el contenido de las zonas a un servidor primario. Un
servidor puede ser primario de una zona y secundario de otra. Los servidores, primario y
secundarios de una zona, tienen autoridad sobre dicha zona. Un cliente DNS no diferencia entre
servidor primario y secundario.
3)
Un servidor DNS de solo cache puede resolver nombres y direcciones IP mediante consultas a
otros servidores DNS, pero no tiene autoridad sobre ninguna zona. Solamente almacena un cache
donde guarda temporariamente el resultado de sus consultas. También mantiene en dicho cache, la
ubicación de los root-servers para poder navegar por el árbol DNS.
4)
Un dominio es una jerarquía de nombres que incluye a todos los nombres por debajo de dicha
jerarquía. Una zona es una base de datos que contiene información DNS a partir de un determinado
dominio que se conoce como dominio principal o raíz de la zona. Una zona puede o no contener a
todos los sub-dominios de su dominio principal. Una zona que contenga información de un sub-
dominio se llama zona hija de la que contiene la información del dominio. La relación madre-hija
de las zonas materializa el árbol DNS. La zona madre contiene las direcciones IP de los servidores
que contienen a las zonas hijas, para permitir la navegación del árbol DNS desde “arriba hacia
abajo”. Siempre es posible la navegación desde un root-server hasta cualquier zona del árbol.
5)
Una zona directa permite obtener la dirección IP a partir de un nombre DNS. Una zona inversa
permite obtener un nombre DNS a partir de una dirección IP.
6)
Los más comunes son A, PTR, NS, MX y SOA. También existen otros que no son menos
importantes.
7)
Un archivo de zona contiene la información de una zona. Los servidores DNS son las
computadoras que almacenan dichos archivos.
8)
Un servidor DNS forwarder es un servidor DNS que acepta consultas recursivas de otros
servidores DNS que actúan como clientes. La definición de un forwarder a un servidor DNS le
permite a este, consultar en forma recursiva al forwarder para tratar de acceder más rápidamente a
la información que desea conocer pensando que el forwarder tiene en su cache la información que
necesita. También el forwarder permite acceder a la información en caso de estarle negada al
servidor DNS cliente.
9)
Los root-servers son la punta del ovillo en una búsqueda iterativa. Por allí se comienza la búsqueda
para navegar el árbol DNS, cuando se trata de resolver un nombre DNS por Internet.
10)
159
Desde cualquier parte del mundo conectada a Internet, se puede localizar cualquier zona remota
mediante la navegación del árbol DNS posibilitada por las consultas iterativas.
11)
Un resolver realiza una consulta recursiva cuando espera que el servidor a quien consulta le
resuelva totalmente la consulta o le devuelva un código de error en caso contrario. Una consulta
iterativa a un servidor DNS le permite navegar el árbol DNS desde un punto de este, hacia abajo.
Siempre es posible comenzar desde un root-server para acceder a cualquier zona del árbol.
12)
El servicio DNS es estático en el sentido de que los archivos de zona deben actualizarse
manualmente. Dicha tarea está a cargo de personas autorizadas que se conocen como
administradores DNS.
DDNS permita la actualización de las zonas en una forma automática. La actualización la lleva a
cabo la computadora que posee el cliente DNS que debe actualizar su registro en dicha zona. Si
dicha computadora es a su vez cliente DHCP, puede acordar con el servidor DHCP para que sea
este el que lo represente en la actualización en el servidor DNS.
13)
Para la transferencia de datos entre computadoras de la misma administración usa el mecanismo
conocido como Transaction Signatures (TSIG) que consiste en definir una clave secreta que debe
ser compartida entre transmisor y receptor. Existen herramientas que permiten generar las claves.
La distribución de las claves debe realizarse mediante medios extraños a DNSSEC por el
momento.
Para proteger a los datos almacenados y su transferencia a otros servidores con los que no tiene
una relación de confianza, realiza una firma digital a las zonas, para proporcionar autenticación e
integridad mediante criptografía de clave pública.
14)
Consiste en un par de claves privada y pública. Con la clave privada que se debe guardar en un
lugar secreto, se firman digitalmente los registros de recursos de una zona DNS. Con la clave
pública, que se publicita en la misma zona en un registro de tipo KEY, se comprueban las firmas
digitales de los recursos. Dichas firmas digitales también se almacenan en la zona, en registros de
tipo SIG.
15)
Consiste en un par de claves privada y pública. Con la clave privada se firma digitalmente la clave
ZSK y la clave pública KSK se publicita en la zona en un registro de tipo KEY.
También se almacena la clave pública KSK en la zona padre, donde se almacena en un registro de
tipo DS. Si se tiene confianza en la zona padre, se puede confiar en dicho registro DS y de esa
forma se confía en la clave KSK que a su vez permite confirmar la clave ZSK que finalmente
permite confirmar las firmas digitales de todos los registros de recurso de la zona.
Si no se tiene confianza en la zona padre, se debe acceder a una zona de jerarquía superior donde
se tenga confianza y desde allí navegar hacia abajo, estableciendo confianzas temporarias con las
zonas inferiores mediante el procedimiento descrito anteriormente, hasta alcanzar la zona que
contiene el recurso que se desea comprobar. La zona de la cual confiamos su KSK
permanentemente, se denomina punto de acceso a la cadena de confianza.
16)
Para firmar digitalmente una zona debemos disponer en primer lugar la zona DNS convencional y
el par de claves ZSK. El paso siguiente consiste en ejecutar una herramienta como por ejemplo
dnssec, que toma ambos elementos y genera la zona firmada. Dicha zona DNSSEC contiene los
registros de tipo KEY, SIG y NXT como también las claves públicas asociadas a dicha zona.
17)
160
Una rotación de claves ZSK consiste en el cambio de clave ZSK (por razones de seguridad) y los
procedimientos necesarios para mantener vigentes las claves vieja y nueva, de tal manera que los
recursos firmados con cualquiera de las claves permanezcan vigentes durante el tiempo de vida de
dichos recursos.
18)
El servidor “DNS de reenvío / resolver DNSSEC”, permite adquirir datos DNS seguros y
proporcionárselos a los clientes que son resolvers comunes que no trabajan con DNSSEC. En la
figura se muestra la ubicación de dicho servidor.
19)
Un cliente DNS es una computadora que tiene configurado su “resolver” para localizar a un
servidor DNS por defecto.
20)
Configurar a un servidor DNS requiere, además de los siguientes pasos básicos:
• Configurar el protocolo TCP/IP

• Instalar la aplicación del servicio DNS
• Activar el servidor DNS
Se deben realizar las siguientes definiciones mínimas en algún archivo o base de datos de
configuración de la aplicación servidora DNS:
• Activar y verificar el archivo de los Root-Servers

• Crear los archivos de zona directa
• Crear los archivos de zona inversa
• Activar/verificar la posibilidad de búsquedas recursivas e iterativas
• Definir la confianza con los servidores secundarios
• Definir las direcciones IP de los forwarders
• Activar/verificar la opción para notificar a los secundarios de cambios en las zonas
• Activar/verificar la actualización dinámica (opcional)
161
21)
DHCP (Dynamic Host Configuration Protocol) son las siglas que identifican a un protocolo
empleado para que los hosts (clientes) en una red puedan obtener su configuración TCP/IP en
forma dinámica a través de un servidor. Los datos así obtenidos pueden ser: la dirección IP, la
máscara de red, la dirección de broadcast, las características del DNS, entre otros.
22)
Básicamente el servicio DHCP/BOOTP funciona de la siguiente forma. Existe un programa
servidor en un host de la red que escucha las solicitudes de los clientes y que en su configuración
almacena tablas de posibles direcciones IP a otorgar además del resto de la información del
protocolo. Cuando un cliente requiere del servicio envía una solicitud en forma de broadcast a
través de la red.
Todos los servidores alcanzados por la solicitud responden al cliente con sus respectivas
propuestas, este acepta una de ellas haciéndoselo saber al servidor elegido, el cual le otorga la
información requerida. Esta información se mantiene asociada al cliente mientras este no desactive
su interfaz de red (posiblemente porque se apague la máquina) o no expire el plazo del ``contrato''
(lease time).
El plazo del ``contrato'' o concesión es el tiempo en que un cliente DHCP mantiene como propios
los datos que le otorgó un servidor. Este se negocia como parte del protocolo entre el cliente y el
servidor. Una vez vencido el plazo del contrato el servidor puede renovar la información del
cliente, fundamentalmente su dirección IP, y asignarle otra nueva o extender el plazo, manteniendo
la misma información. El cliente puede solicitar también la renovación o liberación de sus datos. Si
el cliente no renueva a término, la dirección IP asignada será liberada y podrá ser asignada a otro
cliente DHCP.
23)
Un ámbito es un conjunto de definiciones de configuración, donde fundamentalmente se define el
intervalo consecutivo de direcciones IP de una red o rango de direcciones. Normalmente los
ámbitos se asocian a una subred física de la red a la que se ofrecen los servicios DHCP. Los
ámbitos proporcionan el medio principal para que el servidor administre la distribución y
asignación de direcciones IP, así como los parámetros de configuración relacionados, a los clientes
de la red.
24)
El computador Agente relé DHCP es un intermediario con protocolo Bootstrap (BOOTP) que re-
transmite mensajes en Protocolo DHCP entre los clientes DHCP y los servidores DHCP ubicados
en distintas redes IP. De esta forma es posible que clientes DHCP emitan su solicitud por difusión
y esta sea retransmitida a otra red mediante el agente de distribución (rele), para alcanzar
finalmente al servidor DHCP. En los segmentos de red IP que contienen clientes DHCP, se
requiere un servidor DHCP o un equipo que funcione como Agente relé DHCP. Normalmente se
configura el agente de distribución DHCP en los ruteadores que comunican las redes con clientes
DHCP.
25)
Se recomienda la siguiente implementación de agente relé en una red DHCP enrutada. Utiliza dos
servidores DHCP que están conectados a dos subredes diferentes.
162
26)
Las opciones de configuración DHCP básicas son las siguientes:
• Dirección de subred
• Máscara de subred
• Dirección IP del ruteador por defecto
• Dirección IP del servidor DNS por defecto
• Nombre del dominio
• Tiempo de concesión
27)
El cliente DHCP puede actualizar dinámicamente a un servidor DDNS (DNS Dinámico) o puede
negociar con el servidor DHCP para que sea este el que registre dinámicamente al cliente en
servidor DDNS.
28)
Las principales características del protocolo HTTP son:
• Toda la comunicación entre los clientes y servidores se realiza a partir de caracteres de 8

bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc.,
respetando su formato original.
• Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado
está identificado por su clasificación MIME.
• Existen tres verbos básicos (hay más, pero por lo general no se utilizan) que un cliente
puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para
enviar información al servidor y HEAD, para solicitar las características de un objeto (por
ejemplo, la fecha de modificación de un documento HTML).
• Cada operación HTTP implica una conexión con el servidor, que es liberada al término de
la misma. Es decir, en una operación se puede recoger un único objeto.
163
• No mantiene estado. Cada petición de un cliente a un servidor no es influida por las

transacciones anteriores. El servidor trata cada petición como una operación totalmente
independiente del resto.
• Cada objeto al que se aplican los verbos del protocolo está identificado a través de un
puntero conocido como URL.
29)
Un URL es un puntero que selecciona un objeto del servidor HTTP sobre el cual se requiere una
operación.
Ejemplo de URL:
30)
En la misma conexión TCP se pueden enviar varios objetos entre el servidor y el cliente. Es la
situación por defecto en la versión HTTP/1.1. Mediante una conexión se transfieren todos los
objetos de la página.
31)
Son un conjunto de variables que se incluyen en los mensajes HTTP, para modificar su
comportamiento o incluir información de interés. En función de su nombre, pueden aparecer en los
requerimientos de un cliente, en las respuestas del servidor o en ambos tipos de mensajes. El
formato general de una cabecera es:
Nombre de la variable : Cadena ASCII con su valor

32)
Las cookies son pequeños archivos de texto que se intercambian los clientes y servidores HTPP,
para solucionar una de las principales “deficiencias” del protocolo: la falta de información de
estado entre dos transacciones. Recuerde que HTTP es un protocolo sin estados.
33)
La primera vez que un usuario accede a un determinado documento de un servidor, éste
proporciona una cookie que contiene datos que relacionarán posteriores operaciones. El cliente
almacena la cookie en su sistema para usarla después en forma automática, transparente al usuario.
En los futuros accesos a este servidor, el browser podrá proporcionar la cookie original, que servirá
de nexo entre este acceso y los anteriores. Todo este proceso se realiza automáticamente, sin
intervención del usuario.
34)
Es posible mantener u hospedar varios sitios en un mismo servidor. Estos sitios se pueden
diferenciar ya sea por tener varias direcciones IP y/o tener diferentes nombres de dominio DNS.
35)
Es posible definir cualquier directorio ya se del mismo servidor o de otra computadora como sub-
directorio del directorio raíz del sitio. Es similar a definir una carpeta compartida. Se deberá definir
el “alias” o sea el path con que se lo ubica desde la red (por ejemplo /profesores, donde / es el
directorio raíz del sitio). También se debe definir el path real del directorio en el sistema de
archivos. Y por último las protecciones y propiedades del directorio.
36)
164
• Carga de módulos complementarios del servidor HTTP para realizar funciones de

extensión
• Número máximo de clientes simultáneos
• Conexión persistente o no persistente
• Protecciones de ciertos directorios del sistema de archivo
• Dirección IP y puerto donde se instala el servicio por defecto.
• Definición de tipos de archivo MIME
• Dirección de correo del administrador
• Usuario y grupo que otorga los privilegios de acceso a los usuarios anónimos (son los
usuarios que no se identifican como usuarios que disponen una cuenta en el servidor, o sea
la gran mayoría de usuarios que diariamente acceden a las páginas del sitio)
• Directorio raíz del sitio por defecto
• Documento por defecto del sitio por defecto
37)
Este servicio pertenece a la familia de servicios esenciales de Internet y se usa para la transferencia
de archivos fundamentalmente.
Trabaja como todos los servicios TCP/IP bajo el modelo cliente/servidor. Normalmente todos los
sistemas operativos poseen un cliente FTP para bajar o subir archivos hacia el servidor FTP. Este
protocolo es universal como todos los servicios esenciales TCP/IP y por lo tanto su funcionalidad
no varía con el sistema operativo que lo contiene. Debido a su naturaleza interactiva mediante
comandos, se trata en dos partes: FTP cliente y FTP servidor.
38)
Como otros servicios permite la conexión de dos tipos de usuarios: usuarios locales con cuentas en
el servidor y el usuario anonymous o usuario anónimo.
39)
El acceso anónimo significa que dicho usuario accede con privilegios otorgados por una cuenta
pre-establecida del sistema operativo.
40)
El acceso anónimo es más seguro ya que evita el envío de contraseñas de usuarios privilegiados,
por la red, el acceso es más restringido, se controla una sola cuenta.
41)
Las conexiones básicas son:
Conexión de control: La ruta de comunicación entre el USER-PI (intérprete de protocolo del
usuario) y el SERVER-PI (intérprete de protocolo del servidor) para el intercambio de órdenes y
respuestas. Esta conexión sigue el Protocolo Telnet para el diálogo. Se define un puerto por
defecto para el servidor. Normalmente es el puerto 21.
Conexión de datos: Una conexión bidireccional sobre la que se transfieren los datos en un modo y
tipo especificados. Los datos transferidos pueden ser una parte de un archivo, un archivo entero o
un cierto número de archivos. La conexión se puede establecer entre un server-DTP (proceso de
transferencia de datos del servidor) y un user-DTP (proceso de transferencia de datos del usuario)
o entre dos server-DTP's. Se define un puerto por defecto para el servidor. Normalmente es el
puerto 20.
42)
Los procesos del servidor son Server-PI y Server-DTP. En el cliente son Interfaz de usuario, User-
PI y User-DTP, como se muestra en la figura.
165
43)
Se definen los siguientes modos de transferencia de datos en el protocolo FTP:
Modo flujo: Los datos se transmiten como un flujo de bytes. No hay ninguna restricción en el tipo
de representación usado; se permiten estructuras de registro.
Modo bloque: El archivo se transmite como una serie de bloques de datos precedidos por uno o
más bytes cabecera.
Modo comprimido: Hay tres clases de información a enviar: datos normales, enviados en una
cadena de bytes; datos comprimidos, formados por repeticiones o relleno; e información de
control, enviada en una secuencia de escape de dos bytes.
44)
• Cambia el directorio de trabajo en el equipo remoto: cd directorioRemoto

• Cambia el directorio de trabajo del equipo local. De forma predeterminada, el
directorio de trabajo es en el que se ha iniciado ftp. : lcd [directorio].
• Muestra una lista resumida de los archivos y subdirectorios de un directorio remoto:
ls [directorioRemoto].
• Copia archivos locales en el equipo remoto utilizando el tipo actual de transferencia
de archivos: mput archivosLocales [ ...].
• Establece la conexión con el servidor de FTP especificado: open equipo [puerto]
• Muestra el directorio actual del equipo remoto: pwd
• Baja un archivo desde el servidor hacia el directorio local: get archivo
45)
• Dirección IP: Define la dirección IP donde se instala el servicio

• Puerto TCP: Determina el puerto que está utilizando el servicio. El puerto predeterminado
es el 21. Puede cambiarlo por cualquier número exclusivo de puerto TCP; no obstante, los
clientes deben saberlo de antemano para pedir ese número de puerto o, de lo contrario, no
conseguirán conectarse al servidor.
• Numero máximo de usuarios: Cantidad máxima de usuarios que pueden conectarse
simultáneamente.
166
• Tiempo de espera de la conexión: Establece el intervalo de tiempo que va a esperar el

servidor antes de desconectar a un usuario inactivo. De esta forma se asegura que todas las
conexiones se cierren si el protocolo HTTP no puede cerrar una conexión.
• Habilitar registro: Activa el registro del sitio FTP, que puede registrar detalles acerca de
la actividad de los usuarios y crear registros en varios formatos
• Cuentas de seguridad: controla quién puede utilizar el servidor y especificar la cuenta
empleada para que los clientes anónimos inicien una sesión en el equipo.
• Mensaje de bienvenida: Contenido del texto que se muestra a los clientes cuando se
conectan al servidor FTP. De manera predeterminada, este mensaje está en blanco.
• Mensaje de salida: Presenta este texto a los clientes cuando se desconectan del servidor
FTP. De manera predeterminada, este mensaje está en blanco.
• Mensaje de conexiones máximas: Presenta este texto a los clientes que intentan
conectarse cuando el servicio FTP ya tiene el número máximo permitido de conexiones de
clientes. De manera predeterminada, este mensaje está en blanco.
• Directorio raíz del sitio FTP: Se indica el path del directorio raíz del sitio, que es una raíz
virtual para el usuario anonymous. El usuario anonymous no podrá acceder a un directorio
en el sistema de archivos del servidor que se encuentre por encima de este directorio.
• Protecciones de los directorios del sitio: se indican las protecciones que se aplican a todos
los usuarios que acceden al sitio FTP
• Definición de sitios virtuales: Solo son posibles otros sitios si se les asigna distintas
direcciones IP. En este protocolo no existe el Host header como en HTTP
• Definición de directorios virtuales: Se especifican mediante el alias, path y protecciones.
Habilitar la carga de archivos hacia el servidor para el usuario anonymous: Es necesario

indicar en forma explícita la habilitación para que el usuario anonymous pueda subir archivos al
servidor.
46)
MTAs (Mail Transport Agent) o agentes para la trasmisión de correo: son aquellos programas
servidores que permiten transportar el correo electrónico de una máquina a otra a través de la red.
Como ejemplos de MTAs se pueden citar a Sendmail, Qmail, Postfix, Exchange Server y otros.
Todos hablan el mismo idioma, o sea utilizan un protocolo común para la comunicación: el SMTP
(Simple Mail Transfer Protocol).
Las funciones básicas de protocolo SMTP son las siguientes:
• Acepta un mensaje entrante en un puerto por defecto (normalmente el puerto 25).
• Comprueba las direcciones del mensaje.
• Si son direcciones locales, almacena el mensaje local para después recuperarlo.
• Si son direcciones remotas, envía el mensaje remoto.
Por tanto, los servidores SMTP son funcionalmente similares a los routers de paquetes.
MDA's (Mail Delivery Agent) o Agentes de Distribución de Correo: que se encargan de mover
el correo dentro de un sistema, es decir, desde un MTA al buzón local MUAs (Mail User Agents)
que son los programas clientes que posibilitan a los usuarios manipular su mensajería. Estos
programas son ejecutados directamente por los usuarios. Proveen facilidades para escribir los
mensajes, enviarlos, descargar y leer los que llegan, organizarlos en directorios, hacer búsquedas,
imprimirlos, mantener un libro de direcciones electrónicas, etc. de un usuario, o del buzón hacia un
MUA mediante POP3 o IMAP.
MUAs (Mail User Agents) o agente de correo del usuario: que son los programas clientes que
posibilitan a los usuarios manipular su mensajería. Estos programas son ejecutados directamente
por los usuarios. Proveen facilidades para escribir los mensajes, enviarlos, descargar y leer los que
167
llegan, organizarlos en directorios, hacer búsquedas, imprimirlos, mantener un libro de direcciones

electrónicas, etc.
47)
48)
Básicamente un mensaje se divide en tres partes:
• Encabezado ("Header")
• Cuerpo del mensaje
• Archivos adjuntos ("Attachment")
49)
HELO eafit.edu.ar
MAIL FROM: usuario@eafit.edu.ar
RCPT TO: userst@dominio.subdominio (especifica el destino)
DATA
bla, bla, bla, ...
.
50)
1. Limitar el número de conexiones entrantes
2. Control de acceso de conexiones entrante en el puerto 25
3. Restricciones de retransmisión (Relay)
4. Seguridad saliente para establecer conexión con otros servidores
5. Nombre de dominios que son locales para este servidor
6. Host inteligente (“smart host”)
7. Servidores SMTP de reenvío para mensajes de dominios remotos
8. Ruteo
• Al host inteligente
168
• Al servidor SMTP que se obtiene de la tabla de servidores de reenvío de dominios

remotos
• Al servidor SMTP que se obtiene de la consulta DNS por el tipo MX que
corresponde al dominio remoto dominio.com.
• A un mailbox local
51)
El Protocolo de Acceso a Mensajes de Internet, versión 4rev1 (IMAP4rev1) permite a un cliente
acceder y manipular los mensajes de correo electrónico contenidos en un servidor que actúa como
Agente de Distribución de Mensajes (MDA). IMAP4rev1 nos permite manipular los archivos
contenedores de mensajes, llamadas comúnmente "buzones", con una funcionalidad equivalente a
la que obtenemos con los contenedores de mensajes locales.
52)
IMAP4rev1 permite realizar operaciones para crear, borrar, y renombrar buzones; comprobación
de nuevos mensajes; lectura del contenido; borrado permanente de mensajes; establecimiento y
borrado de banderas; búsqueda genérica; y recuperación selectiva de atributos de mensaje, textos,
y porciones de texto.
53)
El cliente inicia la conexión y se relaciona con el servidor mediante comandos. El comando de
cliente da comienzo a una operación. A cada comando de cliente se le asigna un prefijo consistente
en un identificador (normalmente una cadena corta de caracteres alfanuméricos, p.ej. A0001,
A0002, etc.) llamado "etiqueta". El cliente asigna a cada comando una etiqueta diferente. Los
argumentos del comando requieren una realimentación por parte del servidor. El servidor envía
una respuesta de solicitud de continuación del comando si este está preparado para recibir los
octetos (si es lo adecuado) y el recordatorio del comando.
54)
Además de ser capaz de recuperar todo el texto de un mensaje, IMAP4rev1 permite la
recuperación de fragmentos del texto completo del mensaje. En concreto, es posible leer la
cabecera del mensaje, el cuerpo del mensaje o una sección del cuerpo.
55)
Además del texto del mensaje, cada uno de los mensajes posee una serie de atributos. Estos
atributos se pueden recuperar individualmente o en conjunción con otros atributos o textos del
mensaje. Como ejemplo tenemos:
• Tamaño del mensaje
• Fecha y hora de recepción
• Número de secuencia
56)
Una conexión IMAP4rev1 puede encontrarse en cuatro estados. La mayoría de los comandos son
válidos únicamente en ciertos estados. Es un error de protocolo de parte del cliente intentar
ejecutar un comando mientras este no se encuentra en el estado apropiado. Los comandos se
organizan en función del estado en el cual está permitida su ejecución. Existen comandos que
puedan utilizarse en varios estados.
57)
1. Comando LOGIN: identifica el cliente al servidor y se hace cargo de la clave en
texto plano autentificando al usuario.
2. Comando SELECT: selecciona un buzón de correo para que en un futuro se pueda
tener acceso a los mensajes que este contiene.
3. Comando CREATE: crea un buzón de correo con el nombre especificado.
4. Comando DELETE: borra el buzón de correo que posea el nombre especificado.
169
58)
El objetivo del POP3 es obtener correo electrónico del buzón remoto y almacenarlo en la maquina
local del usuario para su lectura posterior. Se emplea principalmente en conexiones con MODEM
en las que el tiempo de conexión cuesta dinero. Es un protocolo mucho más simple que IMAP.
Inicialmente, el equipo servidor inicia el servicio POP3 escuchando el puerto TCP 110. Cuando un
equipo cliente quiere hacer uso del servicio, establece una conexión TCP con el equipo servidor.
Cuando la conexión se ha establecido, el servidor POP3 envía un saludo. El cliente y el servidor
POP3 a partir de entonces intercambian órdenes y respuestas (respectivamente) hasta que se cierre
o interrumpa la conexión.
59)
Una sesión POP3 pasa por varios estados durante su periodo de vida. Una vez abierta la conexión
TCP y tras enviar el servidor POP3 el saludo, la sesión entra en la fase de AUTORIZACIÓN. En
esta fase, el cliente debe identificarse ante el servidor POP3.
Una vez que el cliente lo realiza con éxito, el servidor adquiere los recursos asociados con el buzón
del cliente, y la sesión entra en la fase de TRANSACCIÓN. En esta fase, el cliente solicita la
actuación al servidor POP3.
Tras el envío por el cliente de la orden QUIT, la sesión entra en la fase de ACTUALIZACIÓN.
En esta fase, el servidor POP3 libera cualquier recurso adquirido durante la fase de
TRANSACCIÓN, y dice adiós. En ese momento se cierra la conexión TCP.
60)
1. Abrir conexión en el puerto 110
2. USER nombre (indicar el nombre de una cuenta de correo)
3. PASS password (indicar la contraseña de la cuenta)
4. STAT (pide el resumen del mailbox)
5. LIST (pide el listado de los mensajes)
6. RETR 1 (solicita el mensaje 1)
7. DELE 1 (marca al mensaje 1 como eliminado)
8. QUIT (cierra la sesión)
9. Cierre de la conexión
61)
Este protocolo, especifica un mecanismo para codificar texto y datos binarios dentro de los límites
del desarrollo de correo electrónico. Pero también es adoptado por otros servicios que trabajan con
contenido multimedial como el protocolo HTTP.
62)
Permite incluir en un mismo mensaje, los siguientes tipos de contenido:
• Mensajes en idiomas con acentos (por ejemplo español, francés y alemán).
• Mensajes en idiomas sin alfabetos (por ejemplo, chino y japonés).
• Mensajes que no contienen texto (por ejemplo, imágenes, audio y video).
• Mensajes combinados de los anteriores (por ejemplo texto, una foto y una canción).
63)
La especificación MIME define 5 campos en la cabecera del mensaje. Estos campos permiten
definir un formato que posibilita la mezcla de contenidos. Especialmente se define un delimitador
para separar contenidos.
64)
En MIME aparece la idea de mandar un mensaje compuesto por múltiples partes, y cada una de
ellas a su vez de múltiples partes. Aparece por tanto una estructura recursiva que permite la
generación de combinaciones complejas de varias partes.
65)
170
66)
67)
68)
El principal objetivo es permitir un método estándar para comunicar entre sí terminales y procesos
orientados a Terminal (interactivos). Está previsto que el protocolo se pueda usar también para
comunicaciones terminal-terminal ("enlace") y comunicaciones proceso-proceso (computación
distribuida).
69)
Un NVT es un dispositivo imaginario que proporciona una representación normalizada intermedia
de un terminal real. Esto elimina la necesidad para los computadores "servidor" y "usuario" de
guardar información de las características del terminal del otro y de las convenciones para
manejarlo. Ambos mapean (relacionan) las características del dispositivo local para que a través de
la red parezca un NVT y ambos pueden asumir un mapeado similar en el otro extremo.
El computador "usuario" es aquel al que el terminal físico está normalmente conectado y el
computador "servidor" es el que normalmente proporciona algún servicio. Desde otro punto de
vista, aplicable incluso en comunicaciones terminal-terminal o proceso-proceso, el computador
"usuario" es aquel que inicia la comunicación donde se encuentra el usuario que interactúa con el
servidor.
70)
Mediante Telnet es posible crear una sesión de Terminal en un servidor desde un host cliente de tal
manera que se pueda acceder al intérprete de comandos como es la práctica habitual en UNIX o
Linux. En otras palabras, un “usuario” accede a los servicios de un intérprete de comandos. En la
figura siguiente se representa esta situación.
71)
Hay gran cantidad de motivos por los cuales un administrador necesita monitorizar entre otros:
• La utilización del ancho de banda

• El estado de funcionamiento de los enlaces
• La detección de cuellos de botella
• Solucionar problemas en el cableado
• Administrar la información de encaminamiento entre máquinas
72)
171
1. Gestión de rendimiento: tiene por objetivo mejorar el rendimiento de la red

mediante la optimización de los dispositivos y su accionar. Por ejemplo interactuar
sobre una tabla de ruteo para optimizar el tráfico de paquetes.
2. Gestión de fallos: trata sobre la gestión de dispositivos para reaccionar frente a
fallos producidos.
3. Gestión de configuración: Permite la configuración remota de dispositivos.
4. Gestión de cuentas: Gestiona la admisión y restricción acceso a usuarios de la red.
5. Gestión de seguridad: gestiona métodos y definiciones de seguridad como gestión
de claves, control de acceso a los recursos, etc.
73)
Entidad gestora: es una aplicación con control humano que supervisa y controla el desempeño de
los dispositivos que con su comportamiento modifican el comportamiento de la red.
Dispositivo gestionado: Son los dispositivos de red sensibles a la gestión centralizada por el
gestor.
Base de datos de la información gestionada: Se entiende por información gestionada, aquella
que indica o mide el comportamiento de los dispositivos monitorizados y controla los dispositivos
comandados en forma remota.
Agente de gestión: es un proceso que se ejecuta en un dispositivo gestionado, para relacionarlo
interactivamente con el gestor remoto.
Protocolo de gestión: es el que posibilita el diálogo entre el gestor y el dispositivo gestionado.
74)
Los objetos de gestión de red, también conocidos como objetos MIB se guardan en una base de
datos, conocida como base de información de gestión (MIB).
Cada objeto contiene información de distinto tipo que permite medir o conocer el estado de un
dispositivo como también actuar sobre él para ejercer el control remoto.
SMI a través de ASN.1, define un esquema jerárquico de nombres de “objetos de información”
que se representan mediante un árbol que comienza en su máximo nivel con el nodo ”.” llamado
“root”, y por debajo de él otros sub-árboles. Aquellos objetos que no contengan a otros objetos se
definen como objetos “hojas”. Estos objetos hojas son en realidad los objetos administrables.
75)
El lenguaje de definición de datos, conocido como SMI o estructura de información de gestión
(Structure of Management Information), es el lenguaje que define los tipos de datos, un modelo
de objetos, y reglas para representar la información de gestión. SMI define el formato de los
datos que se intercambian el gestor y los gestionados. También podemos decir que SMI define el
formato de los objetos administrables MIB. SMI se complementa con otro estándar de definición
de datos como lo es ASN.1.
76)
El protocolo SNMP permite el intercambio de datos y comandos entre el sistema gestor y los
dispositivos gestionados en una red de computadoras. Es el que define el diálogo entre el gestor
SNMP y los agentes SNMP.
77)
ASN.1 (Abstract Syntax Notation number One) es un estándar internacional que tiene como
objetivo especificar los datos usados en protocolos de las telecomunicaciones. Es un lenguaje
computacional de gran alcance y complejo: fue diseñado para modelar eficientemente la
comunicación entre los sistemas heterogéneos. La Notación de Sintaxis Abstracta Uno (ASN.1) es
una notación que se utiliza para describir los mensajes que se intercambian entre si los programas
de aplicación. Proporciona una descripción del alto nivel que libera a los diseñadores de
protocolos de tener que centrarse en los detalles de los bits y bytes del mensaje. También define el
172
esquema jerárquico de nombres adoptado por SMI. Podemos decir que cumple la función de la
capa de presentación del modelo OSI para una gestión SNMP.
173

Unidad 6.unlocked PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 6.unlocked PDF

Cargado por

Copyright:

Formatos disponibles

Unidad 6: Servicios y protocolos de aplicación Informática VI

UNIDAD 6: SERVICIOS Y PROTOCOLOS DE APLICACIÓN

• Reconocer los servicios que prestan las computadoras a programas cliente

El servicio de Correo Electrónico

6.1 El servicio DNS

Servidores DNS e Internet

Servidores de nombres (Servidores DNS)

Formato de los registros de recursos DNS

A continuación se describen algunos registros que son los más comunes.

Registro de tipo AAAA

Descripción: registro de recursos de direcciones de host IPv6 (AAAA). Asigna un nombre de

Registro de tipo ATMA

Descripción: registro de recursos de direcciones en Modo de transferencia asincrónica (ATMA,

Registro tipo CNAME

Descripción: registro de recursos de nombres canónicos (CNAME). Asigna un nombre de

Registro tipo ISDN (RDSI)

Descripción: registro de recursos de la Red digital de servicios integrados, RDSI (ISDN,

Descripción: registro de recursos de buzón (MB). Asocia el nombre de buzón de dominio,

Descripción: se usa para asignar un servidor de nombres DNS a un dominio determinado. El

Registro de tipo PTR

Descripción: registro de recursos de apuntador (PTR). Relaciona una dirección IP en el campo

Tipo de registro SOA

Descripción: Registro de recursos de inicio de autoridad (SOA). Indica el nombre de origen de la

En el ejemplo siguiente, el propietario se especifica como "@" y representa al dominio principal u

@ IN SOA nameserver.pepe.com. postmaster.pepe.com. (

3600 ; refresh [1h]

600 ; retry [10m]

86400 ; expire [1d]

3600 ) ; min TTL [1h]

Registro de tipo X25

Servidores de nombres: primario, secundario y maestro

Tenemos dos tipos de zonas:

• Zonas directas. Permiten obtener la dirección IP en base a un nombre de dominio.

En la siguiente figura vemos un ejemplo de una zona directa.

En la siguiente figura vemos un ejemplo de una zona inversa.

@ IN SOA ns.iua.edu.ar. root.iua.edu.ar. (

Las transferencias de zona incrementales se describen en el documento Solicitud de comentarios

Una transferencia de zona puede darse en cualquiera de los casos siguientes:

• Cuando vence el intervalo de actualización de una zona

• Cuando un servidor maestro notifica los cambios de la zona a un servidor secundario

1. Durante la nueva configuración, el servidor de destino envía una solicitud de transferencia

La zona se entrega al servidor de destino que solicita la transferencia con su versión

3. Cuando el intervalo de actualización vence, el servidor de destino utiliza una consulta de

Esta respuesta contiene el número de serie de la zona en su estado actual en el servidor de

5. El servidor de destino comprueba el número de serie del registro de inicio de autoridad en

Si el valor del número de serie de la respuesta de inicio de autoridad es igual a su número

Si el valor del número de serie de la respuesta de inicio de autoridad es mayor que su

Si el servidor de origen admite la transferencia incremental y mantiene un historial con los

Si el servidor de origen no admite la transferencia incremental o no posee un historial con

Los servidores DNS modernos admiten la notificación DNS; una actualización de la

La notificación DNS implementa un sistema de inserción para notificar a un grupo selecto de

Servidores de reenvío (forwarders) y servidores esclavo

Servidores de almacenamiento temporal (sólo-cacheo)

El almacenamiento en caché aumenta el rendimiento de la resolución DNS para las consultas

Mientras el tiempo de vida de un registro de recursos almacenado en la caché no caduque, un

Obtención del nombre del host dada la dirección IP

Una vez localizado, el servidor DNS con autoridad en "15.16.192.152.in-addr.arpa" puede

Formato del mensaje DNS

El mensaje DNS tiene cinco secciones como se muestra en la figura.

• El header o encabezamiento contiene información tal como tipo de mensaje, y que

HEADER QUESTION ANSWER AUTHORITY ADDITIONAL

• Una respuesta con autoridad

Una respuesta de referencia contiene registros de recursos adicionales no especificados por el