Guía de Administración de Redes con Linux - Ejecución de named (II)

Ficheros de base de datos DNS

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 caché 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 Ejemplo 6-11∞, que muestra el fichero named.hosts para nuestro sistema.

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

|| [domain] [ttl] [class] type rdata ||

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.

domain

Aquí va el nombre del dominio que se aplica al RR actual. Si no se da nombre de dominio, se asume el mismo que se puso para el RR anterior.

ttl

Con el fin de forzar al sistema DNS a descartar información después de cierto tiempo, cada RR lleva asociado un tiempo de vida o ttl[2]. El campo ttl especifica, en segundos, el tiempo de validez de la información desde que se obtiene del servidor. Es un número decimal de hasta ocho dígitos.

Si no se especifica ningún valor, tomará uno por defecto del campo minimum del registro SOA precedente.

class

Aquí se indica la clase de dirección: IN para direcciones IP, HS para objetos de la clase Hesiod. Trabajando con redes TCP/IP debe usarse siempre la clase IN.

Si no se especifica ningún valor, se toma el valor del RR anterior.

type

Describe el tipo de RR. Los tipos habituales son A, SOA, PTR y NS. En las siguientes secciones comentaremos estos tipos de RRs.

rdata

Contiene los datos asociados al RR. El formato depende del tipo, y se describirán más adelante.

A continuación se presenta una lista incompleta de RRs que se utilizan en los ficheros de DNS. Hay algunos más 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:

origin

Nombre canónico del servidor de nombres primario para este dominio. Se suele dar como nombre absoluto.

contact

Dirección de correo electrónico de la persona responsable de mantener el dominio, reemplazando el carácter «@» por un punto. Por ejemplo, si el responsable de nuestra red fuese janet, este campo contendrá: janet.vbrew.com.

serial

Este es el número de versión del fichero de zona, expresado con un número decimal. Cuando se cambien datos del fichero, deberá incrementarse este número. Se suele expresar como número de versión en el día actual, es decir, en el formato AAAAMMDDnn siendo AAAA el año, MM el mes, DD el día y nn el número de revisión de ese día (01 si no hay más de una). Por ejemplo, 2001072201 para el 22 de julio de 2001.

El número de versión es utilizado por los servidores secundarios para saber cuándo la información de una zona ha cambiado. Para mantenerse actualizados, los servidores secundarios piden cada cierto tiempo el registro SOA del primario, y comparan el número de versión con el que tienen en la caché. Si ha cambiado, el servidor secundario pedirá de nuevo la información de zona al primario.

refresh

Especifica el intervalo, en segundos, que esperan los servidores secundarios entre peticiones de registros SOA a los primarios. De nuevo, se trata de un número decimal de hasta ocho dígitos.

Normalmente, la topología de la red no cambia mucho, con lo que este número será como poco de un día para grandes redes, y de mucho más tiempo para redes pequeñas.

retry

Este número determina los intervalos de tiempo entre reintentos de comunicación con servidores primarios cuando una petición de una zona falla. No debe ser pequeño ya que un fallo temporal del servidor primario hará que el secundario cargue inútilmente la red. Buenas elecciones son una hora o como poco media hora.

expire

Especifica el tiempo, en segundos, que tardará el servidor en descartar los datos de zona si no ha podido contactar con el servidor primario. Normalmente se pondrá un valor grande, de por lo menos una semana (604800 segundos), aunque si se incrementa a un mes o más será incluso más razonable.

minimum

Valor predeterminado para el valor del ttl en los registros de recursos que no lo especifiquen. Sirve para indicar a otros servidores de nombres que descarten el RR tras cierto tiempo. No tiene efecto, sin embargo, sobre el tiempo en el que un servidor secundario intenta actualizar la información de zona.

El valor de minimum debe ser grande, en especial para redes locales con topologías poco cambiantes. Una buena elección puede ser de una semana o un mes. En el caso de que haya registros RR que cambien con frecuencia, siempre podrá asignarle valores particulares de ttl.

A

Asocia direcciones IP con nombres. El campo de datos contiene la dirección separando los octetos por puntos, como es habitual.

