La generalidad de los administradores de red familiarizados con GNU/Linux consideran a BIND como la aplicación por excelencia para implementar un servicio de nombres de dominio. No obstante, de hace algunos años a la fecha vienen desarrollándose alternativas interesantes, como NSD, sobre la cual hablaremos un poco en este tutorial.

NSD es un servidor de DNS de alto rendimiento implementado desde cero por NLnetLabs. Es razonablemente compatible con BIND, es decir, pudiera tenerse un servidor maestro con BIND y un esclavo con NSD o viceversa. Además, consume considerablemente menos memoria que BIND, y al estar concebido solo como servidor autoritario,¹⁾ puede resultar potencialmente más seguro.

NSD utiliza una base de datos para almacenar los registros, lo cual permite un inicio rápido del servicio y facilita la detección de errores sintácticos y estructurales en los archivos de zonas, antes que se proporcionen al servicio. Actualmente algunos rootservers están utilizando NSD en lugar de BIND, lo cual ya dice bastante sobre la eficiencia, seguridad y robustez de esta aplicación.

A los efectos de este tutorial, supongamos que nuestro proveedor de servicios nos ha delegado la zona midominio.tld²⁾ y asignado el bloque de direcciones ipv4 203.0.113.8/29,³⁾ que pretendemos distribuir de la siguiente manera para proporcionar servicios a una WAN:

De modo que vamos a realizar una instalación de NSD en modo maestro y esclavo para que se mantengan sincrónicos.

Para instalar este servicio digamos en Debian o derivadas, podemos utilizar el siguiente comando:

sudo apt-get install nsd3

Adicionalmente, si deseamos podemos crear directorios personalizados para la ubicación de la base de datos y los archivos de zona:⁴⁾

cd /etc/nsd && sudo mkdir -p db zones

Configurar NSD es relativamente fácil, particularmente si no se desea implementar funcionalidades como DNSSEC. Todo lo que necesitamos hacer es editar el archivo de configuración, crear los archivos de zonas (que pueden tener cualquier nombre y pueden mantener la sintaxis de BIND), generar la base de datos e iniciar el servicio.

Primeramente, editemos el archivo de configuración (por defecto, /etc/nsd/nsd.conf) y coloquemos en su interior algo como esto:

server:
        debug-mode: no
        ip4-only: yes
        hide-version: yes
        database: "/etc/nsd/db/nsd.db"
        logfile: "/var/log/nsd.log"
        difffile: "/etc/nsd/db/ixfr.db"
        xfrdfile: "/etc/nsd/db/xfrd.state"
        pidfile: "/var/run/nsd.pid"
        statistics: 3600
        #username: "bind"
        zonesdir: "/etc/nsd/zones"
        verbosity: 0
        ip-address: 127.0.0.1
        ip-address: 203.0.113.10
 
zone:
        name: "midominio.tld"
        zonefile: "midominio.tld.zone"
        provide-xfr: 203.0.113.8/29 NOKEY
        notify: 203.0.113.11 NOKEY
 
zone:
        name: "113.0.203.in-addr.arpa"
        zonefile: "midominio.tld.reverse1.zone"
        provide-xfr: 203.0.113.8/29 NOKEY
        notify: 203.0.113.11 NOKEY
 
zone:
        name: "8/29.113.0.203.in-addr.arpa"
        zonefile: "midominio.tld.reverse2.zone"
        provide-xfr: 203.0.113.8/29 NOKEY
        notify: 203.0.113.11 NOKEY

Observarán que se ha anclado el servicio a dos interfaces de red, la local y una externa. De no incluirse la línea ip-address, el servicio escucha en todas las interfaces. Un detalle importante a tomar en consideración aquí es que cuando tenemos un bloque de direcciones con máscara 29, tenemos que utilizar un tipo de delegación llamada “sin clases” que tiene una sintaxis ligeramente más compleja, para esto hemos declarado en la configuración dos zonas inversas. El motivo lo explicaremos más adelante. La opción notify pudiera repetirse múltiples veces para notificar sobre cambios en las zonas a más de un esclavo, de haber varios en la misma subred.

Editemos ahora el archivo de la zona principal (/etc/nsd/zones/midominio.tld.zone):

$ORIGIN midominio.tld.
$TTL 1d ;  Tiempo de vida por defecto para los registros
 
@  0  SOA  ns1.midominio.tld.  hostmaster.midominio.tld. (
  2013070401  ; Número de serie (YYYYMMDDNN)
  6h          ; Tiempo de refrescar la información por parte del esclavo
  1h          ; Tiempo de reintento por parte del esclavo en caso de problemas
  4w          ; Tiempo de expiración de la información por parte del esclavo
  3h          ; Tiempo que deben permanecer cacheadas las respuestas negativas
  )
 
  NS   ns1
  NS   ns2
  MX   10  mail
  TXT  "v=spf1 a mx include:midominio.tld -all"
 
ns1      A      203.0.113.10
ns2      A      203.0.113.11
ns       CNAME  ns1
mail     A      203.0.113.12
webmail  A      203.0.113.13
www      A      203.0.113.14
*        CNAME  www

