Ficheros de zona y registros de recursos

Un fichero de zona describe un nombre de dominio de forma que pueda ser utilizado por los programas DNS. Una mala configuración puede tener consecuencias indeseables, más o menos graves, como el envío del correo a una localización errónea, la redirección de los clientes a la competencia, etc., y como las respuestas a las consultas DNS suelen ser cacheadas por otros sistemas DNS, la rectificación de un error puede llevar un tiempo considerable, de horas, días e incluso semanas. Es evidente que la correcta configuración de los servicios de DNS es fundamental para las empresas.

Un fichero de zona es un fichero de texto con un formato estandarizado (RFC 1035) cuyo contenido está formado por los siguientes items:

• Comentarios: Comienzan con un punto y coma ( ; ) y terminan con el final de la línea. Pueden ponerse en cualquier lugar.
• Directivas: Todas las directivas comienzan con el signo dolar ( $ ) y controlan ciertos aspectos del fichero de zona.
• Registros de recursos (RR): Ocupan una línea cada uno a excepción de las entradas que van entre paréntesis, las cuales pueden distribuirse en varias líneas. Sirven para definir características, propiedades y entidades del dominio.
• Separadores de campos: Pueden ser espacios y/o tabuladores. Se pueden utilizar tantos como se deseen. Su uso fundamental es el de dar al fichero de zona un aspecto claro.

Lo siguiente es un ejemplo de fichero de zona:

; IPv4 zone file for asir.com
$TTL 2d
; default TTL for zone
$ORIGIN asir.com. ; base domain-name
; Start of Authority record defining the key characteristics
; of the zone (domain)
@         IN    SOA   ns1.asir.com. hostmaster.asir.com. (
                      2016040800  ; se = serial number
                      12h         ; ref = refresh
                      15m         ; ret = refresh retry
                      3w          ; ex = expiry
                      2h          ; nx = nxdomain ttl
                      )
; name servers Resource Records for the domain
          IN    NS    ns1.asir.com.
; the second name server is
; external to this zone (domain).
          IN    NS    ns2.asir.net.
; mail server Resource Records for the zone (domain)
; value 10 denotes it is the most preferred
    3w    IN    MX    10 mail.asir.com.
; the second mail server has lower preference (20) and is
; external to the zone (domain)
          IN    MX    20 mail.asir.net.
; domain hosts includes NS and MX records defined previously
; plus any others required
ns1       IN    A     192.168.1.10
mail      IN    A     192.168.1.11
prof      IN    A     192.168.1.12
www       IN    A     192.168.1.13
; aliases ftp (ftp server) to an external location
ftp       IN    CNAME ftp.asir.net.

Como puede verse, el registro SOA se ha distribuido en varias línea, también se podría haber escrito en una sola, si no usamos los paréntesis:

@         IN    SOA     ns1.asir.com.     hostmaster.asir.com.     2016040800     12h     15m     3w     2h

El formato del fichero de zona ofrece muchos métodos abreviados con el objetivo de reducir su tamaño y teclear menos; normalmente hay varias formas de hacer casi todo.

Las directivas y los RR más usados son:

• Directiva $TTL: Define el valor por defecto del TTL para el dominio, es decir, el tiempo que un RR puede permanecer en una caché de un servidor de nombres. Es obligatoria.
• Directiva $ORIGIN: Contiene el nombre del dominio de la zona que se está definiendo. Es opcional.
• RR SOA (Start Of Authority): Es el primer RR que debe aparecer obligatoriamente en el fichero de zona, debe ser único y describe las características globales de la zona o dominio.
• RR NS (Name Server): Definen los servidores de nombres que son autoritarios de la zona o dominio. Se deberían poner al menos dos registros NS, los cuales pueden hacer referencia a servidores internos al domino o externos al mismo. Es obligatorio al menos un registro NS.
• RR MX (Mail Exchanger): Definen los servidores de correos del dominio. Es un registro opcional, pues el dominio no tiene por qué tener servicio de correo. También pueden ponerse más de un registro MX, haciendo referencia tanto a servidores internos al dominio como externos.
• RR A (Address): Definen las direcciones IPv4 de todos los equipos de la zona. Es opcional.
• RR AAAA: Equivalente al A pero con direcciones IPv6. Es opcional.
• RR CNAME: Definen alias para los registros de recursos. Por ejemplo, un equipo puede tener más de un nombre usando CNAME. Es opcional.