Para cada máquina sólo puede haber un registro A, que se considera nombre oficial o canónico. Cualquier otro nombre será un alias y debe ser incluido con registros CNAME.

NS

Apunta a un servidor de nombres maestro de una zona subordinada. El campo de datos contiene el nombre del servidor. Para traducir ese nombre debe proporcionarse un registro A adicional, que se conoce como glue, al proporcionar la dirección IP del servidor.

Hay que incluir registros NS en dos casos: primero, cuando delegamos la autoridad a una zona subordinada. Segundo, en la base de datos del servidor principal de cualquier zona. Los servidores NS especificados en el fichero de zona deben coincidir exactamente con los que especifica la zona padre que delega.

El registro NS especifica el nombre del servidor de nombres primario y los secundarios para una zona. Estos nombres deben poderse resolver para poderse usar. A veces los servidores pertenecen al mismo dominio que sirven, lo que ocasiona un problema de el huevo o la gallina: no podemos obtener el servidor de nombres hasta que accedamos al dominio, pero para acceder el dominio hay que conocer la IP del servidor de nombres... Para resolver este problema se crean registros A directamente en la zona padre, para resolver esas direcciones. Estos son los que ya comentamos antes, los registros glue (podríamos traducirlos como registros-pegamento), puesto que unen o pegan la zona hija a la zona padre.

CNAME

Asocia un alias con su nombre canónico. El nombre canónico se determina con un registro A. Los alias son indicados mediante registros CNAME.

PTR

Se usa para asociar nombres del dominio in-addr.arpa con sus nombres normales. Se usa para obtener nombres a partir de direcciones IP (traducción inversa). El nombre de la máquina debe ser el canónico.

MX

Especifica el servidor de correo para un dominio. En la sección Sección 17.4.1∞ se explica por qué son necesarios estos servidores. La sintaxis del registro MX es:

|| [domain] [ttl] [class] MX preference host ||

host nombra el servidor de correo para el dominio domain. Cada servidor tiene asociado un valor de preference (preferencia). Cuando un agente de transferencia de mensajes quiere entregar correo al dominio, intentará conectarse a esos servidores hasta conseguir entregar el mensaje; empezando por el que tenga menor valor de preferencia.

HINFO

Este registro da información sobre el hardware y el software de la máquina. Su sintaxis es:

|| [domain] [ttl] [class] HINFO hardware software ||

El campo hardware identifica el hardware usado en este nodo. Para indicarlo, se siguen ciertas convenciones, especificadas en el RFC 1700. Si el campo contiene blancos, debe encerrarse entre comillas dobles. El campo software indica el sistema operativo que ejecuta el nodo, que también está normalizado.

Por ejemplo, un registro HINFO para describir un sistema Intel ejecutando Linux podría ser:

|| tao 36500 IN HINFO IBM-PC LINUX2.2 ||
y para el caso de que se tratara de un sistema basado en Motorola 68000: || cevad 36500 IN HINFO ATARI-104ST LINUX2.0 jedd 36500 IN HINFO AMIGA-3000 LINUX2.0 ||

Hay una clase especial de configuración de named, que nos servirá para introducirnos en su funcionamiento. Se llama sólo-caché. No sirve ningún dominio propio, pero actúa como repetidor de otros DNS para nuestra red local. Cuando se repitan peticiones a un mismo nodo, el servidor responderá con la información que ya tiene, evitando peticiones repetidas que ocupen ancho de banda en Internet. Esto es especialmente útil cuando contamos con una conexión de banda estrecha, como las que veremos en Capítulo 7∞ y Capítulo 8∞.

El fichero named.boot para un servidor sólo de caché, es similar a éste:

|| ; named.boot para servidor de sólo caché directory /var/named primary 0.0.127.in-addr.arpa named.local ; red local caché . named.ca ; servidores raiz ||

Además de este fichero, hay que tener el correspondiente named.ca, con una lista válida de servidores raíz. Debemos copiar y usar Ejemplo 6-10∞ para esto. No se requieren otros ficheros para una configuración de sólo caché.