Como notarán, se ha incluido un registro para habilitar la protección SPF en nuestro servicio de correo (ver el documento RFC4408), se ha creado un registro de tipo CNAME para el nombre ns (algunas veces las consultas buscan este nameserver en particular), y al final se ha colocado otro CNAME con un comodín, lo cual simplemente significa que cualquier petición a un subdominio inexistente, apuntará en su lugar hacia el sitio web. Para más información sobre la configuración de un DNS, consultar los documentos RFC1033, RFC1034 y RFC1035. Adicionalmente, resulta conveniente consultar el documento RFC1912 para evitar errores que suelen cometerse.

Los valores de tiempo pueden establecerse en segundos (la norma) o mediante abreviaturas que pueden combinarse (por ejemplo, 2h30m) y se permiten tanto en minúsculas como mayúsculas:

Un detalle que conviene aclarar: el tiempo de vida por defecto para los registros (establecido en la variable TTL que aparece al principio del archivo de zona) es uno de los valores más importantes a tener en cuenta, pues define el tiempo tras el cual los clientes deben actualizar la información que tienen en su cache, y también define cuan rápidamente los cambios en nuestro dominio se propagarán a los nameservers padres. Si la información de nuestro dominio cambia con relativa frecuencia, puede ser conveniente un valor bajo, pero si este no es el caso y especialmente si tenemos una red con muchos equipos, puede mejorarse el rendimiento aumentando este valor hasta un día, una semana, o más (el límite máximo permisible es 2^31 - 1, es decir 2147483647, ¡unos 68 años!). Aumentar el valor del TTL reduce las consultas de DNS y hace que los servicios (navegación y demás) funcionen ligeramente más rápido. Un buen truco puede ser mantener el TTL por defecto en un valor relativamente alto (digamos de uno a varios días) y cuando tengamos previsto hacer cambios en el DNS, reducir el TTL unos días antes a un valor bajo (digamos entre unos minutos y una hora), de esta manera cuando se realicen los cambios en el DNS, todos los clientes y nameservers padres se actualizarán rápidamente, luego podrá aumentarse nuevamente el TTL a su valor para “producción”. Por cierto, si bien según el documento RFC1035 el registro SOA debe tener un TTL de valor cero para evitar que se cachee, posteriormente el documento RFC2181 clarificó que esto no es un requerimiento.

Otra cosa a tener presente es que el último valor del registro SOA originalmente se conocía como Default TTL o Minimum TTL, pero su efecto ha cambiado con el paso del tiempo y actualmente (de acuerdo al documento RFC2308) se utiliza para definir el tiempo que deben almacenarse en la cache las respuestas negativas (se recomienda un valor entre 1 y 3 horas), de modo que ya no debería utilizarse este campo para establecer el valor predeterminado o mínimo de los registros.

Obviamente, cualquier cambio en los archivos de zonas requiere actualizar también el número de serie, para que el nameserver esclavo se sincronice debidamente. Y a propósito del esclavo, conviene tener en el registro SOA un valor de expiración alto, de esta manera si el servidor primario falla, el esclavo tendrá una copia en la cache que durará por el tiempo que se haya definido en el valor de expiración. Mantener nameservers secundarios con un valor de expiración bajo contradice el propósito de estos.

Pasemos ahora a la delegación de la zona inversa. Algo importante a tomar en consideración aquí es que la delegación de zonas inversas usualmente se realiza para las redes con máscaras 8, 16 ó 24. Sin embargo, como vimos anteriormente, nos habían asignado un bloque de direcciones ipv4 con máscara 29 (8 direcciones con 6 utilizables, de ellas una para el router). ¿Qué hacer entonces? Bueno, pues para las máscaras 25 o superiores, debe implementarse algo conocido como delegación sin clases (para más detalles, ver el documento RFC2317). No todas las implementaciones de DNS permiten este tipo de delegación, pero afortunadamente, NSD sí las permite.

Sin más, declaremos entonces nuestra primera zona inversa (/etc/nsd/zones/midominio.tld.reverse1.zone):

$ORIGIN 113.0.203.in-addr.arpa.
$TTL 1d ;  Tiempo de vida por defecto para los registros
 
@  0  SOA  ns1.midominio.tld.  hostmaster.midominio.tld. (
  2013070401  ; Número de serie (YYYYMMDDNN)
  6h          ; Tiempo de refrescar la información por parte del esclavo
  1h          ; Tiempo de reintento por parte del esclavo en caso de problemas
  4w          ; Tiempo de expiración de la información por parte del esclavo
  3h          ; Tiempo que deben permanecer cacheadas las respuestas negativas
  )
 
  NS  ns1.midominio.tld.
  NS  ns2.midominio.tld.
 
10  CNAME  10.8/29
11  CNAME  11.8/29
12  CNAME  12.8/29
13  CNAME  13.8/29
14  CNAME  14.8/29