Veamos el anterior ejemplo paso a paso. En primer lugar, las características que describe de la zona son:

• El nombre de dominio implementado la zona es: asir.com.
• La zona posee dos servidores de nombres, una interior al dominio (ns1.asir.com) y otro externo al mismo (ns2.asir.net).
• También tiene dos servidores de correo, que resuelven las direcciones con formato X@asir.com. Al igual que con los servidores de nombres, por motivos de seguridad, uno es interno al dominio (mail.asir.com) y otro externo (mail.asir.net).
• La zona posee un servidor web interno en el host www.asir.com.
• También el dominio asir.com dispone de un servidor ftp, de nombre interno ftp.asir.com, pero instalado en un host externo de nombre ftp.asir.net.
• Por último, se ha creado el nombre prof.asir.com para el ordenador del profesor, que es un ordenador cliente, sin ningún servicio en especial.

Como se puede ver, la configuración del ejemplo es capaz de resistir algunas situaciones problemáticas, gracias a dos estrategias:

• Hay dos servidores de nombres localizados geográficamente en lugares distintos (ns1.asir.com y ns2.asir.net), lo que permitirá que el servicio DNS, para el dominio asir.com, siga funcionando en el caso de que algún problema deje fuera de línea al servidor principal, ns1.asir.com.
• También, en el caso de que los correos no puedan llegar al servidor mail.asir.com, estos serán enviados a mail.asir.net, el cual estará configurado para que los reenvíe periódicamente a mail.asir.com, hasta que los reciba. Por lo tanto, ningún correo se perderán mientras esté fuera de línea mail.asir.com.

$TTL 2d

La directiva $TTL (RFC 1035) se utiliza para establecer el valor por defecto del tiempo de vida de los RR en las caché de los servidores de nombres. Cada RR puede llevar especificado explícitamente su TTL en la línea donde se crea, pero si no ponemos nada, se asume como tiempo de vida para dicho registro, el valor dado por $TTL.

Según el estándar, el valor TTL debe expresarse en segundos, pero la sintaxis de BIND permite utilizar también sufijos de tiempo (m → minutos, h →horas, d →días, w →semanas, da igual en mayúscula o en minúscula), y como es un software tan utilizado, el resto de programas servidores DNS lo aceptan también.

La siguiente directiva $TTL es equivalente a la anterior, pues simplemente está expresada en segundos en vez de en días.

$TTL 172800

El número de segundos puede ir desde 0 (indica que el RR no se guarde en la caché) hasta 2147483647 (unos 68 años).

Establecer un TTL razonable es importante pues influye en lo siguiente:

• Cuanto menor sea el TTL, más rápidamente se eliminarán de la caché los RR, forzando a realizar consultas DNS más frecuentemente, y por lo tanto, aumentará la carga operativa del servidor de nombres de la zona .
• Afectará también al tiempo que le llevará propagarse a todos los usuarios, cualquier cambio en el servidor de nombres.

El valor de dos días (2d) es algo razonable. El estándar, RFC 1912, propone un valor mayor a un día. En caso de hacer una modificación que queramos que se propague rápido, por ejemplo, un cambio de IP de un nombre, se suele bajar el valor TTL, por ejemplo a 12h, para volver de nuevo a 2d cuando el servicio se haya estabilizado.

Actualmente BIND rechaza la carga de una zona si la directiva $TTL no tiene un valor válido.

$ORIGIN asir.com.

La directiva $ORIGIN (RFC 1035), especifica el nombre del dominio que se añadirá a cualquier nombre incompleto de los RR. Un nombre incompleto será un nombre que no acabe en punto, es decir, que no sea un FQDN (nombre de dominio completamente cualificado). Es aconsejable no olvidar el punto final en el valor de $ORIGIN.

