Como se comentó en el capítulo 2, la red TCP/IP puede utilizar diferentes métodos para convertir nombres en direcciones IP. El mecanismo más simple consiste en almacenar los nombres en una tabla de máquinas en el fichero /etc/hosts. Esto es únicamente interesante en el caso de pequeñas redes de área local que solo requieran la administración de una persona, y que no tengan trafico IP con el mundo exterior. Recordamos que el formato del fichero hosts fue descrito en el capítulo 5.

Alternativamente, puede utilizarse BIND - el servicio de nombres Internet de Berkeley o "Berkeley Internet Name Domain" - para traducir nombres de máquinas a direcciones IP (cosa que también se conoce como resolución). Configurar BIND puede ser una laboriosa tarea pero, una vez hecho, los cambios en la topología de la red serán mucho más fáciles de hacer. En Linux, como en muchos otros sistemas Unix, el servicio de nombres se realiza mediante un programa llamado named. Al iniciarse, carga un conjunto de ficheros maestros en su cache y espera peticiones de procesos locales o remotos. Existen distintas maneras de preparar BIND, y no es necesario ejecutar un servidor de nombres en cada máquina: generalmente, uno para toda la red es suficiente.

 Este capítulo le dará ideas generales acerca de como configurar y ejecutar un servidor de nombres. Si pretende usar BIND en un entorno mas complejo que una pequeña red local (tal vez con conexión a Internet) debería echar un vistazo a un buen libro sobre BIND, como "DNS y BIND" de Cricket Liu (vea [AlbitzLiu92]). Además, le interesará echar un vistazo a los comentarios adicionales que aparecen junto a las fuentes de su versión de BIND. También existe un grupo de news para cuestiones sobre DNS: el grupo comp.protocols.tcp-ip.domains.

Cuando hablamos del "sistema de resolución", no nos referiremos a una aplicación en particular, sino a la biblioteca de resolución: un conjunto de funciones que pueden encontrarse en las bibliotecas estándar del lenguaje C. Las rutinas principales son gethostbyname(2) y gethostbyaddr(2), que buscan la dirección IP de una máquina a partir del nombre y viceversa. Es posible configurarlas para que simplemente miren en el fichero hosts local (o remoto, si se usa NIS). Otras aplicaciones, como smail, pueden incluir diferentes rutinas para esto y necesitan cierto cuidado.

El fichero host.conf es fundamental para controlar la configuración del sistema de resolución de nombres. Se encuentra en el directorio /etc e indica al sistema de resolución que servicios debe usar y en que orden.

