BIND (Berkeley Internet Name Domain), como implementación del prorocolo DNS, es el servidor de este tipo más comunmente usado en internet. La necesidad administrativa de montar un servidor de nombres DNS hacen de BIND una de las primeras opciones a tener en cuenta y desde este artículo se explotará la instalación y configuración del mismo.

Un poco de historia

BIND es uno de los primeros servidores DNS creados al albor de internet. Encargado y patrocidano por la DARPA (Defense Advanced Research Projects Agency) a principios de los años ochenta, cuando el Departameto de Defensa estadounidense estaba implicado en el desarrollo de la red de redes, el proyecto queda finalmente en manos de DEC/Digital (Digital Equipment Corporation), que se encarga de desarrollarlo casi por completo. Finalmente es uno de los empleados de Digital, Paul Vixie, quien retomará el proyecto y lo incluirá en el consorcio ISC (Internet Software Consortium), responsable actual del mantenimiento del programa.

Si bien las primeras implementaciones del servidor BIND (en concreto las versiones 4 y 8) mostraban una cantidad de vulnerabilidades exagerada (como casi todo el software nacido a la par que internet), la versión 9 del producto ya no presenta tantas complicaciones. Escrita desde cero para superar las dificultades técnicas de antiguos desarrollos, dicha versión fue impulsada por proveedores UNIX, deseosos de que BIND mantuviera la competencia con Microsoft en igualdad de condiciones y por el Ejército de los Estados Unidos, que desarrolló funcionalidades relativas a la seguridad como DNSSEC (DNS Security Extensions), al darse cuenta de que la seguridad dentro del servicio DNS es algo a tener muy en cuenta.

Características

BIND 9 ofrece un servidor de nombres de dominio a través de named, una bibioteca de resolución de sistemas de nombres de dominio y un paquete de herramientas para monitorizar el correcto funcionamiento de todo el sistema (bind-utils).

Entre sus principales características se incluyen los protocolos de seguridad como DNSSEC o TSIG (Transaction SIGnature) y el soporte de IPv6, nsupdate (actualizaciones dinámicas), notificación DNS, rndc flush, vistas y procesamiento en paralelo. Gracias a su arquitectura mejorada se ha conseguido una mejor portabilidad entre sistemas.

Introducción a DNS

DNS (Domain Name System) es una base de datos distribuida y jerárquica que almacena información relativa a los nombres de dominio en internet o gestiona nombres de equipos y servicios en redes locales. El uso más común de una base de datos DNS es la de asignación de nombres de dominio o de servidores de correo a direcciones IP. Dicha asignación se utilizará para la localización de dichos equipos/servicios de una manera sencilla y sin tener que recordar cada vez la dirección real. La información dada se puede consultar a la inversa (una dirección IP se traduce en un nombre almacenado en la base de datos).

Los componentes principales de un sistema DNS son los siguientes:

• Clientes DNS - Encargados de realizar las consultas pertinentes a las bases de datos de los servidores DNS.
• Servidores DNS - Contestan a las peticiones realizadas por los clientes. Dicha contestación se hará consultando la base de datos propia o haciendo una consulta recursiva a otro servidor DNS.
• Zonas de autoridad - Son los espacios de nombres de dominio donde se almacenan los datos. Generalmente, una zona de autoridad comprende, al menos, un nombre de dominio y todos sus subdominios, pudiendo estos últimos estar en sus zonas de autoridad propias.

Servidores DNS

Dentro de este apartado, contamos con dos tipos de servidores:

• Servidor Maestro/Primario - Consulta los datos del dominio en la base de datos del propio servidor donde se aloja.
• Servidor Esclavo/Secundario - Consulta los datos de una caché que rellena a partir de los datos de un servidor Primario. Dicho proceso se denomina Trasferencia de zona.

Es muy recomendable tener, al menos, tres servidores DNS configurados (RFC 2182) para un correcto funcionamiento del sistema de resolución. Un servidor actuaría como nodo DNS Primario y los otros dos como nodos secundarios, que replicarían y respaldarían la base de datos principal. Obviamente, en un entorno local que no necesita servir datos fuera de la red (internet) no es tan necesario.

Como hemos apuntado anteriormente, un servidor DNS puede hacer dos tipos de consultas:

• Consultas Iterativas - El servidor DNS responde a la consulta del cliente desde los datos guardados en su base de datos o en las bases de los sistemas locales. Si dicha información no se encuentra disponible, la petición se reenviará hacia otros servidores, hasta encontrar la Zona de Autoridad válida que resuelva la petición. En principio, la carga de la consulta recae sobre el cliente.
• Consultas Recursivas - El servidor DNS proporciona, si existe, la respuesta a la solicitud. Para ello, hará tantas consultas iterativas como sea necesario hasta dar con el dato solicitado. Las peticiones son transparentes a la máquina del cliente.

