Después de la primera entrega (Configurar un servidor de nombres con BIND) donde comentábamso algunas piezas elementales de BIND, en esta segunda entrega veremos cómo escribir ficheros de zona, que son los ficheros en los que se guardan los datos que BIND sirve.

Los Registros de Recursos

Los Registros de Recursos (RR) son cada uno de los datos elementales que un servidor de nombres sirve, y (casi) siempre se escriben en una línea del fichero de zona. Un RR típico es una relación entre un nombre de dominio y una dirección IP, como las líneas que aparecen en los ficheros de configuración de la entrega anterior.

Precisamente vamos a comenzar esta explicación con esos RR: los de tipo A.

Un RR de tipo A relaciona un nombre de dominio con una dirección. Si estamos hablando de Internet (o de redes que utilicen el protocolo IP) esa dirección será una dirección IP.

Un RR de tipo A se construye, entonces, de esta manera:

nombre    TTL    clase    tipo    dirección

Por ejemplo:

savor.gulic.org.    86400    IN    A    193.145.155.10

Este RR relaciona el nombre savor.gulic.org. (el punto del final es necesario, e indica la raíz del árbol DNS) con la dirección IP 193.145.155.10 que es una dirección de Internet, (IP), por eso especificamos que el RR es de clase IN (Internet), y esa información es válida durante 1 día (86400 segundos). Hay otras clases que no son para usar en Internet, como CH o HS para redes CHAOS o Hesiod (respectivamente).

Íntimamente relacionado con el tipo A, y con la misma sitaxis, está el tipo AAAA para direcciones IPv6:

A.ORSN-SERVERS.NET.    3600000    IN    AAAA    2001:8d0:0:3::100

Es decir, la dirección IPv6 de a.orsn-servers.net es 2001:08d0:0000:0003:0000:0000:0000:0100 y es válida durante 41 días y 16 horas.

Otro tipo que ya hemos visto es el tipo CNAME, que registra un alias de nombre de dominio:

drupal.gulic.org.    86400    IN    CNAME    savor.gulic.org.

Es decir, si buscas la dirección de drupal.gulic.org lo que debes hacer es buscar la de savor.gulic.org, y el alias es válido durante 1 día.

Si tienes un servidor de nombres para tu dominio, con los tipos anterior puedes hacer, más o menos, lo que te de la gana, y si te equivocas “sólo” dejarás fuera de juego a una máquina. La cosa se complica un poco con el siguiente tipo, en el cual una equivocación puede dejar fuera de juego todo un subdominio. Es el tipo NS, que registra un servidor de nombres:

gulic.org.    86400    IN    NS    ns1.canarytek.net.

