El servicio 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 de forma dinámica a través de un servidor del
protocolo. 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.

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. 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 renta 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.
 Figura: Representación simplificada del protocolo DHCP

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.

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 Linux la implementación del servidor de DHCP y de BOOTP la mantiene la ISC (Internet Software
Consortium). Esta se empaqueta en la distribución Red Hat bajo el nombre dhcp. Existen además otros dos
paquetes asociados a este servicio que implementan la parte cliente: pump y dhcpcd.

En las secciones siguientes se explicará como adecuar una estación de trabajo para que obtenga su configuración
de red a través de DHCP y como instalar y configurar un servidor de DHCP.
Subsecciones

• Configuración del cliente de DHCP

• Configuración del servidor de DHCP
• Referencias

Configuración del cliente de DHCP

La configuración de todas las interfaces de red de un sistema Linux se encuentra en el directorio
/etc/sysconfig/network-scripts/. En este existe un fichero para cada interfaz nombrado de la forma
ifcfg-x, donde x es el nombre de la interfaz. Por ejemplo para la interfaz especial loopback existe ifcfg-lo y
para la primera interfaz de tipo ethernet, el fichero es ifcfg-eth0. El contenido de este último es similar al
siguiente:

DEVICE=eth0 # dispositivo de red asociado

ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.100.4
NETMASK=255.255.255.0
GATEWAY=192.168.100.1
# se activa la interfaz durante el inicio
# la configuración es estática
# la dirección IP asociada a la interfaz
# la máscara de red
# la dirección del gateway

Como puede apreciarse el fichero sólo consta de un conjunto de asignaciones a variables que expresan la
configuración total de la interfaz correspondiente. En este caso para una interfaz de red estática se le asigna a
BOOTPROTO el valor static. Para el caso de que se fuera a emplear DHCP sería dhcp y para BOOTP, bootp. En
ambos casos los valores de IPADDR, NETMASK y GATEWAY serían ignorados, ya que estos se toman a partir del
servidor de los protocolos.
Una vez modificada la configuración se debe reiniciar la interfaz de red. Esto se puede hacer de múltiples
formas. A continuación se muestran dos de ellas suponiendo que se trabaja sobre la interfaz eth0:

1-.
Ejecutando el script /etc/rc.d/init.d/network6.1. Ejemplo:
# service network reload
2-.
Utilizando los comandos ifup e ifdown. Ejemplo:
# ifdown eth0
# ifup eth0

Luego se puede observar el resultado ejecutando el comando ifconfig pasándole como argumento el nombre de
la interfaz.

Para configurar las interfaces de red también se pueden utilizar algunas herramientas que se encargan
transparentemente de modificar los ficheros antes mencionados y en algunos casos de reiniciar la interfaz de red
alterada. Ejemplo de ellas son: netconfig (interfaz texto), netcfg (interfaz gráfica) y netconf (interfaz texto y
gráfica en dependencia del entorno de trabajo).

Como se mencionó anteriormente existen dos clientes de DHCP/BOOTP para Red Hat: pump y dhcpcd. Se
explicará pump que es el utilizado por defecto en el caso de Red Hat 7.1. Aunque puede ser invocado
manualmente, pump es un daemon que normalmente se inicia automáticamente si existe alguna interfaz
configurada para usar DHCP o BOOTP.

Las opciones principales son:

-i <device>
: para especificar la interfaz de red referenciada.
-k
: termina el daemon y deshabilita todas las interfaces asociadas
-r
: libera la interfaz
-R
: fuerza la renovación de la información contratada
-s
: muestra el estado de las interfaces
-l <time>
: especifica en horas el tiempo solicitado por el cliente dado el cual expira el contrato de su información

Ejemplos:

# pump -i eth0 -l 72
# pump -s
Device eth0
IP: 192.168.100.50
Netmask: 255.255.255.0
Broadcast: 192.168.100.255
Network: 192.168.100.0
Boot server 192.168.100.2
Next server 0.0.0.0
Gateway: 0.0.0.0
Renewal time: Fri Apr 6 02:50:05 2001
Expiration time: Fri Apr 6 11:50:05 2001
# pump -r
Configuración del servidor de DHCP
El servidor de DHCP es el daemon dhcpd el cual una vez instalado y configurado se puede manipular con el
script del mismo nombre en el directorio /etc/rc.d/init.d. Ejemplos:

# service dhcpd start

Starting dhcpd: [ OK ]

# service dhcpd status

dhcpd (pid 516) is running...

