instalación y configuración de un servidor dns utilizando bind 8.3.1

INSTALACIÓN Y CONFIGURACIÓN DE UN SERVIDOR DNS
UTILIZANDO BIND 8.3.1
Aclaración previa
El presente documento ha sido redactado en base a mis conocimientos y a otros
documentos que he leído en Internet. Es posible que algunas cosas no sean del todo
exactas o que admitan matizaciones, en cuyo caso agradecería cualquier comentario que
me sea remitido a la dirección de correo [email protected] para rectificarlas o
concretarlas.
Introducción
El objetivo del presente documento es describir la instalación de un servidor de nombres
basado en el servidor bind versión 8.3.1 del ISC. Trataré de comentar en detalle la
compilación y la instalación del demonio sobre plataforma Linux enjaulado con chroot
para obtener un mayor grado de seguridad. Además intentaré describir algunas de las
configuraciones más comunes.
Antes de entrar en materia conviene revisar algunos conceptos para evitar confusiones.
Todos hemos oído hablar del DNS pero en ocasiones mezclamos y confundimos funciones
bien distintas que desempeña un servidor DNS: resolución no recursiva y resolución
recursiva. Para mayor claridad a partir de ahora hablaremos de servidor “zonal” cuando
un DNS cumpla la función de resolución no recursiva y de un servidor “caché” en caso de
resolución recursiva.
Servidor zonal
Un servidor zonal tiene como objetivo responder aquellas consultas que recibe sobre
zonas que tiene configuradas localmente (bien como primario, bien como secundario).
Existen dos tipos distintos de servidores zonales: primarios y secundarios. A efectos de
funcionalidad ambos son idénticos y la diferencia radica únicamente en que es en el
primario donde tenemos que realizar los cambios del contenido de una zona porque el
secundario simplemente la replica. Por este motivo solo puede, o mejor dicho “debe”,
existir un primario para cada zona y uno o varios secundarios (NOTA: existe un límite en
el número de secundarios asociados a una zona en función del tamaño del paquete de
respuesta a una consulta DNS).
En el caso de un servidor zonal primario “cerrado” (que no permita las transferencias
zonales a cualquiera) es imprescindible establecer una relación de confianza con los
secundarios para permitir la replicación de las zonas.
Servidor caché
Un servidor caché se encarga de responder las consultas que recibe de sus clientes a
base de consultar a los servidores zonales adecuados o bien consultando en su propia
caché si la consulta ya ha sido realizada con anterioridad y aún no ha expirado.
Todos tenemos configurado uno o dos servidores DNS caché en nuestra pila TCP/IP. En
equipos unix figuran en el fichero /etc/resolv.conf (nameserver X.X.X.X) y en windows se
configuran en las casillas correspondientes a las direcciones del servidor DNS dentro de
las propiedades del protocolo TCP/IP. También existe la posibilidad de que nuestro
proveedor de acceso o un servidor DHCP de nuestra red nos asigne automáticamente las
direcciones de los servidores DNS caché.
Es habitual que se nos pregunte en la configuración de los DNS caché por el primario y el
secundario. Este tipo de jerarquía (“primario” y “secundario”) no tiene nada que ver con
la existente entre servidores zonales de un mismo dominio, sino que hace referencia a la
prioridad con la que se realizan las consultas a uno u otro servidor por parte de la pila
TCP/IP de nuestro sistema operativo.
Servidores mixtos (zonal y caché)
Un servidor DNS puede configurarse como servidor zonal y caché a la vez, aunque no es
una configuración que recomiende, salvo en casos muy controlados, puesto que puede
darse el caso que responda autoritativamente consultas sobre zonas que tiene
configuradas pero no delegadas.
Por poner un ejemplo del inconveniente que he citado vamos a ver un ejemplo típico de
un traslado de dominio entre dos proveedores. En este caso el registrador de nombres
puede exigirnos tener la zona configurada previamente a la realización del traslado, o
simplemente por nuestro interés lo configuraremos cuanto antes porque no sabemos
cuándo se hará efectivo el mismo. Si la configuración del dominio en el nuevo DNS no es
exactamente igual que en el servidor que actualmente tiene la zona delegada nos
encontraremos con toda una suerte de inconvenientes porque los clientes del DNS caché
(que en ese caso actuará como zonal por tener configurada la zona en local) verán una
información sobre el dominio mientras que el resto de Internet verá otra (la del servidor
que actualmente tenga delegada la zona).
Resolución directa y resolución inversa
Existen fundamentalmente dos tipos de zonas (dominios) en función del tipo de
resolución a efectuar: directas e inversas. Además de éstas hay algunas más, como por
ejemplo el “hint” en la que aparecen los root servers (aquellos que sirven el dominio
“root”) y que se incluye de forma explícita en todos los servidores DNS.
La resolución directa hace referencia a aquellas consultas en las que preguntamos qué
dirección IP tiene un nombre determinado, por ejemplo ¿qué dirección IP tiene
www.google.com?. Este tipo de preguntas las realiza constantemente nuestra pila TCP/IP
cada vez que navegamos.
Por el contrario, la resolución inversa se encarga de resolver qué nombre está asociado
con una determinada dirección IP, por ejemplo ¿qué nombre de host corresponde a la
dirección IP 216.239.39.100?. La resolución inversa no la emplean habitualmente
nuestros equipos (cliente) sino algunos servidores, fundamentalmente con dos objetivos:
bien escribir en los logs nombres en lugar de direcciones IP, bien establecer controles de
acceso basados en la existencia de un nombre asociado a una IP o de la equivalencia de
las consultas nombre a IP e IP a nombre (denominada doble resolución inversa).
Dentro de la jerarquía del DNS que veremos un poco más adelante se definió una zona
del árbol donde se almacena la información necesaria para la resolución inversa. Esta
zona es concretamente la “in-addr.arpa.”, y de ella dependen distintas zonas organizadas
que se van correspondiendo con los distintos grupos de octetos posibles en una dirección
IP.
Jerarquía del espacio de nombres
El DNS es un sistema de base de datos jerárquica distribuida a través de varios
servidores. La jerarquía del espacio de nombres es comparable a la del sistema de
ficheros de nuestro disco duro, considerando que los directorios son equivalentes a las
zonas (dominios) y los ficheros a los registros de cada zona. Siguiendo con esta analogía,
los separadores de directorios son el carácter “/” o “\” (u otros, según el S.O.) mientras
que en el DNS el separador de zonas (o dominios, como se prefiera) es el carácter punto
“.”.
La jerarquía dentro de un nombre de host se interpreta de derecha a izquierda y además
comienza por el dominio “.” (similar al directorio “/” o “\” del sistema de ficheros).
Habitualme nte no se pone el “.” al final de los nombres de dominio ni de host puesto que
se entiende que queda implícito (por ejemplo: el dominio “google.com” se entiende que
es “google.com.”, terminado en punto). El dominio raíz es por tanto el dominio “.”, del
que cuelgan los dominios denominados de primer nivel: “com.”, “net.”, “org.”, etc.
NOTA: En la configuración de una zona en el servidor DNS debemos tener presente que
para especificar una referencia absoluta debemos incluir el “.” al final de un nombre de
host ya que de otro modo se entendería siempre relativo al dominio que se está
configurando.
Tal y como comentamos unos párrafos antes, el espacio de nombres para la resolución
inversa depende de la zona “in-addr.arpa.” y en él la jerarquía se representa justo a la
inversa que en el direccionamiento IP. Así, el registro que define el nombre asociado a la
dirección IP “1.2.3.4” será el “4.3.2.1.in-addr.arpa.”, con la dirección IP justo al revés, y
se encontrará dentro de la zona “3.2.1.in-addr.arpa.”. Como la delegación de la
autoridad se realiza por zonas a primera vista resulta imposible delegar la resolución
inversa de bloques de direcciones inferiores a una clase C, por ejemplo solo del rango
1.1.1.0 a 1.1.1.31. Esto no es del todo cierto ya que existen me canismos para poder
hacerlo empleando alias (registros CNAME) y creando una nueva subzona que es
realmente la que se delega. Aquellos interesados en este último aspecto pueden
consultar el apartado Q.5.5 de la “unnoficial FAQ” del DNS
(http://www.intac.com/~cdp/cptd-faq/) para obtener más detalles.
Ahora que hemos comentado la jerarquía existente solo nos queda aclarar cómo se
distribuye la “autoridad” dentro del espacio de nombres entre distintos servidores,
conocido como “delegación”. Para cada zona (dominio) existe un servidor autoritativo
configurado como primario y normalmente uno o más como secundarios. La delegación
de una zona consiste simplemente en especificar dentro de una zona (por ejemplo
“com.”) la subzona (por ejemplo “algo.com.”) concreta que queremos delegar con los
servidores DNS zonales autoritativos (primario y secundario/s, aunque a este nivel no se
especifica cuál desempeña cada una de las funciones) que servirán su contenido. Estos
servidores DNS podrán a su vez delegar nuevas subzonas (por ejemplo “cosa.algo.com.”)
dependientes jerárquicamente de la subzona delegada.
Funcionamiento del DNS: ¿cómo se realiza la resolución?
Cada uno de los tipos de servidor DNS que hemos comentado antes (zonal, cache y
mixto) tienen un comportamiento distinto y aquí es donde podemos comprobar las
funciones bien diferenciadas que tiene cada uno de ellos.
En el caso de un servidor zonal, como hemos comentado anteriormente, cuando recibe
una consulta busca entre las zonas que tiene configuradas como locales (para las que es
autoritativo) y si encuentra la respuesta la envía. Si el servidor no encuentra la respuesta
devuelve una referencia a los root servers para que quien le ha realizado la consulta lo
busque a partir de ellos y da por respondida la consulta. Este modo de funcionamiento se
denomina habitualmente no recursivo, aunque yo prefiero denominarlo “zonal”.
Cuando un servidor caché recibe una consulta lo primero que hace es mirar en una caché
en la que anota las respuestas a preguntas que ha recibido anteriormente. Es importante
hacer notar que los registros almacenados en la caché expiran de acuerdo con los
parámetros que el administrador de cada zona concreta ha configurado, es decir,
depende del DNS zonal y no del caché. Por este motivo podemos tener en la caché
registros que expiran a los 15 minutos y registros que lo hacen a las 48 horas. Si el
registro se encuentra en la caché se envía la respuesta y se da por finalizada la consulta.
En el caso de que un servidor caché no disponga de la respuesta a la pregunta que
recibe, bien porque no la hubiese recibido nunca con anterioridad, bien porque si la
hubiera recibido pero haya expirado, el servidor comienza una búsqueda a través de uno
o varios DNS zonales hasta que encuentra la respuesta (positiva o negativa). Este
funcionamiento se denomina habitualmente recursivo, ya que el propio servidor caché se
encarga de buscar la respuesta directamente y devuelve el resultado que encuentra, sin
que el cliente que realizó la consulta tenga que preocuparse de nada.
En el funcionamiento recursivo de un DNS caché siempre se sigue la misma pauta, que
consiste en recorrer la jerarquía del espacio de nombres, consultando a los distintos DNS
zonales en busca de la respuesta a la consulta. Por ejemplo, si recibe una pregunta por la
dirección IP del host www.google.com, primero busca en uno (o varios, en serie o en
paralelo, dependiendo del tipo de servidor) de los root servers (los que sirven el dominio
“.”) y le pregunta por la dirección de los servidores zonales para la primera zona
(comenzando a leer por la derecha), que en nuestro ejemplo sería “com.”. Una vez que
sabe cuáles son los DNS zonales del dominio “com.”, le lanza una consulta a uno (o
varios) para saber quién tiene delegada la siguiente zona, que sería “google.com.”. Una
vez que obtiene la respuesta se dirige nuevamente a los servidores zonales del dominio
“google.com.” y les pregunta por el registro www.google.com. . Una vez que obtiene la
respuesta se la envía al cliente que realizó la consulta y la almacena en la caché.
NOTA: El proceso que se acaba de describir para un funcionamiento recursivo no es
“exactamente” así, pero he preferido describirlo de este modo para no complicarlo.
Como se puede comprobar la resolución de nombres para un servidor caché es un
proceso costoso, con una carga de trabajo elevada y considerable consumo de ancho de
banda. Por este motivo conviene utilizar como servidores DNS caché aquellos servidores
que no estén excesivamente cargados pero que sean utilizados por un número
suficientemente elevado de usuarios que enriquecen la caché. De este modo
obtendremos una resolución más ágil y seremos más “ecológicos” con Internet
reaprovechando recursos, disminuyendo el consumo de ancho de banda y aliviando un
poco la carga de los root servers.