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
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
y
.
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é.