# service dhcpd reload

Shutting down dhcp [ OK ]
Starting dhcp [ OK ]

La configuración del servicio se hace a través del fichero /etc/dhcpd.conf. En este se designan
fundamentalemente los rangos de direcciones IP a otorgar de acuerdo a las subredes definidas, así como el resto
de los campos que se asignan a través del servicio a los clientes. Una vez iniciado, dhcpd lee este fichero y
almacena en memoria una lista de las direcciones disponibles en cada subred. Cuando un cliente solicita
mediante el protocolo DHCP una dirección, el servidor le hace una propuesta incluyendo en ella el tiempo del
contrato, si el cliente acepta entonces se establecerá el contrato que expirará una vez alcanzado el tiempo
indicado por el administrador en la configuración, y que por defecto es de un día.

Antes de que el contrato expire el cliente tratará de renovarlo para continuar usando la dirección otorgada. Una
vez expire el contrato el cliente no podrá usar más esta información.

Con el objetivo de recordar los contratos establecidos, siempre que reinicie el sistema o se renueve el servicio,
dhcpd almacena estos en forma de base de datos en un fichero nombrado dhcpd.leases y que se guarda en el
directorio /var/lib/dhcp. Siempre que dhcpd vaya a establecer un contrato con un cliente almacena una
entrada en este fichero y se asegura de que esta información sea realmente transferida (flush) al fichero. Esto
permite que aunque el sistema aborte por un motivo u otro, siempre que reinicie dhcpd podrá recordar los
contratos establecidos previamente, lo cual hará después de leer su fichero de configuración.

El fichero de contratos tiene un formato de texto ASCII y contiene todas las declaraciones de los contratos
efectuados. Siempre que un contrato se establezca, se renueve o expire se genera una nueva entrada al final del
fichero. Por tanto si aparece más de una entrada para un mismo contrato se asume como válida la que se
encuentre más cercana al final del fichero. Cuando se instala dhcpd normalmente no existe la base de datos de
contratos, sin embargo esta es imprescindible para que el servicio inicie adecuadamente. Por ello se debe crear el
fichero vacío de esta forma (o de otra):

# touch /var/lib/dhcp/dhcpd.leases

Para prevenir que el fichero de contratos crezca indefinidamente, cada cierto tiempo todos los contratos
conocidos son trasladados hacia otro con el nombre dhcpd.leases~, y entonces se comienzan a almacenar los
nuevos contratos en el fichero principal. Si durante este proceso el sistema y/o el servicio abortan puede que no
se llegue a generar el nuevo fichero principal, en cuyo caso se requerirá de crearlo manualmente para que el
servicio pueda reiniciar correctamente.

El fichero de contratos consta sólo de un tipo de sentencias. Estas tienen la forma:

lease <dirección IP> { <sentencias> }

Las sentencias, que se separan por el caracter ``;'', definen a quien se le asignó el contrato y que tiempo durará
este. A continuación se listan y ejemplifican las sentencias principales:

• starts <fecha>;
• ends <fecha>;
Especifican las fechas de comienzo y final del contrato. Estas fechas poseen el siguiente formato:

W YYYY/MM/DD HH:MM:SS

Donde:

o W - es el día de la semana. Sólo se utiliza para que la fecha sea más comprensible para los
humanos. Se especifica con números entre 0 y 6 donde el 0 se corresponde con el domingo.
o YYYY/MM/DD - es la fecha formada por el año, que se expresa con cuatro dígitos, el mes, que oscila
entre 1 y 12, y el día que lo hace entre 1 y 31.
o HH:MM:SS - representa el tiempo formado por la hora que se moverá en el rango de 0 a 23, y los
minutos y segundos, que lo harán de 0 a 59.

Las fechas se especifican a partir del uso horario de Greenwich (GMT : Greenwich Mean Time) y no del
tiempo local. Para obtener la hora de Greenwich se puede ejecutar $ date -u.
Ejemplos:

starts 1 2001/4/12 10:56:34;

ends 3 2001/4/14 10:56:34;

• hardware <tipo> <dirección MAC>;

Permite indicar la dirección MAC de la interfaz de red del cliente con el que se hizo el contrato. Las
direcciones MAC se expresan utilizando seis números hexadecimales separados por dos puntos. El tipo
de hardware por lo general es ethernet que es la arquitectura de red más común en nuestros contextos.
Ejemplo:

hardware ethernet 00:48:54:8C:90:CA;