Las opciones del fichero host.conf deben estar en líneas distintas. Los campos deben separarse por blancos (espacios o tabuladores). Un símbolo almohadillado (#) supone desde ese punto hasta el final de la línea un comentario del fichero.

Las opciones disponibles son las siguientes:

_____________________________________________
1 N. del T.: literalmente, burla

Cuando se busque una máquina con el nombre de dominio local éste será eliminado, haciendo que la búsqueda en el fichero /etc/hosts tenga éxito. Esta opción puede ir repetida con varios dominios, de modo que su máquina podría ser local a diversos dominios.

Un ejemplo de este fichero para la máquina vlager seria:

Existen algunas variables de entorno que establecen opciones que tienen mas prioridad sobre las puestas en el fichero host.conf. Estas son:

Cuando se configura la librería de resolución para utilizar los servicios de BIND, tiene que indicarse también que servidores utilizar. El fichero resolv.conf contiene una lista de servidores, que si está vacía hará considerar al sistema que el servidor está en su máquina.

Si ejecuta un servidor de nombres en su máquina local, tendrá que configurarlo por separado, como se explicará después. Si se encuentra en una red local y puede usar un servidor de nombres existente, mejor.

La opción más importante del fichero resolv.conf es nameserver, que tiene la dirección IP del servidor de nombres a usar. Si especifican varios servidores poniendo varias líneas nameserver, se intentarán usar en el orden dado; por lo que debería poner en primer lugar el servidor de nombres más rápido o cercano. Actualmente, puede ponerse un máximo de tres servidores distintos.

Si no hay ninguna línea nameserver, se intentará buscar el servidor en la propia máquina local.

Hay dos opciones más: domain y search, indicando la primera dominios alternativos a probar si la búsqueda inicial del nombre falla. Estos dominios irán separados por blancos o tabuladores.

Si no se incluye una opción search, se construirá una lista de búsqueda por defecto por el dominio local mas todos los dominios padre hasta el raíz. El dominio local puede darse con la opción domain, y si no se da ninguno el sistema de resolución lo obtendrá mediante la llamada al sistema getdomainname(2).

Como lo anterior puede resultar confuso, sea el siguiente ejemplo de fichero resolv.conf para la Cervecera Virtual:

Cuando se trate de traducir el nombre vale, el sistema empezará por buscar directamente vale y si falla, probará con vale.vbrew.com y finalmente vale.com.

Si tiene en funcionamiento una red local dentro de otra más grande, deberá usar servidores de nombres principales siempre que sea posible. La ventaja de hacerlo así es que se consiguen generosas memorias cache, ya que todas las peticiones de nombres les llegan a ellos. Este esquema, sin embargo, tiene un inconveniente: cuando un incendio inutilizó el cable de red dorsal de nuestro departamento en la Universidad, no pudimos trabajar, pues ninguno de los servidores de nombres estaban accesibles. No funcionaban ni los terminales X ni las impresoras...

Aunque no es muy habitual que las redes dorsales de las universidades sean pasto de las llamas, deberían tomarse precauciones para casos como éste.

Una solución es poner un servidor de nombres local que se ocupe de sus nombres locales, y reenvíe todas las peticiones de otros nombres a los servidores principales. Por supuesto, ésto solo es posible si usted tiene un dominio propio.

Alternativamente, puede mantener una copia de la tabla de nombres para su dominio o red local en el fichero /etc/hosts. En el fichero /etc/host.conf deberá incluir la opción "order bind hosts" para obligar a usar el fichero local si el servidor principal de nombres falla.

El programa que proporciona servicio de nombres en las máquinas UNIX suele ser named 2. Es un servidor desarrollado inicialmente para Unix tipo BSD, con el propósito de proporcionar servicio de nombres a máquinas clientes y posiblemente a otros servidores de nombres.

La versión actualmente utilizada en casi todos los sistemas Linux es BIND-4.8.3. La nueva versión, BIND-4.9.3, esta en este momento en versión Beta, y pronto estará disponible para Linux.

_____________________________________________
2 N. del T.: Pronúnciese neim-di:

Esta sección requiere ideas acerca de como funciona el Sistema de Nombres y Dominios (DNS). Si lo que sigue a continuación le suena a chino, puede releer el capítulo 2, que le dará información acerca de como funciona básicamente el DNS.

El programa named suele iniciarse al arrancar la máquina, y ejecutarse hasta que se apaga. Obtiene la información que necesita de un fichero llamado /etc/named.boot, y diversos ficheros que contienen datos acerca de nombres de dominio y direcciones, llamados ficheros de zona. Los formatos y semántica de estos ficheros serán explicados en la siguiente sección.

Para ejecutar named, solo tiene que teclear:

El programa named se iniciará y leerá el fichero named.boot y los ficheros de zona que se especifiquen en él. Su número de proceso será anotado en ASCII en el fichero /var/run/named.pid, recibirá ficheros de zona de los servidores principales si es necesario y comenzará a escuchar las peticiones de DNS por el puerto 53.3

El fichero named.boot suele ser muy pequeño y contiene punteros a ficheros con información de zonas y a otros servidores de nombres. Los comentarios en este fichero comienzan con un punto y coma y se extienden hasta el siguiente fin de línea. Antes de que veamos con más detalle el formato de este fichero, observaremos el ejemplo para la máquina vlager dado en la figura 6.1.4

Los comandos cache y primary sirven para cargar información en named. Esta información se obtiene de los ficheros especificados en el segundo argumento. Contienen representaciones textuales de los registros DNS, que veremos a continuación.

En este ejemplo, se configura named como el servidor de nombres principal para tres dominios: los que se indican con el comando primary. La primera línea dice que named actúe como servidor principal para vbrew.com, tomando la información de zona del fichero named.hosts. El comando directory dice que todos los ficheros de zona se encuentran en el directorio indicado.

_____________________________________________
3 Hay varios binarios de named disponibles en los servidores de FTP, cada uno configurado de forma diferente. Algunos anotan su fichero de número de proceso en el directorio /etc/, otros en /tmp y otros en /var/tmp.
4 Observar que los nombres de dominio del ejemplo se dan sin el punto final. Versiones anteriores del programa named parece que traten los puntos al final como errores y sin avisar descartan la línea afectada. En la versión BIND-4.9.3 se intenta arreglar este tema.

Figura 6.1: El fichero named.boot para vlager.

La entrada iniciada con la palabra cache es muy especial y debe estar presente en casi todas las máquinas que ejecuten un servidor de nombres. Su función es doble: indica a named que active su cache, y también que cargue la información de los servidores raíz del fichero indicado (en este caso, named.ca). Regresaremos a este concepto más tarde.

A continuación se presenta una lista de las opciones más importantes que podemos poner en el fichero named.boot:

Hay dos opciones adicionales que no vamos a describir: sortlist y domain. Además, hay dos directivas que pueden aparecer en los ficheros de zona. Son $INCLUDE y $ORIGIN, que tampoco vamos a describir, ya que raramente se utilizan.

Los ficheros incluidos con named, como named.hosts, siempre tienen un dominio asociado a ellos llamado origen. Este es el nombre de dominio especificado con los comandos cache y primary. En un fichero maestro, se pueden especificar nombres de máquinas y dominios relativos a este dominio. Un nombre dado en un fichero de configuración se considera absoluto si termina con un punto. En caso contrario se considera relativo al origen. Al origen en sí mismo nos podemos referir con "@".

Todos los datos en un fichero principal se dividen en registros de recursos o RRs. Son la unidad de información del DNS. Cada RR tiene un tipo. Los registros de tipo A, por ejemplo, asocian un nombre a una dirección IP. Los registros de tipo CNAME asocian un alias de una máquina con su nombre oficial. Como ejemplo, obsérvese la figura 6.3 de la página 96, que muestra el fichero named.hosts para nuestro sistema.

La representación de los RRs en los ficheros utiliza el siguiente formato:

Los campos se separan por espacios o tabulaciones. Una entrada puede continuarse en varias líneas si se abre un paréntesis antes del primer fin de línea y el último campo es seguido de un cierre de paréntesis. Cualquier cosa entre un punto y coma y el siguiente salto de línea será un comentario.

_____________________________________________
5 N. del T.: Time to Live

A continuación se presenta una lista incompleta de RRs que se utilizan en los ficheros de DNS. Hay algunos mas que no vamos a comentar. Son experimentales, y de escaso uso.

SOA Describe una zona de autoridad (SOA significa "Start of Authority", es decir, "Comienzo de Autoridad"). Señala que los registros siguientes contienen información "autorizada" para el dominio. Cada fichero incluido en la opción primary debe tener un registro SOA para esta zona. Los datos asociados contienen los siguientes campos:

El campo hardware identifica el hardware utilizado. Existe un conjunto de convenciones sobre esto, el cual puede verse en el RFC 1340. Si el campo contiene blancos, debe encerrarse entre comillas dobles. El campo software especifica el software utilizado, para el que también existen convenciones en el mismo documento RFC.

Las figuras 6.2, 6.3, 6.4, y 6.5 son ejemplos de ficheros para un servidor de nombres en nuestra red ejemplo, localizado en la máquina vlager. El ejemplo es sencillo dada la simplicidad de nuestra red. Si tiene requisitos mas complejos, léase el libro "DNS and BIND" de Cricket Liu y Paul Albitz ([AlbitzLiu92]).

El fichero named.ca mostrado en la figura 6.2 da ejemplos de registros de servidores raíz.

Un fichero de cache típico suele tener información sobre una docena de servidores. Puede obtener la lista de servidores del dominio raíz mediante el programa nslookup descrito mas adelante.6

Figura 6.2: Fichero named.ca.

_____________________________________________
6 Esto no podrá hacerlo si no ha especificado algún servidor raíz. Puede en cambio ejecutar nslookup con un servidor diferente del suyo, o usar el fichero de ejemplo de la figura 6.2 y entonces obtener una lista de servidores validos.

Figura 6.3: Fichero named.hosts.

Figura 6.4: Fichero named.local.

Figura 6.5: Fichero named.rev.

Existe una utilidad que resulta interesante para comprobar el funcionamiento del servidor de nombres recién configurado. Se llama nslookup, y puede usarse tanto interactivamente como desde la línea de comandos. En el último caso, se invoca simplemente como:

y pedirá el nombre indicado al servidor de nombres que aparezca en resolv.conf (si aparece mas de uno, nslookup cogerá uno al azar).

El modo interactivo, sin embargo, es mucho más interesante. Además de buscar máquinas por su nombre, se puede también preguntar por cualquier registro DNS, y transferir la información de zona completa de un dominio.

Cuando se invoca sin argumentos, nslookup mostrará el servidor de nombres en uso y entrará en modo interactivo. En el prompt '>' que se mostrará, puede teclear cualquier nombre de dominio por el que quiera preguntar. Por defecto, preguntará por registros de tipo A, es decir, aquellos que dan una dirección IP correspondiente al dominio introducido.

Esto se puede cambiar tecleando "set type=tipo", donde tipo es un nombre de registro de recurso (RR) como los descritos antes (en la sección 6.2) o bien la palabra ANY.

Por ejemplo, ésta puede ser una sesión con nslookup:

Si intenta preguntar por un nombre que no tiene dirección IP asociada, pero se encuentran otros registros relacionados en el DNS, el programa responderá con un error "No type A records found" (no se encontraron registros de tipo A). Sin embargo, puede hacer preguntas para otro tipo de registros sin mas que usar el comando "set type". Por ejemplo, para obtener el registro SOA de unc.edu, podría escribir lo siguiente:

De manera similar, se pueden pedir registros MX, etc. Y mediante la palabra ANY se obtendrán todos los RR asociados al nombre escrito.

Una aplicación práctica de nslookup para la depuración es obtener la lista de servidores raíz para el fichero named.ca. Esto puede hacerse pidiendo todos los registros NS asociados al dominio raíz:

El conjunto completo de comandos disponibles en nslookup puede obtenerse con la orden interna help.

Hay algunas utilidades que pueden ayudarle en sus tareas de administrador de BIND. Describiremos dos de ellas. Por favor, eche un vistazo a la documentación que traen para saber como utilizarlas.

La utilidad hostcvt sirve para obtener una configuración inicial de BIND a partir del fichero /etc/hosts. Genera tanto los ficheros de traducción directa (registros A) como los de traducción inversa (registros PTR) teniendo cuidado con los nombres de alias y otros. Por supuesto, no hará todo el trabajo, pues aun puede que necesite ajustar los registros SOA o añadir registros MX. Suponemos que también le ayudará tener cerca algunas aspirinas. El programa hostcvt forma parte de las fuentes de BIND, pero puede obtenerse por separado en algunos servidores FTP dedicados a Linux.

Después de configurar el servidor de nombres, puede que desee comprobar el resultado. La aplicación ideal para ésto (al menos para mí) es el programa dnswalk, un paquete basado en perl que navega por la base de datos DNS, buscando errores habituales y verificando que la información es consistente. El programa dnswalk ha sido enviado recientemente al grupo comp.sources.misc de News, y debería estar en los servidores FTP que archiven este grupo (un servidor que seguro que lo tiene es ftp.uu.net).