Se puede usar $ORIGIN dentro del fichero de zona cuantas veces queramos, y su efecto actúa desde el punto en el que se define hasta el final del fichero o hasta la siguiente directiva $ORIGIN.

$ORIGIN asir.com.
...
...
$ORIGIN informatica.asir.com.
...
...

La directiva $ORIGIN actúa, por ejemplo, en la siguiente línea:

ns1       IN    A     192.168.1.10

haciéndola equivalente a la siguiente:

ns1.asir.com.       IN    A     192.168.1.10

ya que ns1 no es un FQDN, y con $ORIGIN se consigue hacerlo, pero con menos esfuerzo, lo cual es importante si el fichero de zona tiene muchos RR.

@         IN    SOA   ns1.asir.com. hostmaster.asir.com. (
                      2016040800  ; se = serial number
                      12h         ; ref = refresh
                      15m         ; ret = refresh retry
                      3w          ; ex = expiry
                      2h          ; nx = nxdomain ttl
                      )

El registro SOA (RFC 1035) es el RR más importante, debe existir uno para cada zona y sirve para definir una serie de valores globales de la zona. Lo habitual es escribirlo usando el formato multilínea.

El RR SOA comienza con el nombre del dominio al que se refiere y se suele escribir el símbolo @, el cual se sustituye por el valor que $ORIGIN tenga en ese momento.

El nombre ns1.asir.com., es el nombre del servidor de nombres maestro de la zona. Se ha escrito con formato FQDN, que es lo habitual, pero se podría haber simplificado. Por otro lado, el nombre FQDN (también se podría haber simplificado) hostmaster.asir.com. es la dirección de correo del administrador del servicio DNS a donde enviar determinados informes. Puede ser cualquier dirección válida y en vez de usar la @ (hemos visto que tiene otro significado) se usa un punto, por lo que la dirección del ejemplo es en realidad: hostmaster@asir.com.

El número 2016040800 es el número de serie actual de la zona. Cada vez que actualicemos el fichero de zona debemos aumentar el número de serie, lo cual le servirá a los servidores esclavos (secundarios) para detectar que se han hecho cambios con respecto a la copia del fichero de zona que ellos tienen, y de este modo solicitar una transferencia de actualización. Suele utilizarse un formato de fecha: yyyymmddnn, en vez de un número nn normal. El valor mínimo es 1 y el máximo 4294967295.

El valor 12h es el valor de refresco para los servidores esclavos. Cuando transcurre dicho tiempo, los servidores esclavos de la zona intentan leer el registro SOA del maestro, y si el número de serie de este último es superior al número de serie del registro SOA de la copia que tienen los esclavos, entonces se solicita al maestro una transferencia completa del fichero de zona.

El intervalo de tiempo 15m indica el tiempo de reintento de contacto del servidor DNS esclavo con el maestro, es decir, para este ejemplo, transcurrido el intervalo de refresco, 12 horas, el servidor esclavo, como se ha dicho, intenta contactar con el servidor maestro para conseguir el registro SOA, si no lo consigue, lo volverá a intentar pasados 15 minutos.

El tiempo 3w, es el tiempo de expiración de los servidores esclavos, es decir, el intervalo de tiempo transcurrido el cual sin conseguir contactar con el maestro, el esclavo deja de contestar a las consultas DNS, pues se considera en ese momento no autoritario ya que su copia del fichero de zona estaría demasiado desactualizada. En el ejemplo, tras 12 horas, el servidor esclavo, intenta contactar con el servidor maestro, y al no conseguirlo, cada 15 minutos lo vuelve a intentar, y así estaría hasta 3 semanas, momento en el cual se detendría su funcionamiento como servidor DNS.

Por último, el valor 2h, indica el intervalo de tiempo que se mantendrá una consulta no resuelta en la caché de los servidores de nombres; transcurrido dicho tiempo, se volverá a intentar resolver la consulta (RFC 2308). En nuestro caso, si se hace una consulta de un nombre, por ejemplo, fpg.asir.com, y no es posible resolverla, el servidor devolverá un error de nombre (Name Error o NXDOMAIN). Durante las siguientes dos horas, si se vuelve a hacer la misma consulta, se responderá de la misma forma; pero pasadas las dos horas, se intentaría de nuevo resolver la consulta fallida. Los valores posibles van de 0 hasta 10800.

