El transporte y rutado de paquetes en Internet se realiza manejando las direcciones IP, tal y como se indica en este protocolo (IP=Internet Protocol). Es un sistema muy eficiente y claro, pero muy poco adaptado a las entendederas humanas. DNS (Domain Name System) es un sistema de correspondencias entre cadenas de caracteres inteligibles por los humanos, o "nombres", y las direcciones IP de las máquinas.
El sistema refleja, en parte, la organización que siguen las direcciones IP que usan las máquinas, con algunas diferencias. En primer lugar una máquina suele tener asignado un sólo nombre aunque posea varias direcciones IP (ver artículo de routers) y por otra parte DNS es independiente de IP en el sentido de que es un servicio más que ofrece la máquina y que supone que el rutado de paquetes entre máquinas ya es completamente funcional. Estrictamente se podría prescindir por completo de DNS cuya misión consiste en obtener la direccion IP de una máquina a partir de su nombre (y "apellidos" o dominio).
La jerarquía de nombres sigue de cerca la de subredes. En este caso se habla de subdominios. Es muy habitual, aunque no obligatorio, que cada subdominio se corresponda con una subred. La denominación completa de una máquina sigue un convenio de "puntos" muy conocido a estas alturas (¿Quíen no ha visto ya alguna direccion de Internet en anuncios o revistas?):
[maquina].[subdominio].[dominio]
dónde [dominio]
puede estar compuesto de subdominio y dominio recursivamente (es sólo una cuestión de nomenclatura). Está claro que una máquina sí puede tener varios nombres, en concreto un servidor puede tener un nombre "oficial" y otro (empezando por www
o ftp
) para dar distintos servicios. La madre de todos los dominios se denomina "root" y se designa mediante un punto. Los principales dominios que cuelgan del raiz son ampliamente conocidos: edu,com,org,mil,
etc, huelga comentarlos aquí.
Es obvio que, como mínimo cada máquina debe conocer su propio nombre, que se suele elegir en el proceso de instalación. Este nombre debe estar en el archivo /etc/hostname
. La máquina conoce su dominio de una manera un poco más complicada (ver más adelante).
La petición de un servicio a otra máquina implica conocer la dirección IP del servidor en cuestión. Los programas (netscape, ftp, rlogin, etc) consiguen la dirección a partir del nombre mediante las llamadas gethostbyname(3)
y gethostbyaddr(3)
. Estas funciones implementan el "name resolver" que funciona en cualquier instalación, aunque sea local. El proceso que sigue el resolver para obtener la dirección depende de como esté configurado mediante los archivos /etc/resolv.conf
y /etc/host.conf
. En el primero se indican los dominios y servidores sobre los que realizar las búsquedas con las sentencias:
nameserver [direccion-IP]
search [subdominio1] [subdominio2] ...
rlogin atlante.ieeesb.etsit.upm.es
sino que hace rlogin atlante
desde una máquina que pertenece al dominio ieeesb.etsit.upm.es
o rlogin ieeesb.etsit
desde una máquina en el dominio upm.es
). La entrada domain indica al traductor de nombres qué dominios debe añadir al nombre de la máquina en estos casos. La búsqueda se realizará agregando al final del nombre cada uno de los elementos de la lista de dominios que se indican, por el orden en el que aparecen.
domain [mi_subdominio]
gethostname(2)
, buscando la cadena de caracteres que sigue al primer punto (por esta razón no es buena idea bautizar una máquina con un nombre que contenga puntos, a menos que se especifique aquí claramente cual es el domino al que pertenece). Si no hay comando search
cualquier búsqueda sobre el nombre de una máquina se realizará en primer lugar en el mismo dominio al que pertenece. Si existe un search
sólo se buscará en la lista de dominios que aparecen en la misma, es decir, aunque aparezca nuestro subdominio en domain
es necesario repetirlo en search
para que se efectúen las búsquedas dentro del mismo.
/etc/host.conf
se describe el comportamiento del algoritmo de resolución de nombres. En este caso los comandos más usados son:
order [method], [method], ...
hosts
-- Buscar en el archivo /etc/hosts.
bind
-- Buscar en los servidores de nombres que se indican en /etc/resolv.conf
nis
-- Buscar en la base de datos NIS (Network Information System, más conocida por "páginas amarillas", ver más adelante)
multi [on/off]
Con todo esto ya es posible configurar un sistema de resolución de nombres local. Supongamos que tenemos una red cuyo subdominio es ieeesb.etsit.upm.es
que posee dos máquinas llamadas atlante
y febe
y que la dirección de un servidor de nombres accesible es 138.100.17.10
.
Para que DNS funcione basta con tener un /etc/resolv.conf
como:
domain ieeesb.etsit.upm.es search ieeesb.etsit.upm.es etsit.upm.es nameserver 138.100.17.10
y un /etc/host.conf
como:
order host,bind multi off
y listar en el archivo /etc/hosts
las direcciones IP y los nombres asociados a las máquinas de nuestra subred, que siguiendo con ejemplo pueden ser:
138.100.31.81 atlante.ieeesb.etsit.upm.es atlante 138.100.31.82 febe.ieeesb.etsit.upm.es febe
Cualquir resolución de nombre se intentará en primer lugar a través de los datos en el /etc/hosts
y si no se consigue se realizará una pregunta al servidor, en este caso 138.100.17.10
. Se buscarán primero direcciones en ieeesb.etsit.upm.es
y después en etsit.upm.es
. Se debe observar que el nombre del subdominio de la máquina hay que indicarlo en search
aunque ya se encuentre en domain
.
Este es el tipo de configuración que se obtiene tras una instalación de GNU/Linux local típica. Todo lo necesario para actualizarla puede ser, a lo sumo, modificar la lista de máquinas locales en /etc/hosts
.
El método anterior es el adecuado para una red pequeña en la que un solo archivo /etc/hosts
puede albergar la tabla de asignación de direcciones y nombres. Al principio cada nodo resolvía la traducción de forma local del mismo modo que se ha indicado. Todos los ordenadores poseian una tabla similar con las entradas tanto de nodos locales como la de TODOS los remotos. En 1981, cuando los "/etc/hosts"
debian ocupar varios megas que se quedaban obsoletos en pocas horas, se puso en marcha DNS. El concepto es bastante simple, cuando un ordenador debe realizar una traducción de un nodo cuyo nombre no se encuentra en las tablas locales, se consulta a un servidor que, o bien contiene una tabla más amplia o bien puede cursar la petición a otro servidor. Los servidores deben poseer caches en las que se guarden las últimas peticiones resueltas y que se actualicen periódicamente para reflejar los cambios de nombres en la red.
Como se puede intuir, el sistema forma una base de datos distribuida en la que cada nodo guarda información de los subdominios que cuelgan del mismo. Una gestión cabal de los servidores es la que marca la diferencia entre una red usable y un caos absoluto.
Uno de los paquetes que implementan un servidor de DNS es Bind (Berkeley Internet Name Domain). Originalmente para BSD, y posteriormente portado a la mayoría de sistemas operativos existentes, Bind consta de un servidor (un proceso auxiliar o demonio, "daemon") y la libreria de funciones para la resolución de nombres de la que se habla anteriormente.
Al arrancar el demonio de bind, named
, el primer archivo que se lee es /etc/named.boot
y se ejecutan usualmente los comandos:
directory [trayecto]
/var/named
, ya que hay caches que deben ser reescritas (consultar FHS, en referencias).
include [file]
/etc/named.conf
indica los dominios que se van a servir y las cachés que se van a usar para almacenár las consultas. En estas cachés habrá que introducir ciertas entradas iniciales, que se verán más adelante. Un named.conf
típico es:
options { directory "/var/named"; }; // // Boot file for name server // // type domain source file zone "." { type hint; file "named.root"; }; zone "localhost" { type master; file "named.local"; }; zone "127.in-addr.arpa" { type master; file "named.rev-local"; };
En options
se incluyen parámetros de comportamiento del servidor, en este caso se repite el trayecto indicado en /etc/named.boot
.
La sentencia:
zone "[subdominio]" { type [tipo]; file "[caché]" };
especifica qué archivo contiene la caché de la zona [subdominio]
así como el tipo de consulta que se realizará para esta zona. Los tipos de consulta son:
hint
zone
.
master