• uid <identificador>;
Es otro parámetro que permite identificar al cliente.
Ejemplo:

uid "hada+fn.fwf:m0-r45j9wfn4-2554k5";

• client-hostname <nombre del host>;

Almacena el nombre del host cliente. Se refiere a los nombres del DNS.
Ejemplo:

client-hostname "deltha.disaic.cu";

• hostname <nombre del host>;

Almacena el nombre del host cliente. Se refiere a los nombres NetBios de los ambientes Windows.
Ejemplo:

hostname "gandalf";
 • abandoned;
Esta sentencia se emplea para indicar que una dirección está siendo mal usada debido a que el cliente que
la poseía la abandonó o que el servidor al tratar de reasignar dicha dirección descubrió que estaba siendo
utilizada por un cliente no autorizado. Las direcciones abandonadas son reasignadas cuando ya no
quedan direcciones libres disponibles.

El fichero de configuración de dhcpd, /etc/dhcpd.conf, consta de un conjunto de sentencias. Unas sentencias

pueden contener a otras. Las sentencias se clasifican en parámetros y declaraciones. Los parámetros expresan
como hacer algo, si se hace algo o no, así como los atributos que se le asignan al cliente. Las declaraciones, en
cambio, se emplean para describir la topología de una red, describir a un conjunto de clientes o para aplicar
determinados parámetros a un grupo de declaraciones. Las declaraciones tienen la forma:

<nombre de la declaración> [atributos] {

[parámetros]
[declaraciones]
}

y los parámetros:
[option] <nombre del parámetro> [valores];

Los parámetros que comienzan con la palabra reservada ``option'' describen aquellos datos que brinda el
servidor al cliente como parte del protocolo, y los que no, describen las características del servidor de DHCP.
A continuación se describen las sentencias declarativas:

• shared-network : permite agrupar un conjunto de subredes que compartan la misma red física. El único
atributo de esta sentencia es un nombre que sólo se utiliza para las trazas del servicio.
Sintaxis:
• shared-network <nombre> {
• [parámetros]
• [declaraciones]
• }
• subnet : permite agrupar las características globales que van a tener los clientes de una misma subred.
Sintaxis:
• subnet <dirección de red> netmask <máscara de red> {
• [parámetros]
• [declaraciones]
• }
• range : permite definir un rango de direcciones IP a otorgar a clientes pertenecientes a una subred. Toda
declaración tipo subnet debe tener asociada una declaración range en la cual se especifique las
direcciones IP mínima y máxima. Si se especifica el atributo dynamic-bootp se indica que estas
direcciones se pueden asignar también a clientes BOOTP. Cuando se especifica una sola dirección IP se
omite la dirección máxima.
Sintaxis:
• range [dynamic-bootp] <dirección IP mínima> [dirección IP máxima]

• host : permite describir aquellos hosts que tengan una dirección fija. Todos los clientes que usan
BOOTP deben tener asociada una sentencia host. Un cliente se corresponde con una declaración host si
la opción dhcp-client-identifier indicada en la declaración posee el valor del identificador que
brinda el cliente a través del protocolo. De no ser así entonces se emplearía la dirección MAC del cliente
especificada a través de el atributo hardware.
Sintaxis:
•
• host <hostname> {
 • [parámetros]
• [declaraciones]
• }

• group : permite agrupar a otras declaraciones para aplicarles varios parámetros comunes. Puede ser
utilizada para agrupar hosts, subredes, redes compartidas y otros grupos.
Sintaxis:
• group {
• [parámetros]
• [declaraciones]
• }

Los parámetros principales son:

• lease-file-name <filename>;
Indica el nombre del fichero donde se almacenan los contratos. Este parámetro tiene alcance global por lo
que se debe especificar fuera de todos los ámbitos (declaraciones) para que tenga efecto real. Por defecto
es
/var/lib/dhcp/dhcpd.leases
• default-lease-time <time>;
Expresa el tiempo en segundos por defecto que tendrán los contratos a los clientes que no soliciten un
tiempo específico para la expiración de sus contratos.
• max-lease-time <time>;
Expresa en segundos la duración máxima de un contrato.
• min-lease-time <time>;
Expresa en segundos la duración mínima de un contrato.
• min-seconds <seconds>;
Indica el número de segundos que debe esperar el servidor de DHCP para responder al pedido de los
clientes. Se utiliza cuando se tiene un segundo servidor y se desea que este responda después que el otro
haya hecho su oferta al cliente.
• hardware <type> <address>;
Indica la dirección física (MAC) de un cliente particular (declaraciones tipo host). El atributo type
expresa el tipo de arquitectura de la interfaz de red, actualmente puede ser: ethernet o token-ring. La
dirección MAC se expresa utilizando seis números hexadecimales (números desde 00 hasta ff)
separados por el caracter ``:''.
• server-name <servername>;
Indica el nombre que se ofrecerá a los clientes como identificador del servidor que emplean.
• fixed-address <address> [, <address>];
Expresa las direcciones IP que son fijas para los clientes descritos a través de las declaraciones de tipo
host. Pueden utilizarse nombres de dominio en lugar de números IP.
• dynamic-bootp-lease-cutoff <date>;
Indica la fecha en que expiran los contratos de todos los clientes BOOTP. Como se ha expresado
anteriormente los contratos con este tipo de cliente no expiran nunca ni se renuevan pero puede que en
ciertas situaciones sea necesario interrumpirlos. El formato del atributo date es idéntico al que se emplea
en el fichero de contratos descrito anteriormente.
• get-lease-hostnames <flag>;
Indica si el servidor resolverá o no las direcciones IP de los clientes a nombres de dominio y usará estos
nombres como la opción host-name del protocolo. Si el valor es verdadero entonces la resolución se hará
para todas las direcciones en el mismo alcance (scope). Un valor verdadero se expresa con ``on'',
mientras que falso se indicará con ``off''. Por defecto es falso.
 • use-host-decl-names <flag>;
Indica si se asume que el nombre provisto en cada una de las declaraciones tipo host dentro del mismo
ámbito, es el nombre del cliente correspondiente (opción host-name del protocolo).
• authoritative;
• non authoritative;
Indican si el servidor está autorizado o no para realizar sus funciones. Por defecto un servidor DHCP
asume que la información que brinda a una subred determinada no es correcta ni está autorizado para
ello. Esto permite que si un usuario inexperto instala un servidor de DHCP en la red este no sea
escuchado por los clientes como lo es un servidor legítimo que se le indique explícitamente que está
autorizado. El administrador de red que configure adecuadamente su servidor debe colocar este
parámetro al comienzo del fichero, aunque puede ser conveniente en algunas ocasiones declarar al
servidor autorizado de acuerdo a los segmentos de red definidos y no de forma global.
• always-broadcast <flag>;
Se emplea para algunos clientes de DHCP/BOOTP que no recepcionan las respuestas del servidor si no
son en forma de broadcast. Se debe tratar de colocar este parámetro a ``on'' sólo para los clientes que
realmente lo necesiten pues provoca demasiado tráfico en la red.
• ddns-update <flag>;
Indica si se realizan o no actualizaciones dinámicas al DNS siempre que se establezca un contrato. Por
defecto este parámetro tiene valor ``on''.
• allow <request>;
• deny <request>;
• ignore <request>;
Se emplean para controlar la respuesta del servidor de DHCP ante distintos tipos de pedidos: allow
permite, deny niega e ignore ignora la solicitud. Algunas de las posibles solicitudes (atributo request)
son:
o unknown-clients : se emplea para indicar al servidor si acepta o no las solicitudes de los clientes
desconodidos. Un cliente desconocido es aquel que no tiene asociado una declaración tipo host.
Por defecto las solicitudes de estos clientes se aceptan.
o bootp : se utiliza para señalar si se aceptarán o no los pedidos de los clientes BOOTP. Por defecto
se aceptan.
o booting : se emplea en las declaraciones del tipo host para indicar si se aceptará o negará la
solicitud del host correspondiente. Por defecto se aceptan para todos los hosts.
o declines : se utiliza para indicar si el servidor acepta o no los mensajes del tipo DHCPDECLINE de
los clientes. Cuando un servidor recibe este tipo de mensajes asume que la dirección que ofrece
no es válida pues al parecer alguien no autorizado la está utilizando y entonces la declara como
abandonada. Desafortunadamente un cliente ``malicioso'' o con una implementación incorrecta
puede agotar todo el spool de direcciones a otorgar que posee el servidor y antes de que este
decida emplear las direcciones abandonadas ya se habrán provocado algunos trastornos en el
servicio.

Entre los parámetros que se le pueden otorgar a un cliente a través del protocolo y que van precedidos por la
palabra ``option'', se encuentran:
• option domain-name <domain name>;
Indica el nombre del dominio que empleará el cliente.
• option domain-name-servers <ip address> [, <ip address> ... ];
Indica los servidores de nombres de dominio a emplear por el cliente.
• option host-name <hostname>;
Indica el nombre que empleará el host cliente.
• option subnet-mask <ip address>;
Indica la máscara de red que se le asignará al cliente.
 • option routers <ip address> [, <ip address> ... ];