Como podemos apreciar, hemos colocado registros de tipo CNAME a las verdaderas direcciones inversas que nos han asignado (no es imprescindible colocar la dirección completa, ya que el sistema es capaz de hacer el completamiento automáticamente gracias a la variable ORIGIN definida al inicio de la zona). El único propósito de esta zona es replicar la delegación sin clases que usualmente hace el proveedor (en este caso, Etecsa) para que en caso de hacerse una consulta a la zona inversa desde una PC en la misma subred de direcciones que nos han asignado, la respuesta apunte hacia las direcciones correctas, de lo contrario podríamos encontrar problemas con las búsquedas inversas.

En el segundo archivo de zona inversa (/etc/nsd/zones/midominio.tld.reverse2.zone), colocaremos los verdaderos registros para resolver las direcciones ip a sus nombres de dominio.

$ORIGIN 8/29.113.0.203.in-addr.arpa.
$TTL 1d ;  Tiempo de vida por defecto para los registros
 
@  0  SOA  ns1.midominio.tld.  hostmaster.midominio.tld. (
  2013070401  ; Número de serie (YYYYMMDDNN)
  6h          ; Tiempo de refrescar la información por parte del esclavo
  1h          ; Tiempo de reintento por parte del esclavo en caso de problemas
  4w          ; Tiempo de expiración de la información por parte del esclavo
  3h          ; Tiempo que deben permanecer cacheadas las respuestas negativas
  )
 
  NS  ns1.midominio.tld.
  NS  ns2.midominio.tld.
 
10  PTR  ns1.midominio.tld.
11  PTR  ns2.midominio.tld.
12  PTR  mail.midominio.tld.
13  PTR  webmail.midominio.tld.
14  PTR  www.midominio.tld.

Con lo anterior, el servicio debería quedar configurado. Ahora, generemos la base de datos:

sudo nsdc rebuild

Este comando en realidad lo que hace es llamar al comando zonec, que también podemos invocar directamente con parámetros:

sudo zonec -vv

La ventaja de disponer de estos comandos es que antes de iniciar el servicio, se realiza una validación básica de la configuración y las zonas.⁵⁾ Una vez generada la base de datos con los registros de nuestras zonas, iniciamos el servicio:

sudo nsdc start

Podríamos comprobar si el servicio se está ejecutando con el siguiente comando:

sudo ps -C nsd

Deberían aparecer uno o más procesos, lo cual significa que el servicio está ejecutándose. Otra variante que también podría utilizarse:

sudo nsdc running

Si el servicio se está ejecutando, el comando anterior no devuelve nada, en caso contrario devuelve un mensaje indicando que el servicio está detenido.

La instalación y configuración del equipo esclavo es muy parecida a la del maestro, excepto que no es necesario llenar las zonas, sino solamente ajustar el archivo de configuración:

server:
        debug-mode: no
        ip4-only: yes
        hide-version: yes
        database: "/etc/nsd/db/nsd.db"
        logfile: "/var/log/nsd.log"
        difffile: "/etc/nsd/db/ixfr.db"
        xfrdfile: "/etc/nsd/db/xfrd.state"
        pidfile: "/var/run/nsd.pid"
        statistics: 3600
        #username: "bind"
        zonesdir: "/etc/nsd/zones"
        verbosity: 0
        ip-address: 127.0.0.1
        ip-address: 203.0.113.11
 
zone:
        name: "midominio.tld"
        zonefile: "midominio.tld.zone"
        allow-notify: 203.0.113.10 NOKEY
        request-xfr: AXFR 203.0.113.10 NOKEY
 
zone:
        name: "113.0.203.in-addr.arpa"
        zonefile: "midominio.tld.reverse1.zone"
        allow-notify: 203.0.113.10 NOKEY
        request-xfr: AXFR 203.0.113.10 NOKEY
 
zone:
        name: "8/29.113.0.203.in-addr.arpa"
        zonefile: "midominio.tld.reverse2.zone"
        allow-notify: 203.0.113.10 NOKEY
        request-xfr: AXFR 203.0.113.10 NOKEY

Como podemos apreciar, las cláusulas “zone:” en lugar de tener las opciones provide-xfr y notify como en el maestro, tienen como contraparte las opciones allow-notify y request-xfr, para especificar respectivamente qué equipos pueden enviar notificaciones y a cuáles consultar para buscar actualizaciones en las zonas.

Ahora podríamos realizar algunas comprobaciones del servicio DNS con comandos como dig, host o nslookup. Por ejemplo:

dig @203.0.113.10 midominio.tld. any +norecurse +multiline
host -t any midominio.tld 203.0.113.10
nslookup -q=any midominio.tld 203.0.113.10

Incluso, NLnetLabs ha desarrollado una librería independiente llamada ldns que proporciona entre otras cosas el comando drill, una alternativa para hacer consultas que no depende de las librerías de BIND (a diferencia de dig), ni tampoco está anclado a NSD. Para instalar la librería, podemos ejecutar el siguiente comando:

sudo apt-get install ldnsutils

Utilizar entonces el comando drill es sencillo:

drill midominio.tld. @203.0.113.10 any

Este tutorial pudiera ampliarse con la utilización de IXFR y DNSSEC, la ejecución de NSD de forma chrooted, el uso de direcciones ipv6, la interacción de NSD con BIND, etc.

• Autor: Hugo Florentino