Otra forma de escribir el registro SOA anterior, un poco más simplificada, pero en este caso menos habitual, sería:

@         IN    SOA   ns1 hostmaster (
                      2016040800  ; se = serial number
                      12h         ; ref = refresh
                      15m         ; ret = refresh retry
                      3w          ; ex = expiry
                      2h          ; nx = nxdomain ttl
                      )

Siguiendo con nuestro ejemplo de fichero de zona:

          IN    NS    ns1.asir.com.
          IN    NS    ns2.asir.net.

Los registros NS definen los servidores de nombres autoritarios (al menos dos) de la zona o dominio. Comienza con el nombre del dominio que sirven, pero en este caso no se ha puesto nada, por lo que el nombre se coge del registro anterior, el RR SOA, que usa el nombre @, que ya sabemos que se sustituye por asir.com. En último lugar se coloca el nombre del servidor, en este caso se ha puesto en formato FQDN. Una versión con más escritura sería:

asir.com.          IN    NS    ns1.asir.com.
asir.com.          IN    NS    ns2.asir.net.

y más simplificada:

          IN    NS    ns1
          IN    NS    ns2.asir.net.

El servidor ns1, al ser un nombre interno, posteriormente tendrá que ser resuelto a una IP (se hará con un registro A o AAAA), pero el ns2, al ser externo, se resolverá con una consulta DNS.

   3w   IN     MX    10 mail.asir.com.
        IN     MX    20 mail.asir.net.

Los registros MX se utilizan para definir los servidores de correo de la zona. Siempre comienzan con el nombre del dominio al que sirven. En este caso, al igual que en los registros NS, no se ha puesto nada, por lo que cogen el valor del registro anterior (NS), que a su vez lo cogía del anterior (SOA), de modo que el valor es asir.com.

En el primer RR MX se ha puesto un valor de TTL explícito que solapa el valor global dado por la directiva $TTL, de modo que el tiempo de vida de ese registro en las caché será de tres semanas.

Los registros MX llevan un número que indican la prioridad del servidor de correo. En el ejemplo, los valores 10 y 20, lo que indica que el servidor mail.asir.com tendrá más prioridad que mail.asir.net por tener un valor más bajo. Los valores válidos van desde 0 hasta 66536.

El nombre mail.asir.com al ser interno, deberá tener una traducción a IP, lo que se hará con un registro A o AAAA.

Los registros anteriores podrían haberse escrito de forma más extensa así:

asir.com. 3w   IN     MX    10 mail.asir.com.
asir.com.      IN     MX    20 mail.asir.net.

y de forma más abreviada así:

3w   IN     MX    10 mail
     IN     MX    20 mail.asir.net.

Continuando con el ejemplo, viene ahora el bloque de los RR A:

ns1       IN    A     192.168.1.10
mail      IN    A     192.168.1.11
prof      IN    A     192.168.1.12
www       IN    A     192.168.1.13

Los registros A definen las IPv4 de los equipos dentro del dominio cuyos nombres se quieran hacer públicos. El equivalente para definir las IPv6 es el RR AAAA.

En el ejemplo se asocian los siguientes nombres con IP, ns1, mail, prof y www, todos nombres no FQDN, por lo que se les añadirá el valor en ese momento de $ORIGIN que es asir.com. Si se hubiesen usados nombres FQDN, quedarían así las líneas:

ns1.asir.com.       IN    A     192.168.1.10
mail.asir.com.      IN    A     192.168.1.11
prof.asir.com.      IN    A     192.168.1.12
www.asir.com.       IN    A     192.168.1.13

Lo habitual es escribir los registros A con nombres no FQDN.

ftp       IN    CNAME ftp.asir.net.

Los registros CNAME se utilizan para definir alias de RR A que ya existan. En el ejemplo se crea el alias ftp.asir.com para el registro A, en este caso externo al dominio, ftp.asir.net.

Otra forma de haber hecho lo mismo hubiese sido:

ftp.asir.com.       IN    CNAME    ftp.asir.net.