Indica las direcciones IP de los routers (gateway) que empleará el cliente.
• option broadcast-address <ip address>;
Indica la dirección de broadcast que utilizará el cliente.
• option dhcp-client-identifier <string>;
Indica el identificador que puede emplear el cliente como alternativa a su dirección MAC.
Ejemplo:
authoritative;
option domain-name "disaic.cu";
option domain-name-servers 192.168.100.2, 192.168.200.3;

shared-network disaic {
server-name clio;
default-lease-time 604800; # 7 días
min-lease-time 86400; # 1 día
max-lease-time 864000; # 10 días
option subnet-mask 255.255.255.0;
option routers 192.168.100.1;

subnet 192.168.100.0 netmask 255.255.255.0 {

option broadcast-address 192.168.100.255;
option routers 192.168.100.1;
}

Proceso de resolución de nombres

Para satisfacer las solicitudes de los resolvers los servidores de nombres no solamente retornan información
acerca de las zonas para la que están autorizados, también tienen que hacerlo de aquellas para las que no lo están.
Este proceso se denomina resolución

Gracias a que el espacio de nombres de dominio tiene estructura arbórea sólo es necesario por parte del servidor
de nombres conocer un punto de este árbol: los nombres y los números IP de los servidores de nombre del
dominio raíz (servidores raíces).

De esta forma cualquier servidor de nombres para resolver un nombre determinado (o realizar otro tipo de
consulta) sólo necesitará conocer algún servidor raíz y consultarlo. Este referirá la dirección del servidor del
subdominio correspondiente (dominio de primer nivel), el cual a su vez puede referir a otro servidor y así
sucesivamente se va completando el proceso de resolución que puede concluir exitosamente o no.
 Figura: Proceso de resolución del nombre www.chips.ibm.com

La figura muestra el proceso de resolución del nombre www.chips.ibm.com. En esta se aprecia como el
servidor de nombres interrogado consulta a su vez a todos los servidores autorizados para cada uno de los
dominios que contienen al nombre de dominio en cuestión.

Cachè y tiempo de vida (TTL)

Hasta ahora puede concluirse que los servidores raíces reciben todas las consultas que se realizan cada instante
en Internet. Otros servidores, no necesariamente los del dominio raíz, también pueden estar muy sobrecargados.
Es por ello que las implementaciones del DNS proveen el mecanismo de cachè que no es más que una facilidad
que utilizan los servidores de nombres durante el proceso de resolución con vistas a disminuir el número de
consultas necesarias para obtener una información determinada. Esta facilidad se implementa utilizando un
cachè de las respuestas a las consultas más recientes. Por ejemplo, supongamos que se haya resuelto
recientemente el nombre www.chips.ibm.com, si a continuación se desea consultar cierta información acerca del
nombre www.developers.ibm.com no será necesario interrogar a un servidor raíz para conocer los servidores del
dominio com, ni tampoco a alguno de estos para el dominio ibm, gracias a que ya está ``cacheada'' la dirección
de un servidor del dominio ibm y es a partir de este donde comenzará el proceso de resolución.

Existen servidores de nombres que sólo realizan cachè. Estos no son autoritarios de ninguna zona. Lo único que
hacen es guardar en su cachè las respuestas que le dan otros servidores cada vez que son consultados.

Los servidores de nombres no deben almacenar en sus cachès la información a la que acceden por un tiempo
indefinido, pues entonces sería imposible la actualización de esta una vez sea cambiada en los servidores
autorizados para ello. Es por eso que a cada dato de un dominio se le asocia por parte de su administrador un
tiempo de vida o TTL (Time To Live), dado el cual cualquier servidor que lo tenga almacenado en su cachè debe
volver a interrogar al servidor autorizado de la zona a la que pertenece el dato.
Para decidir el tiempo de vida de cada dato en un dominio hay que establecer que importa más: la consistencia o
el rendimiento. Un TTL pequeño permitirá que la información sea consistente casi siempre, pues los datos
expirarán rápidamente obligando a descargarlos del cachè y a obtener los nuevos valores de los servidores
autorizados. En cambio producirá un mayor número de consultas a través de la red y esto empeorará el
rendimiento del servidor y extenderá a su vez el tiempo promedio de resolución. La situación inversa, un TTL
grande, mejorará el desenvolvimiento de los servidores y acortará el tiempo del proceso de resolución, pero
puede provocar que la información se mantenga inconsistente durante mucho tiempo.

Como dato curioso se puede decir que el servidor del dominio raíz operado por la ISC (Internet Software
Consortium), f.root-servers.net responde más de 272 millones de consultas por día. De hecho es el servidor de
DNS más cosultado en Internet. Opera a través de dos procesadores Compaq ES40 AlphaServer a 4500MHz y
con 8GB de RAM. El software empleado es el ISC BIND 8.2.3.

Estructura de la base de datos del DNS

A cada nombre de dominio en el DNS se le pueden asociar varias informaciones. Para los nombres de dominio
asociados a un host, la principal información es su número IP, pero también se le pueden hacer corresponder
varios alias, indicar una descripción de la máquina (procesador y sistema operativo), etc. Para todos los nombres
de dominio, estén o no asociados a un host, se puede especificar el redireccionamiento del correo dirigido a estos
hacia un determinado sistema conocido como Mail Exchanger.

Todos estos tipos de datos se conocen como Resource Records (RR) y se asocian a los nombres de dominios.
Los records se dividen en clases. Cada clase representa un tipo de red o software. Actualmente hay clases para
internets (cualquier red basada en TCP/IP), redes basadas en el protocolo Chaosnet y redes que usan el programa
Hesiod. De ellas la más popular y de hecho la única que usaremos en nuestros contextos, es la clase internet.

Los records también pueden ser de varios tipos en correspondencia con la información que almacenan, tal y
como se ejemplificó anteriormente.

Traducción de direcciones a nombres

El proceso de resolución en el DNS no sólo permite traducir nombres a direcciones IP, también se puede hacer el
proceso inverso, o sea dado un número IP determinar el nombre principal asociado a esta. Esta facilidad permite
que los programas puedan producir su salida en un formato más humano, por ejemplo el subsistema de trazas en
lugar de colocar los números IP de las máquinas en las salidas que genera puede utilizar sus nombres. Este tipo
de traducción también permite hacer ciertos chequeos de autorización por parte de algunos servidores (Web, FTP
y otros) que en dependencia de ello dan determinadas facilidades de acceso.

Si se utilizan tablas de hosts (fichero /etc/hosts en Linux) la traducción de direcciones a nombres es trivial
pero, de acuerdo a como hemos visto que se estructura el DNS hasta el momento, dicha traducción se vuelve
imposible debido a que es necesario explorar todo el espacio de nombres para encontrar un número IP
determinado y su nombre equivalente. Es por ello que se le adiciona una parte especial al espacio de nombres de
dominio. En esta parte conocida como dominio in-addr.arpa se utilizan las direcciones en lugar de los nombres
para identificar los dominios. Las direcciones o números IP se expresan en el formato de cuatro números entre 0
y 255 separados por puntos. En la figura se representa la forma de este dominio especial donde se encuentran
todas las posibles direcciones IP y sus equivalentes en nombres. En este caso se ejemplifica con un host
hipotético de nombre www.linux.disaic.cu con dirección IP 30.60.120.240.

Rápidamente se pueden apreciar una diferencia fundamental entre el espacio de nombres de dominios y el
dominio especial arpa, pues en arpa los nombres de dominio completos se expresan de forma invertida a como
se hace en las direcciones IP. Para el caso hipotético anterior el nombre de dominio arpa del host sería
240.120.60.30.arpa.in-addr. Debido a esto se puede apreciar que aunque ambas estructuras son jerárquicas las
direcciones IP siempre son más específicas de izquierda a derecha, mientras que los nombres de dominio lo son
de derecha a izquierda (ver figura ).

Hacer que el primer número de las direcciones IP aparezca primero en la jerarquía permite la delegación de la
autoridad de los dominios arpa. Por ejemplo el dominio 60.30.in-addr.arpa contendría toda la información
acerca de los hosts cuyas direcciones IP comiencen con 30.60 y en consencuencia este podría ser delegado al
administrador de la red 30.60. Si fuera al revés, o sea que el dominio 60.30.in-addr.arpa contuviera a las
direcciones que terminen en 60.30 no sería posible la delegación de la administración de este dominio.

Figura: Proceso de resolución del número IP 30.60.120.240 al nombre www.linux.disaic.cu

Figura: Diferencias en la especificidad de los nombres y las direcciones IP