Es decir, el servidor de nombres al que tienes que preguntarle si buscas información sobre gulic.org es ns1.canarytek.net (dato válido durante 1 día). Un error en esto implica que nadie que le pregunte a este servidor será capaz de saber a quién preguntarle por gulic.org, con lo que en realidad dejaremos a gulic.org inaccesible desde el mundo (con la excepción de quienes puedan averiguar las direcciones IP por otro medio, como un caché propio (que expirará también en 1 día).

Si uno posee un dominio, en el servidor de nombres primario de ese dominio normalmente se pone también otro tipo de registro, el que indica que el servidor que lo posee es la Autoridad para ese dominio. Se trata del registro SOA (Start of authority) y su formato es más complicado:

dominio    TTL    clase    tipo    MNAME    RNAME    Serie    Refresco    Reintento    Caducidad    Mínimo

Un ejemplo:

gulic.org.    86400    IN    SOA    ns1.canarytek.net.    root.canarytek.net.    2005092102    28800    7200    604800    86400

Veamoslo poco a poco: El dominio gulic.org reside en el servidor de nombres ns1.canarytek.net. que es el servidor Autoritativo para el dominio. La dirección de correo de su administrador es root@canarytek.net (como vemos se sustituye “@” por “.” en la dirección de correo del administrador). El número de serie puede ser cualquier cosa, lo único importante es que crezca cada vez que modifiquemos el fichero. Es muy común usar una fecha como número de serie, en este caso el 21 de febrero de 2005, segunda versión del día. Los números siguientes indican el tiempo que esperará un servidor esclavo antes de tratar de actualizar la zona (es como la validez de los otros tipos, pero sólo afecta a los servidores esclavos), 8 horas aquí, el tiempo que esperá un servidor esclavo tras una actualización fallida antes de intentarlo de nuevo, 2 horas aquí, el tiempo que durará esta zona en un servidor esclavo si no se consigue actualizarla (que es distinto del Refresco, que es el tiempo antes de intentar actualizarla por primera vez), 1 semana aquí,y el tiempo mínimo que un servidor que haya almacenado una respuesta “Ese subdominio no existe” de esta zona debe esperar antes de volver a intentarlo, 1 día aquí. Usualmente este último valor se utiliza también como TTL del resto de los RR de la zona, si no se ponen específicamente, pero esta práctica es incorrecta.

Una línea por RR

Cada RR debe ocupar una línea, y sólo una, ya que el fin de línea (o retorno de carro) es lo que separa un RR del siguiente. Y cada línea no vacía es un RR completo.

Eso sí, como buen fichero de configuración, en algún sitio deben ir los comentarios. En un fichero de zona, se considera un comentario todo lo que haya entre un punto y coma (“;”) y el final de la línea.

Es posible hacer que un RR (típicamente un RR SOA) ocupe más de una línea si se utilizan paréntesis. Un RR SOA típicamente se escribe así:

gulic.org 86400 IN SOA ns1.canarytek.net. root.canarytek.net. (
                                 2005092102 ; Serial: 21/09/05 #2
                                 28800 ; Refresh: 8h
                                 7200 ; Retry: 2h
                                 604800 ; Expire: 7d
                                 86400 ) ; Minimum: 1d

El correo

Pero eso no es todo. Los programas que entregan el correo en Internet, los MTA que usan el protocolo SMTP, para saber dónde entregar el correo no buscan el RR tipo A (ni el AAAA) que corresponde a la dirección del destinatario, sino un registro MX (Mail eXchanger) que indica qué ordenador se encarga del correo. Un RR MX es diferente de los demás en que lleva, antes del dato, un número que indica la prioridad de ese MX entre los varios que pueda haber: sólo se entregará correo a un MX de menor prioridad (número mayor) si es imposible contactar con un MX de mayor prioridad (número menor):

gulic.org.    86400    IN    MX    10    smtp1.gestion.ulpgc.es.

Es decir, todo el correo @gulic.org se entregará a la máquina smtp1.gestion.ulpgc.es y no a ninguna máquina que acabe en gulic.org.

Un fichero de zona zompleto

Todo esto está muy bien, pero hay que ponerlo todo junto en un fichero de zona. Para ello, basta con poner los RR uno detrás de otro. Pero hay un par de maneras de facilitar el trabajo. La primera es la directiva $TTL que indica el TTL de todos los registros que no lo lleven explícitamente. Con ello nos podemos ahorrar los campos TTL de todos (o la mayoría) de los RR.

Otra manera de facilitar este trabajo es que la clase de los RR se hereda de uno a otro del mismo tipo, como vimos al final de la entrega anterior, donde sólo figuraba la clase IN en el primer registro NS, el primer registro A y el primer registro AAAA.

Otra manera más es el dominio arroba (“@”), que se refiere al dominio origen de la zona, es decir, el que aparece en el RR SOA. Este dominio se puede cambiar a lo largo del fichero con la directiva $ORIGIN. Además, si un nombre se especifica sin el punto final que indica el dominio raíz se le añade el origen al final. $ORIGIN también hereda de esta manera.

Otra simplificación es que los RR heredan el dominio del RR anterior si no se especifica ninguno.

Además, con la directiva $INCLUDE podemos incluir un fichero dentro de otro.

Finalmente, la última simplificación es la directiva $GENERATE que veremos en otra entrega.

Así, un fichero de zona puede ser:

; Un ejemplo de fichero de zona para gulic.org

$TTL 86400 ; TTL para todos los registros
gulic.org IN SOA ns1.canarytek.net. root.canarytek.net. (
                                 2005092102 ; Serial: 21/09/05 #2
                                 28800 ; Refresh: 8h
                                 7200 ; Retry: 2h
                                 604800 ; Expire: 7d
                                 86400 ) ; Minimum: 1d
; En el SOA no hace falta TTL porque la coge del $TTL

@    IN      MX    10    smtp1.gestion.ulpgc.es.
             MX    10    smtp2.gestion.ulpgc.es.
             MX    10    smtp3.gestion.ulpgc.es.
; En estos no hace falta TTL por lo mismo, el primero se refiere a gulic.org por la arroba y los demás al mismo y de la misma clase por herencia

     IN      NS    ns1.canarytek.net.
             NS    ns2.canarytek.net.

     IN      A    193.145.155.10
; Este es el nombre que se resuelve si se pone simplemente "gulic.org"

drupal    IN    CNAME    savor
socios          CNAME    savor
wiki            CNAME    savor
almacen         CNAME    savor
fotos           CNAME    savor
jabber          CNAME    savor
users           CNAME    everett
; Nos podemos ahorrar ".gulic.org." porque al no poner punto final se añade el origen

savor      A    193.145.155.10
everett    A    193.145.155.11
ulysses    A    193.145.155.12
; Heredan la clase IN del registro A anterior

$ORIGIN listas
; Cambiamos el origen a partir de este punto, a listas.gulic.org.

@    A     193.145.155.10
     MX    10    smtp3.gestion.ulpgc.es.
     MX    10    smtp1.gestion.ulpgc.es.
     MX    10    smtp2.gestion.ulpgc.es.
; En estos cuatro RR la @ vale listas.gulic.org. y la clase y el TTL van heredados

Próximo artículo

Estos no son todos los tipos de RR que existen. En la próxima entrega hablaré del tipo PTR y nombraré el resto de los tipos válidos (aunque realmente poco utilizados).