Zonas de Autoridad

Un servidor DNS Primario carga su información desde una Zona de Autoridad. Dicha zona abarca un nombre de dominio y, si los nombres de los subdominios no están delegados, también los incluirá. Toda la información se almacenará localmente en un fichero que contendrá alguno de estos tipos de registros:

Las zonas a resolver serán las siguientes:

• Zonas de Reenvío - Devuelven direcciones IP para búsquedas sobre nombres FQDN (Fully Qualified Domain Name). Es importante apuntar aquí que, en el caso de tratarse de dominios públicos, hay una responsabilidad por parte de la autoridad misma del dominio (el Registrar del WHOIS) para crear dicha zona de reenvío.
• Zonas de Resolución Inversa - Devuelven nombres FQDN para búsquedas sobre direcciones IP. Como en el caso anterior, la responsabilidad de crear la Zona de Autoridad recae sobre la autoridad misma del segmento (si hacemos un WHOIS sobre una dirección IP, obtendremos a la autoridad de todo el segmento de direcciones).

Instalación de BIND

La gran mayoría de distribuciones de linux ya tienen un paquete precompilado de BIND en sus repositorios, así que haremos uso de herramientas como yum o apt-get para su instalación (no obstante, podemos descargar y compilar la última versión de BIND de la dirección www.isc.org/index.pl?/sw/bind/):

Configuración

Antes de comenzar con los ficheros de configuración del programa, es preciso tener claros los datos siguientes:

• Nombre de dominio a resolver.
• Servidor de nombres principal (DNS Maestro/SOA). Dicho nombre tiene que estar plenamente resuelto y, por supuesto, tiene que ser FQDN.
• Lista de servidores de nombres (NS) para la redundancia. Igual que en el caso anterior, deberán estar plenamente resueltos y ser FQDN.
• Cuenta de correo del administrador de la zona. Cuenta real y distinta de la zona a resolver.
• Servidor de correo (MX) con registro A (no vale un CNAME).
• IP predeterminada del dominio.
• Subdominios y direcciones IP asociadas a los mismos (www, mail, ftp, ...).

+ Ficheros de zonas

Un fichero de zonas tiene, en principio, el siguiente aspecto:

Los nombres de dominio terminan en un punto para indicar que son nombres absolutos.

Los registros del fichero son los siguientes:

• IN NS - Relaciona un nombre de subdominio con un servidor de nombres responsable de la zona. Podremos formar así una jerarquía de nombres DNS. Hay que poner el correspondiente registro A para traducir el nombre del servidor a una dirección IP si se usa este registro.
• IN A - Traducción de máquina a dirección IP.
• IN PTR - Traducción de dirección IP a máquina.
• IN CNAME - Alias de las máquinas.

Los distintos ficheros de zonas se encuentran, en una distribución tipo Red-Hat / Fedora en la rama /var/named (o /var/named/chroot/var/named). A continuación vamos a ver un fichero de zona para la configuración típica de un dominio:

Se observa claramente cómo se han creado dos servidores de nombre con autoridad mediante la sentencia NS (con @ se evita tener que escribir el dominio completo de nuevo), ns1.dominio_ejemplo.org. y ns2.dominio_ejemplo.org. y se crean también dos redirectores de correo MX con prioridad de 10 y 20.

Tras el espacio, comienza la traducción de los nombres en direcciones IP. Si atendemos a la última línea, podemos observar el uso claro de la sentencia CNAME. En este caso, el servidor DNS traduciría la dirección redirect.dominio_ejemplo.org hacia la dirección apuntada en dominio_ejemplo.no-ip.info, lo cual puede resultar tremendamente útil en caso de tener que hacer uso de alguna IP dinámica en alguno de los servidores.

En último lugar, nos encontramos con un listado de localización de servicios que hace uso de la sentencia SRV. Dicha sentencia permite la consulta de un dominio y un servicio asociado al mismo. La asociación de servicios se define en el estándar RFC 2052.

+ Traducción inversa

Es requerido en un servidor DNS que las direcciones IP se conviertan igualmente en nombres (reverse lookup). Dicha traducción se usará por parte de diferentes servidores y es muy aconsejable tener definida una zona de este tipo en un servidor DNS. Para la resolución inversa usaremos el pseudo-dominio in-addr.arpa. quedando la dirección pública 55.127.215.in-addr.arpa. (la parte de red de la dirección IP escrita al revés más el dominio). Un fichero de zona de resolución inversa para el dominio anterior quedaría como sigue:

Para la zona inversa de localhost podríamos generar un fichero parecido al siguiente:

Hay que tener en cuenta que la zona de resolución inversa del dominio sólo funcionará en el caso de que ésta quede delegada convenientemente por el proveedor de servicios que se ocupa del rango de direcciones. Si es imprescindible, y el autor de este artículo considera que siempre debería serlo, tener una zona de resolución inversa para nuestra dirección o rango de direcciones, será imperativo contactar con el proveedor de servicios para que de de alta un registro NS para la zona en concreto.

+ El archivo named.conf

El archivo named.conf se sitúa en la rama /etc o /etc/bind y estructura toda la información de zonas del servidor DNS. A grandes rasgos, podemos dividir el fichero en tres secciones: options, que define opciones de configuración general, loggin, que especifica la salida de la información y zone, donde se incorporan los datos generales de los archivos de zonas que ya hemos explicado en los puntos anteriores.

• options

Habitualmente, las opciones incluidas por defecto en los ficheros de configuración de cada distribución para el apartado options son más que suficientes para arrancar el servidor DNS sin ningún tipo de problema. Dichas opciones son demasiado extensas para explicarlas en este artículo, así que es muy recomendable acceder a la página del manual referente a named.conf y leer para qué sirve cada opción y si alguna de ellas puede servir a nuestros propósitos. Una opción importante a tener en cuenta es la de fordwarders, que se usará para suministrar al servidor DNS las direcciones IP de los redireccionadores encargados de consultar ciertas direcciones a otros servidores DNS, cuando éstas no esten disponibles de forma local. De usarse el apartado, deberá quedar como el ejemplo siguiente:

forwarders {
200.33.146.209;
200.33.146.217;
};

• zone

Bajo la definición de zone se darán de alta todas las zonas para nuestros dominios. Habrá que definir siempre una primera zona raíz (un punto), que informará de todos los servidores raíz a nuestro servidor DNS, y seguidamente se darán de alta todas y cada una de las zonas necesarias para el funcionamiento correcto de nuestro servidor. La zona raíz quedará como sigue (el fichero de zona puede consguirse en la dirección ftp.internic.net/domain/named.cache):

zone "." {
type hint;
file "named.ca";
};

Un ejemplo de definición de zona general podría ser el siguiente:

zone "dominio_ejemplo.org" {
type master;
file "/var/named/dominio_ejemplo.org.zone";
allow-query { any; };
allow-transfer { slaves; };
};

Con type master se establece el servidor como maestro/primario (slave establecerá el tipo secundario). file indica la ruta de acceso al fichero de configuración de la zona declarada. allow-query { any; } especifica que es posible hacer consultas externas a la zona. allow-transfer { slaves; } transfiere la configuración de la zona hacia los servidores secundarios especificados en el ACL slaves dentro del fichero de configuración de la forma siguiente:

acl "slaves" {
215.66.73.59;
};

La deficinión de un servidor esclavo, que se limitará a replicar los ficheros de zonas del servidor maestro, podría seguir el ejemplo siguiente para una de sus zonas:

zone "sec.dominio_ejemplo.org" {
type slave;
file "/var/named/sec.dominio_ejemplo.org.zone";
allow-query { any; };
masters { 60.89.100.1; };
};

El fichero sigue las mismas trazas que el ejemplo del maestro, a excepción de la sentencia masters, donde es aconsejable especificar la dirección IP del servidor primario para que el servidor esclavo solicite la transferencia de zonas (puede usarse acl, pero sólo suele existir un servidor maestro en la red en casi la mayoría de los casos).

• logging

Bajo la sentencia logging se definen los canales y archivos hacia donde se dirigirán los mensajes de auditoría de BIND. Una sentencia logging se contruye de la forma siguiente:

logging {
definición_de_canal;
definición_de_canal;
...
category nombre_categoría {
nombre_canal;
nombre_canal;
...
};
};

A continuación ponemos un ejemplo de logging para establecer los mensajes de aviso y las consultas al servidor y redirigirlos hacia distintos ficheros de texto:

logging {
channel warning
{
file "/var/log/server-dns/warning" versions 3 size 100k;
severity warning;
print-category yes;
print-severity yes;
print-time yes;
};
channel general_dns
{
file "/var/log/server-dns/log" versions 3 size 100k;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { warning; } ;
category queries { general_dns; } ;
};

Para profundizar más en la configuración de mensajes consultaremos el manual oficial de BIND en la página de la ISC (www.isc.org).

Transferencia de zonas, seguridad y rndc

Habiéndose establecido la configuración correcta para cada uno de los servidores secundarios y corriendo ya el primario, se establecerá una transferencia segura de zonas del servidor maestro a cada uno de los servidores secundarios. Dicha transferencia generará de forma automática los ficheros de zonas en los servidores secundarios, siempre y cuando se hayan establecido las opciones allow-transfer { slaves; } y masters { x.x.x.x; } en las distintas definiciones de zonas del fichero named.conf, tanto en el servidor maestro como en los esclavos. La transferencia se hará de forma segura y será preciso añadir al fichero named.conf los siguientes parámetros, que se encargarán de controlar las tranferencias mediante una certificado de seguridad:

controls {
inet 127.0.0.1 allow { localhost; } keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
server 215.66.73.59 {
keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
key "2007041102.liberaliatempus.com.tsigkey." {
algorithm hmac-md5;
secret "bsty5LYDsO8infm+n2JNsw==";
};

En el servidor secundario (215.66.73.59) también han de añadirse los parámetros siguientes:

controls {
inet 127.0.0.1 allow { localhost; } keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
server 60.89.100.1 {
keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
key "2007041102.liberaliatempus.com.tsigkey." {
algorithm hmac-md5;
secret "bsty5LYDsO8infm+n2JNsw==";
};

Con la sentencia controls se limita el uso de BIND al entorno localhost, generalmente tras haber realizado una conexión mediante SSH y ejecutado el comando rndc, que servirá para administrar el demonio named. Mediante la sentencia server establecemos que la comunicación con cierta dirección IP ha de realizarse utilizando una clave única y cifrada. Las direcciones en el servidor primario (60.89.100.1) y el secundario (215.66.73.59) se apuntaran entre ellas para permitir la comunicación mediante claves. La sentencia key establece la configuración de la clave de seguridad. Dicha configuración se obtiene durante el proceso de generación de la clave que se hace mediante la ejecución del siguiente comando:

[root@jeke ~]# dnssec-keygen -a HMAC-MD5 -b 512 -n HOST 2007041102.liberaliatempus.com.tsigkey.

Tras la ejecución se habrán generado dos ficheros: K2007041102.liberaliatempus.com.tsigkey..+157+41204.key y K2007041102.liberaliatempus.com.tsigkey..+157+41204.private. El contenido de la clave se encuentra en el fichero con extensión private después de la etiqueta Key: . Dicho contenido se entrecomillará tras el parámetro secret, tal y como aparece en el ejemplo.

Para finalizar, hay que completar la configuración de rndc mediante la edición del fichero /etc/rndc.conf, que quedará de la forma siguiente si atendemos a los ejemplos dados más arriba:

options {
default-server localhost;
default-key "2007041102.liberaliatempus.com.tsigkey.";
};
server localhost {
key "2007041102.liberaliatempus.com.tsigkey.";
};
key "2007041102.liberaliatempus.com.tsigkey." {
algorithm hmac-md5;
secret "bsty5LYDsO8infm+n2JNsw==";
};

Tanto en el fichero named.conf como en el fichero rndc.conf se puede omitir por seguridad la declaración de key y suministrar dicha información a través de un fichero externo. Dicho fichero contendrá las líneas de declaración utilizadas para definir la clave y éstas serán sustituidas por la sentencia include "fichero_clave"; El ejemplo anterior quedaría como sigue:

options {
default-server localhost;
default-key "2007041102.liberaliatempus.com.tsigkey.";
};
server localhost {
key "2007041102.liberaliatempus.com.tsigkey.";
};
include "/etc/rndc.key";

El fichero /etc/rndc.key contendrá todas las líneas sustituidas tal cual y su uso debería ser muy restringido (# chmod 600 /etc/rndc.key).

Podemos comprobar que todo es correcto a nivel de rndc mediante la ejecución del siguiente comando, debiendo repasar los ficheros de configuración si la salida difiere de la mostrada:

[root@jeke ~]# rndc reload
server reload successful

Con esta configuración, la transferencia de zonas qeudará transferida a petición de los servidores secundarios, que verán actualizadas sus zonas sin tener que reescribir los ficheros. Apuntar igualmente que el software de servidor DNS de Microsoft no es compatible con el algoritmo HMAC-MD5, al menos a día de la escritura de este artículo, por lo que no comunicará correctamente con los servidores configurados con BIND.

Puertos

BIND utiliza dos puertos en sus comunicaciones, el 53 TCP, que se usa para las transferencias y el 53 UDP, que se utiliza para las consultas. Será necesario no alicar reglas de cortafuegos sobre estos puertos si queremos que el servicio DNS funcione de forma correcta. La herramienta rndc utiliza el puerto 953 UDP para el control remoto, pero no es recomendable redireccionarlo a través del router si se siguen las indicaciones del artículo a nivel de seguridad.