207.1.- Configuración básica de un servidor DNS

DNS (Domain Name System) es un protocolo de resolución de nombres que permite hacer la relación entre un nombre de host y una dirección IP. Fue creado en 1983 por Paul Mockapetris y Jon Postel, y definido originalmente en las RFC 882 y 883 (que fueron después reemplazadas por las RFC 1034 y 1035). Se ha convertido en el estándar de facto para la resolución de nombres en Internet.

1. Principios de DNS

DNS es un sistema de resolución de nombres estructurado en arborescencia. Esta arborescencia virtual está organizada en dominios y en subdominios. Cada dominio o subdominio constituye un nudo de la arborescencia y puede contener nombres asociados a direcciones IP. Existe también una rama de la arborescencia que permite resolver direcciones IP en nombres de host o de servicios (resolución inversa).

Los dominios y subdominios los gestionan servidores de nombres DNS que cooperan entre ellos para dar a los clientes DNS la relación entre nombres y direcciones IP. Estas últimas pueden ser direcciones IPv4 o IPv6.

La arborescencia DNS puede ser privada o pública. La arborescencia DNS más grande es la de Internet.

1.1.- Clientes y servidores DNS

Un cliente DNS (resolver) interroga a un servidor DNS para conocer la o las direcciones IP que corresponden a un nombre (resolución de nombre), o al contrario, para conocer el o los nombres que corresponden a una dirección IP (resolución de dirección o resolución inversa). El servidor DNS responde si tiene elementos suficientes, en caso contrario interrogará a otros servidores DNS y responderá al final a su cliente, ofreciéndole los elementos solicitados o un código de respuesta de fallo de la resolución.

Un nombre puede ser el nombre de máquina (nombre de host) o un nombre de servicio (por ejemplo, servidor de nombres, servidor de mensajería …). Un nombre puede corresponder a distintas direcciones IP, una dirección IP puede corresponder a distintos nombres. Para poder gestionar un gran número de nombres, en evolución perpetua, de manera fiable y descentralizada, el sistema DNS está estructurado en un arborescencia que combina diferentes conjuntos independientes, gestionados por servidores DNS responsables de una parte de la arborescencia y cooperando entre ellos.

Esta organización ofrece muchas ventajas:

Gestión dinámica y descentralizada: la actualización de la información se hace únicamente en el servidor DNS responsable de la parte correspondiente a la actualización.

Tolerancia a fallos: los servidores DNS responsables de una zona pueden replicar sus datos hacia uno o varios servidores DNS, asegurando la tolerancia a fallos (excepto para las actualizaciones) y el reparto de la carga.

Autonomía de gestión: el conjunto de los nombres/direcciones que se tienen que gestionar está distribuido entre entidades independientes entre ellas, pero que cooperan. No es necesaria una organización centralizada y única que administre el conjunto de los servidores. Si una parte de la arborescencia presenta un problema o está mal configurada, no afectará a las otras partes que se encuentran en el mismo nivel de la arborescencia.

1.2.- Nombres de dominios completos (FQDN)

La raíz de la arborescencia se representa con el carácter punto. Directamente bajo la raíz se encuentran los dominios de primer nivel, TLD (Top Level Domains). Dentro de cada uno de ellos, encontramos múltiples dominios y subdominios. Para especificar el nivel de un dominio en la arborescencia, se utiliza la sintaxis siguiente:

NombreDominioN.NombreDominioN-1.NombreDominioN-2.[…].NombreDominio1[.] Al contrario de la convención para las arborescencias de sistemas de archivos, partimos del nivel más bajo y subimos hacia la raíz. Esta última puede ser o no explícitamente especificada por el carácter punto.

Un dominio (o subdominio) corresponde a conjuntos de nombres, particularmente, nombres de máquinas, llamados nombres de host.

Un nombre de host corresponde a una o distintas direcciones IP, en versión 4 y/o 6. Para identificar de manera única un nombre de dominio, especificamos su FQDN (Fully Qualified Domain Name), subiendo toda la arborescencia del sistema DNS al que pertenece, según la sintaxis vista anteriormente. Según los casos, el carácter punto de la raíz es obligatorio o no.

Ejemplo

FQDN de un nombre de dominio de un servidor HTTP:

2. Los tipos de servidores DNS

Los servidores DNS aseguran dos funciones: gestionar los nombres de dominios DNS (nombres de hosts y nombres de servicios) y la relación con las direcciones IP correspondientes, y responder a las solicitudes de resolución de nombre o de dirección emitidas por los clientes DNS. Para ello, distinguimos diferentes tipos de servidores DNS, sabiendo que un mismo servidor puede desempeñar distintos roles.

2.1.- Servidor de nombres DNS primario o secundario

Los nombres DNS están gestionados por servidores DNS. Cada conjunto de nombres, que puede constituir un dominio completo o un subdominio, se encuentra bajo la responsabilidad de un servidor DNS maestro (master server), llamado también servidor primario o principal (primary server), siendo un servidor autoritativo (authoritative server). Este servidor es el único que puede tomar en cuenta las actualizaciones de los nombres de dominio de los que se ocupa. Puede duplicar, en solo lectura, su base de nombres hacia uno o distintos servidores no maestros (non-master server), llamados también servidores secundarios (secondary server). Estos también serán autoritativos en el dominio o el subdominio, pero no pueden gestionar directamente las actualizaciones de los nombres de dominio.

2.2.- Servidor DNS de caché o transitario (forwarder)

Algunos servidores DNS no gestionan directamente los nombres. Su rol es tomar en cuenta las solicitudes de resolución de nombres emitidas por los clientes DNS, interrogando a otros servidores DNS. Cuando hayan obtenido una respuesta, la almacenan temporalmente en su caché de nombres y la devuelven al cliente.

2.3.- Servidor de caché

Su rol ha sido descrito anteriormente. Cuantas más solicitudes diferentes haya gestionado, más eficaz será su labor, porque si la respuesta a la solicitud del cliente se encuentra en su caché y no ha consumido su tiempo de validez, podrá responder directamente sin tener que interrogar a otro servidor DNS.

2.4.- Servidor transitario (forwarder)

Este servidor DNS no trata él mismo las solicitudes que recibe de los clientes, sino que las transfiere a otro servidor DNS. Este último trata la solicitud y responde al servidor de DNS que le ha transferido la solicitud; el servidor transitario puede, entonces, responder a su cliente.

Esta técnica permite a un servidor DNS interno dentro de una organización tomar en cuenta la resolución de los nombres exteriores de la organización, transmitiendo las solicitudes a un servidor DNS externo. Los clientes internos de la organización no tendrán directamente acceso a servidores DNS externos.

3. Gestión de la arborescencia DNS por los servidores DNS

Los servidores DNS reflejan la estructura de la arborescencia del sistema DNS, gracias a las nociones de autoridad y de delegación de autoridad. También se apoyan en los servidores de la raíz de la arborescencia, que desempeñan un rol específico en la resolución de nombres.

3.1.-. Autoridad y delegación de autoridad

Para cada dominio, un servidor DNS tiene que ejercer la función de autoridad, es decir tener la responsabilidad de gestionar los nombres que pertenezcan a ese dominio. Sin embargo, un servidor DNS puede dar una delegación de autoridad a un subconjunto (o subdominio) del dominio del que es responsable. Esto permite distribuir la gestión de los nombres, garantizando la coherencia de la arborescencia: un servidor DNS que tiene autoridad sobre un dominio debe conocer todos los nombres del dominio y todos los servidores DNS de los subdominios y de su dominio, servidores a los que ha delegado la autoridad sobre esos subdominios.

La mayoría de las veces, los servidores que tienen autoridad se encuentran duplicados, uno de ellos sería el servidor principal, y el otro el servidor secundario, para asegurar de esta manera la tolerancia a fallos.

3.2.- Los servidores DNS de la raíz (root servers)

Los servidores DNS situados en la raíz de la arborescencia desempeñan un papel particular en la resolución de nombres. En efecto, cuando un servidor DNS recibe una solicitud de resolución para un nombre de dominio sobre el que no tiene autoridad, interrogará a uno de los servidores DNS de la raíz para conocer el servidor del nombre del dominio de primer nivel solicitado. Para ello, debe estar configurado con los nombres y las direcciones IP de sus diferentes servidores de nombres de la raíz.

Ejemplo

Los nombres y direcciones IPv4 de los servidores de la raíz del sistema DNS de Internet están declarados en un archivo que se encuentra por defecto con BIND:

3.3.- Los dominios de primer nivel (Top Level Domains)

Los dominios de primer nivel (TLD, Top Level Domain) se sitúan justo bajo la raíz del sistema DNS. Al principio no eran muy numerosos y estaban organizados por dominios funcionales: .com, .org, .net, .int, .edu, .gov y .mil

Después se añadieron dominios geográficos (por país: fr, us, uk, de, etc.), y más tarde se implantaron un gran número de otros identificadores de dominios.

Todos estos dominios están gestionados por servidores DNS, los cuales deben estar declarados como servidores de la raíz y tienen que conocer los servidores DNS de los dominios de nivel inmediatamente inferior, a los que han dado una delegación de autoridad en el subdominio.

3.4.- El dominio de resolución inversa in-addr.arpa.

Esta rama de la arborescencia tiene como objetivo asegurar la resolución de dirección o la resolución inversa. Para ello, las direcciones están estructurados bajo la forma de una arborescencia, en el interior de un dominio llamado in-addr.arpa., un nombre está estructurado en tantos elementos como bytes tenga la dirección, según la sintaxis: z.y.x.w.in-addr.arpa.

donde w, x, y y z corresponden a los cuatro bytes de una dirección IPv4, en orden inverso.

Ejemplo

Para buscar el nombre DNS de una máquina cuya dirección IP es 20.1.0.250, escribiremos 250.0.1.20.in-addr.arpa.

Esta arborescencia está gestionada por los servidores DNS, en paralelo con la arborescencia de los nombres de dominio.

4. Mecanismo de la resolución de nombres

La resolución de nombres es el mecanismo esencial que permite a un cliente DNS obtener la lista de las direcciones IP asociadas un nombre DNS. Si hacemos abstracción de los mecanismos de caché y de los servidores DNS transitorios, el principio de base es el siguiente:

Un cliente DNS tiene que estar configurado para conocer la dirección IP de al menos un servidor de DNS directamente accesible.

Si una aplicación necesita resolver un nombre DNS, solicitará al cliente DNS del sistema (el resolver, generalmente una función de la biblioteca de sockets del sistema) que se ocupe de ello.

El cliente DNS envía una solicitud de resolución de nombre DNS, usando el protocolo de transporte UDP, hacia el puerto bien conocido 53 del primer servidor DNS de su archivo de configuración (/etc/resolv.conf). El cliente queda en espera de una respuesta, durante un cierto tiempo. Si no ha recibido ninguna respuesta después de este tiempo, puede interrogar al servidor DNS siguiente, si tiene otro más declarado en el archivo de configuración.

El servidor DNS trata la solicitud:

Si tiene autoridad en el dominio solicitado, consulta la base de nombres, bien sea para encontrar directamente el nombre solicitado, bien para determinar el servidor DNS al que ha delegado la autoridad para ese subdominio. Responde directamente al cliente o transmite la solicitud al servidor DNS del subdominio, que le responderá con la lista de las direcciones que corresponden al FQDN (o un mensaje de tipo NOT FOUND, si ese nombre no está referenciado).

Si no tiene autoridad, el servidor DNS efectuará una búsqueda recursiva: interroga a uno de los servidores de la raíz DNS, que le responderá con la lista de servidores de nombres del dominio de primer nivel correspondiente al FQDN buscado.

A continuación, el servidor va a reiterar su solicitud, nivel por nivel, hasta encontrar el servidor DNS que tenga autoridad en el subdominio buscado, que le devolverá la lista de las direcciones correspondientes al FQDN (o un mensaje de tipo NXDOMAIN, si el nombre no está referenciado).

Finalmente, el servidor DNS dará la respuesta al cliente.

Cuando un servidor DNS ha obtenido una respuesta a su solicitud, la guardará en su caché, para poder utilizarla más tarde si recibe la misma solicitud. La duración de validez de una respuesta en el caché está configurada por un parámetro asociado al registro de la relación del nombre de do-minio/dirección, llamada TTL (Time To Live).

4.1.- Ejemplo

Solicitud de resolución del nombre DNS www.aulautil.com:

5. Zonas DNS

La información acerca de los objetos gestionados por un servidor DNS están almacenadas en un archivo llamado archivo de zona. Cada zona constituye un conjunto de elementos bajo la autoridad de un servidor DNS principal, que puede opcionalmente transmitir una copia de este archivo, en solo lectura, a uno o a varios servidores secundarios

En el archivo de zona están referenciados los nombres de los hosts y los nombres de servicios asociados a direcciones IP. También encontramos la información referente a los servidores de nombres de la zona y, si fuera necesario, los servidores de nombres que tienen una delegación en los subdominios de esta zona.

Los archivos específicos de zona permiten gestionar la resolución inversa, de direcciones IP hacia nombres DNS.

Los archivos de zona están constituidos por registros de diferentes tipos, según la naturaleza de la información almacenada.

5.1.- Registro de zona (tipo SOA)

Este registro define la zona y sus atributos, entre los que podemos encontrar:

Nombre de la zona.

FQDN del servidor primario.

Correo electrónico del administrador.

Número de serie (para gestionar las actualizaciones de los servidores secundarios).

5.2.- Registros de recursos

Los elementos relativos a los nombres de host o de servicio y las direcciones IP correspondientes se llaman registros de recursos (RR, Resource Record). Pueden ser de distintos tipos. Los tipos principales están descritos a continuación.

Registro de dirección (tipo A o AAAA)

Estos registros contienen la información relativa a los nombres de host y su dirección IP. El tipo A corresponde a las direcciones IPv4, el tipo AAAA a las direcciones IPv6.

Registro de puntero (tipo PTR)

Este tipo de registro mantiene el enlace entre una dirección IP y un nombre DNS. Lo encontramos en los archivos de zona de búsqueda inversa.

Registro de alias (tipo CNAME)

Este tipo de registro (Canonical name) permite hacer una correspondencia entre un nombre (alias) y un nombre FQDN.

Registro de servidor de nombres (tipo NS)

Este tipo de registro (Name server) permite declarar los servidores de nombres de un dominio o de un subdominio.

5.3.- Zona de resolución inversa in-addr.arpa.

Esta zona gestiona la información que permite efectuar la resolución inversa de las direcciones de los nombres de dominio de la zona. Corresponde a un subdominio del dominio in-addr.arpa., para la red/subred de las direcciones IP de la zona de nombres.

Un archivo de zona inversa contiene esencialmente registros de recursos de tipo PTR, que realizan el vínculo entre una dirección IP en notación inversa in-addr.arpa. y un nombre DNS.

6. Los servidores DNS en Linux

Varios programas implementan un servidor DNS en Linux, el más usado es BIND (Berkeley Internet Name Domain).

6.1.- BIND

Concebido por la Universidad de Berkeley para Unix BSD en los años 80, BIND es uno de los primeros servidores DNS. Está mantenido y desarrollado por el ISC (Internet Systems Consortium), un consorcio público sin ánimo de lucro.

Su versión actual es la número 9, reescrita completamente al principio de los años 2000 para implementar una arquitectura más fácil de proteger. Es el servidor de nombres DNS más utilizado hoy día, particularmente en Linux.

Tenemos que conocer bien el servidor BIND para la certificación.

6.2.- Otros servidores DNS

Otros tipos de servidores DNS se usan en entornos DNS, entre ellos:

Dnsmasq
Este programa ofrece un peculiar doble servidor DHCP y DNS transitario (forwarder). Lo encontramos implementado a menudo en equipos de tipo router de Internet, porque permite distribuir las direcciones IP privadas para las máquinas del abonado (a través del servidor DHCP) y dar acceso a los servidores DNS de Internet a través del servidor DNS.

Djbdns
Desarrollado desde 2001 por Daniel J. Bernstein (el creador del servidor de mensajería Gmail), este programa tiene como objetivo resolver múltiples problemas de seguridad encontrados en BIND. Está aconsejado por algunas distribuciones Linux. Se ha efectuado un fork bajo el nombre de dbndns, en el marco del proyecto Debian.

PowerDNS
Programa propietario creado en 1993, se ha convertido en open source en 2003. Provee servicios DNS repartidos entre múltiples servidores con equilibrado de carga (load balancing).

7. Configuración básica de un servidor primario DNS BIND

El servidor BIND es ejecutado por el daemon named. Normalmente se inicia durante el arranque del sistema y su archivo de configuración por defecto es /etc/named.conf (o /etc/bind/named.conf). Su configuración es más o menos compleja en función de su o de sus roles: servidor primario, secundario, servidor de caché y/o servidor transitario. En esta parte, vamos a ver la configuración básica de un servidor DNS primario simple. El firewall de los sistemas Linux está, a menudo, configurado por defecto para bloquear las conexiones entrantes en los puertos usados por DNS, 53 UDP y 53 TCP. Hay que autorizar los mensajes entrantes hacia esos puertos para que el servidor DNS pueda recibir las solicitudes de los clientes o de otros servidores DNS.

7.1.- El archivo named.conf

El archivo de configuración named.conf está generalmente completado por archivos incluidos a través de la directiva include.

Este archivo define las opciones del servidor BIND y su rol, así como la ubicación de los diferentes archivos de zona gestionados por ese servidor (ya que se trata de un servidor principal), y el archivo de declaración de los servidores DNS de la raíz de la arborescencia.

Un servidor primario gestiona al menos una zona para los nombres de dominio o de subdominio en los que ejerce la autoridad, así como la zona de búsqueda inversa correspondiente.

Estos archivos de zona están declarados en el archivo named.conf o en uno de los archivos incluidos, con su ubicación y tipo.

Un archivo de configuración named.conf contiene un conjunto de directivas, las más frecuentes están descritas a continuación.

La directiva include

Esta directiva permite incluir un archivo en el archivo de configuración principal.

La directiva options

La directiva options define un conjunto de opciones según la sintaxis siguiente:

options { <opción>; [<opción>; …] }; Entre las numerosas opciones existentes, las principales son:

allow-query {lista};

Lista de los clientes autorizados a interrogar al servidor sobre sus zonas de autoridad (por defecto: todos).

allow-query-cache {lista};

Lista de los clientes autorizados a interrogar al servidor sobre su caché (por defecto: todos).

blackhole {lista};

Lista de clientes prohibidos (por defecto: ninguno).

directory Path;

Directorio de los archivos de datos (por defecto: /var/named/).

forwarders {lista};

Lista de los servidores DNS hacia los que hay que transferir las solicitudes que queden fuera de las zonas de autoridad.

forward Tipo;

Tipo de forwarding (first, only) en el caso de un servidor DNS transitario.

listen-on {lista};

Direcciones IPv4 de las interfaces en las que el servidor espera las solicitudes (por defecto: todas).

listen-on-v6 {lista};

Direcciones IPv6 de las interfaces en las que el servidor espera las solicitudes (por defecto: todas).

pid-file Path;

Camino de acceso hacia el archivo que contiene el PID del daemon named.

recursion yes|no;

Especifica si el servidor gestiona las solicitudes recursivas (por defecto: yes).

statistics-file NombreArchivo;

Camino de acceso hacia el archivo de estadísticas (por defecto: /var/named/named.stats).

La directiva zone

Esta directiva especifica el nombre de dominio o de subdominio que corresponde a la zona (el punto final es facultativo), sus características y la ubicación del archivo de zona correspondiente.

Los principales atributos son:

file Nombre;

Nombre del archivo de zona (en el directorio de los archivos del servidor).

type Tipo;

Tipo de zona: hint (zona especial para los servidores raíz), master (servidor principal) y slave (servidor secundario).

masters {Dirección};

Dirección del servidor principal para esta zona (en el caso de que haya un servidor secundario).

allow-query {lista};

Lista de los clientes autorizados a efectuar solicitudes sobre esta zona (por defecto: todos).

allow-transfer {lista};

Lista de los servidores secundarios autorizados a solicitar la transferencia del archivo de zona (por defecto: todos).

allow-update {lista};

Lista de los hosts autorizados a solicitar una actualización dinámica en el archivo de zona (por defecto: ninguno).

Ejemplo

Archivo /etc/named.conf (simplificado) en una distribución Rocky 9:

El servidor tiene el rol de servidor de caché y no gestiona ninguna zona, excepto la zona “.” que contiene las direcciones y los nombres de los servidores DNS de la raíz, así como las zonas correspondientes a la red de loopback (named.rfc1912.zones). Escucha en el puerto bien conocido 53, solamente para las solicitudes de la máquina local (dirección loopback 127.0.0.1). La opción recursion yes lo autoriza a efectuar solicitudes de resolución recursiva, interrogando sucesivamente servidores DNS hasta obtener una respuesta de un servidor DNS que tenga autoridad sobre el dominio del nombre buscado.

7.2.- Los archivos de zona por defecto

El paquete de software BIND proporciona generalmente varios archivos de zona.

Un archivo de zona corresponde a la raíz del sistema DNS (zona “.”), en el que están declarados los diferentes servidores de nombres de la raíz del sistema DNS Internet.

Si su servidor DNS es puramente interno en su organización (es decir que no tiene acceso a Internet), hay que modificar el contenido de esta zona para declarar los servidores DNS de la raíz de su arborescencia DNS privada.

Dos archivos de zona corresponden a los nombres de hosts de la red de loopback así como a sus direcciones (zona de búsqueda inversa): zone “localhost” y zone “127.in-addr.arpa”.

Los dos otros archivos de zona de búsqueda inversa corresponden a las direcciones de broadcast y al identificador de la red IP local: zone “0.in-addr.arpa” y zone “255.in-addr.arpa”.

7.3.- Ejemplo

Archivo de configuración de un servidor primario BIND, ejerciendo autoridad sobre la zona del dominio lpic2test.com.

8. Configuración de un servidor de caché o transitario

Algunos servidores DNS no gestionan ninguna parte de la arborescencia del sistema DNS al que pertenecen. Su único rol es el de responder a las solicitudes de sus clientes. Se trata de servidores de caché y/o servidores transitarios (forwarder).

8.1.- Configuración de servidor de caché

Un servidor DNS de caché asegura la resolución de nombres, pero no gestiona ninguna zona.

Este efectúa búsquedas recursivas en los servidores DNS de la arborescencia, para responder a las solicitudes de sus clientes, y almacena las respuestas obtenidas, temporalmente, en su caché. De esta manera podrá responder directamente si una solicitud es relativa a un nombre o a una dirección (resolución inversa) que ya se encuentra en su caché, con la condición de que la vida de la información no haya expirado (TTL).

La opcion recursion yes permite al servidor BIND desempeñar el rol de servidor de caché.

Ejemplo

Archivo de configuración de un servidor de caché BIND.

Exceptuando la zona de los servidores DNS de la raíz y las zonas por defecto, no hay ninguna otra zona declarada.

8.2.- Configuración un servidor transitario (forwarder)

Un servidor transitario (forwarder) no efectúa directamente búsquedas recursivas, si no que transfiere las solicitudes de resolución de sus clientes hacia uno o varios servidores DNS que se encargarán de efectuar las solicitudes de resolución recursiva.

Un servidor puede hacer ese rol para todas las solicitudes, o solamente para las solicitudes relativas a una parte de la arborescencia. Puede gestionar un dominio privado, interno, y difundir hacia servidores DNS externos para los dominios externos (los de Internet, en particular).

El servidor transitario almacena las respuestas obtenidas temporalmente en su caché. De esta manera puede responder directamente si una solicitud es relativa a un nombre o a una dirección que se encuentra en su caché, siempre y cuando la duración de vida de la información no haya llegado a expiración (TTL).

La opción forwarders permite especificar el o los DNS a los que hay que transferir las solicitudes de los clientes DNS.

Ejemplo

Exceptuando las zonas por defecto, no hay ninguna otra zona declarada. El servidor DNS que efectuará las solicitudes a los diferentes servidores DNS de la arborescencia DNS tiene la dirección IP 192.168.0.254.

9. Monitorización de un servidor DNS BIND

El daemon named es arrancado por un script de inicio init system V o por systemd. Si su configuración cambia, habría que reiniciarlo o pedirle que vuelva a cargar su configuración. Para ello, podemos usar el script de inicio o systemd. También podemos enviar la señal HUP (señal 1) al daemon a través del comando kill.

El comando rndc, proporcionado con el paquete BIND, también permite interactuar con el daemon.

9.1.- Recarga de la configuración del servidor

Si el daemon named ha sido lanzado con un script de inicio, le podemos pedir que vuelva a cargar su configuración gracias al argumento reload del script.

Ejemplo

Con una distribución Debian 10:

Si el daemon named ha sido lanzado con systemd, podemos pedirle que vuelva a cargar su configuración gracias al argumento reload del comando systemctl.

Ejemplo

Con una distribución Debian 10:

Con una distribución Rocky 9:

Otro método consistiría en enviar una señal 1 (HUP) al proceso que ejecuta named, lo que provocará que recargue su configuración.

Ejemplo

El PID del proceso que ejecuta el servidor BIND está almacenado en el archivo definido por la opción pid-file del archivo named.conf:

9.2.- Control del archivo de configuración: named-checkconf

El comando named-checkconf permite comprobar la sintaxis del contenido del archivo de configuración named.conf.

El comando devuelve 0 si la sintaxis del contenido del archivo es correcta, en el caso contrario muestra 1, con un mensaje de error.

Ejemplo

El archivo de configuración es correcto desde el punto de vista de la sintaxis.

Quitamos un ; al final de una línea de directiva:

El comando muestra un error y devuelve 1.

9.3.- El comando rndc

El comando rndc permite interactuar con el daemon named.

Sintaxis

Ejemplo

Recargamos la configuración:

Observando la hora de la última configuración, constatamos que el servidor named ha cargado la configuración correctamente.

El comando se usa para administrar servidores DNS remotos, con la la opción -S Servidor. Sin embargo, por razones de seguridad, es necesario que este uso sea configurado en los dos servidores, con un intercambio de claves TSIG. Esta configuración puede hacerse con el comando rndc-confgen.

10. Prueba de un servidor DNS BIND

Para comprobar el funcionamiento correcto de un servidor DNS, podemos usar diferentes comandos. En primer lugar, vamos a usar los comandos host y dig para hacer comprobaciones básicas.

10.1.- El comando host

El comando host permite interrogar a un servidor DNS para resolver un nombre o una dirección.

Sintaxis

Ejemplo

10.2.- El comando dig

El comando dig (Domain Information Groper) permite comprobar de manera detallada el funcionamiento de un servidor DNS. Dispone de muchas opciones para gestionar diferentes aspectos de la resolución de nombres.

En esta parte del capítulo, presentamos un uso básico del comando.

En las distribuciones de tipo Debian, el comando forma parte del paquete dnsutils.

Sintaxis

Ejemplo

Búsqueda inversa directamente a través de una dirección:

207.2.- Creación y gestión de las zonas DNS

Un servidor primario DNS gestiona una o varias zonas. Cada una corresponde a un dominio o a un subdominio de una arborescencia DNS. Opcionalmente puede proporcionar una copia de un archivo de zona, en solo lectura, a uno o a distintos servidores secundarios . Estos últimos pueden dar respuestas autoritativas a las solicitudes de resolución relacionadas con los registros de la zona. Sin embargo, solo el servidor primario puede actualizar el contenido del archivo de zona.

Un servidor DNS puede ser servidor primario para una o varias zonas y servidor secundario para otras zonas.

Para cada archivo de zona debería corresponder un archivo de zona de búsqueda inversa, que permite la resolución inversa (dar el nombre DNS relacionado con una dirección IP). También será necesaria la presencia de un archivo de zona de búsqueda inversa para las direcciones IPv6.

El contenido de un archivo de zona obedece a una sintaxis precisa y exacta, el mínimo error puede hacer que el servidor DNS no lo cargue.

11.- Archivo de zona de búsqueda

La zona tiene que estar declarada en el archivo de configuración named.conf por una directiva zone especificando el nombre de la zona, su tipo y el nombre del archivo de zona.

El archivo de zona tiene que encontrarse en el directorio de datos declarado en el archivo de configuración named.conf, con la opción directory (por defecto /var/named o /var/cache/bind).

Ejemplo

Declaración de una zona en el archivo named.conf:

Se trata de una zona de tipo master, para la que el servidor DNS desempeña el rol de servidor principal.

Un archivo de zona contiene un registro de tipo SOA, que describe las características de la zona, y un conjunto de registros de recursos (tipo RR) para cada nombre de host o de servicio de la zona.

En un archivo de zona, los comentarios van desde el carácter ; hasta el final de la línea. El separador de los campos es un conjunto de caracteres espacio o tabulación, el separador de los registros está al final de la línea (excepto si el registro continúa a lo largo de varias líneas entre paréntesis).

11.1.- Registro de zona (tipo SOA)

Este registro define la zona y sus atributos. Su sintaxis es la siguiente:

Ejemplo

Registro SOA de la zona del dominio lpic2test.com.:

El correo electrónico del administrador es admin@lpic2test.com.

El carácter @ reemplaza a lpic2test.com, el nombre del dominio asociado a la zona en el archivo /etc/named.conf:

11.2.- Registros de recursos

Los elementos relativos a los nombres de host o de servicios y a las direcciones IP correspondientes están declarados en los registros de recursos (RR, Resource Record). El formato de un registro es el siguiente:

Ejemplo

Registros de recursos del archivo de zona del dominio lpic2test.com., con dos servidores que se reparten los diferentes servicios:

11.3.- Ejemplo de archivo

Este archivo de zona de búsqueda corresponde al dominio lpic2test.com., con dos servidores DNS:

12.- Archivo de zona de búsqueda inversa

El archivo de zona de búsqueda inversa (forward lookup) tiene la misma estructura que un archivo de zona directa, pero sus registros de recursos son de tipo PTR.

12.1.- Declaración de la zona en named.conf

El nombre de la zona está formado por los bytes de la parte de red de la dirección IP, ordenados en sentido inverso y con el sufijo del nombre de dominio « .in-addr.arpa ».

Ejemplo

12.2.- Registro SOA

Es necesario un registro de tipo SOA, al igual que para una zona de búsqueda de nombres.

Ejemplo

Registro SOA de una zona de búsqueda inversa, administrada por el servidor principal rocky9.lpic2test.com.:

12.3.- Registros de recursos

Hay que declarar los servidores DNS de la zona de búsqueda inversa, con registros de tipo NS.

Los registros de tipo PTR asocian a la parte del host de la dirección IP un nombre DNS. Se le añade automáticamente a la dirección como sufijo el nombre de la zona.

Ejemplo

Registros de recursos de diferentes hosts en la zona de búsqueda inversa de la red 192.168.0.0/24:

12.4.- Ejemplo de archivo

Este archivo de zona de búsqueda inversa corresponde a la red 192.168.0.0/24, con dos servidores DNS:

13.- Gestión de zonas secundarias

Cada Zona DNS es en general copiada hacia servidores secundarios, para asegurar un buen nivel de tolerancia a fallos. Un servidor secundario puede responder a las solicitudes de resolución de nombres o de direcciones de elementos de su zona, pero no puedo actualizarla.

La zona está configurada para especificar la periodicidad con la que el servidor secundario interroga al servidor primario para obtener el número de versión actual del archivo de zona. Si el archivo de zona del servidor secundario no está actualizado, el servidor solicita al servidor primario la transferencia de su archivo de zona.

a. Declaración de la zona secundaria en named.conf La zona tiene que estar declarada en el archivo named.conf, con el tipo slave y el o los servidores a los que hay que solicitar el número de versión del archivo de zona actual. Durante la carga de la configuración, el daemon named contacta con uno de los servidores especificados y recupera el archivo de zona.

El servidor especificado en el atributo masters no tiene por qué ser el servidor principal, puede ser un servidor secundario, lo que permite repartir la carga de las transferencias de zona. Si hay distintos servidores especificados, se contactará con ellos en el orden de declaración.

Ejemplo

Declaración de una zona para un servidor secundario, en una distribución Debian 10, en el archivo /etc/bind/named.conf.local:

Por defecto, los archivos de zona almacenados por un servidor DNS secundario se encuentran en formato binario, poco legible. Se puede configurar la zona en el servidor secundario para que el archivo transferido desde el servidor principal esté en formato de texto. Hay que añadir la directiva siguiente en la declaración de la zona:

masterfile-format text;

14.-. Delegación de zona

La delegación de zona tiene como objetivo confiar la responsabilidad de un subdominio de la zona a otros servidores DNS. Es así como se gestiona la arborescencia de un sistema DNS como el de Internet. Los servidores DNS de los dominios de primer nivel (TLD) delegan la gestión de los dominios de segundo nivel a servidores DNS, estos últimos delegan la gestión de sus subdominios, etc.

En el archivo de zona del servidor delegatario, es necesario que haya un registro de tipo NS y un registro de tipo dirección (A o AAAA) para cada servidor DNS del subdominio delegado. El registro de tipo de dirección se llama DNS asociado (glue record), porque permite conocer la dirección IP del o de los servidores delegados al servidor DNS. Estos últimos son la autoridad en el subdominio delegado (con un servidor primario y uno o varios servidores secundarios).

La configuración de la zona delegada, en el servidor principal delegado, será parecida a la que se ha visto anteriormente.

Ejemplo

Definición de servidores DNS delegados para el subdominio intra del dominio lpic2test.com, en el archivo de zona delegataria:

15. Control de un archivo de zona

Los comandos named-checkzone y named-compilezone permiten comprobar la sintaxis del contenido del archivo de zona cuyo nombre y camino de acceso han sido utilizados como argumento: named-checkzone [Opciones] NombreZona CaminoArchivoZona
named-compilezone [Opciones] NombreZona CaminoArchivoZona El comando named-compilezone además puede convertir en salida el archivo de zona de un formato binario a un formato de texto, para leer un archivo de zona de servidor secundario o, por el contrario, optimizar su tiempo de carga.

Ejemplo

El archivo de zona es correcto desde el punto de vista de la sintaxis.

Modificamos un registro quitándole el carácter punto al final de un FQDN:

El comando muestra el error. Podemos constatar que en ausencia del carácter ’.’ final, el nombre de dominio de la zona es automáticamente añadido al FQDN, lo que hace que sea incorrecto.

16.- Pruebas de un servidor DNS

La configuración de los servidores DNS es relativamente compleja, y un error de sintaxis en uno de los archivos de configuración puede provocar que el servidor no arranque. También hay que configurar los diferentes clientes, a través del archivo /etc/resolv.conf, incluyendo los mismos servidores DNS.

Distintos comandos permiten comprobar el buen funcionamiento de los servidores DNS, primarios, secundarios, de caché o de tránsito para la resolución de nombres y para la resolución inversa.

16.1.- El comando nslookup

Este comando de origen Unix ha sido, durante mucho tiempo, la herramienta más eficaz para comprobar los servidores DNS. En Linux, está considerado como en vía de obsolescencia, y es remplazado por el comando dig.

El comando puede funcionar en modo línea de comandos (con opciones y argumentos) o en modo interactivo si se ejecuta sin argumentos.

Sintaxis

Ejemplo

Interrogación del servidor BIND de la máquina local:

Interrogación del servidor DNS 8.8.8.8 (ofrecido por Google):

Interrogación del servidor DNS local sobre un nombre de su propia zona:

La respuesta es autoritaria, al contrario que en las interrogaciones anteriores.

16.2.- El comando dig

El comando dig permite comprobar exhaustivamente el funcionamiento de un servidor DNS. Dispone de numerosas opciones para gestionar diferentes aspectos de la resolución de nombres.

Sintaxis

Ejemplo

Interrogación del servidor BIND de la machine local:

Interrogación del servidor DNS 8.8.8.8 (proporcionado por Google):

Interrogación del servidor DNS local, sobre un nombre de su zona:

207.3.- Seguridad de un servidor DNS

Un servidor DNS es susceptible de recibir solicitudes desde las redes en las que participa, solicitudes que pueden venir de clientes DNS o de otros servidores DNS. Por lo tanto, puede constituir un punto de entrada hacia la organización de la que depende y ser utilizado para recuperar información sensible (direcciones y nombres de máquinas o de servicios de red).

Por otro lado, en la hipótesis de un fallo de seguridad en el programa ejecutable de BIND, un servidor DNS podría ser utilizado para tomar el control del sistema en el que se ejecuta, o para proporcionar información sensible (cuentas de usuarios, etc.).

Existen diferentes técnicas que permiten proteger un servidor BIND:

Limitar los clientes y servidores DNS autorizados a comunicar con él.

Repartir los datos nombres/direcciones entre distintos servidores.

Restringir las posibilidades de lectura-escritura del servidor a una rama de la arborescencia del sistema de archivos global (chroot jail).

17.- Control de los clientes autorizados

Un servidor BIND puede estar configurado para tratar solamente las solicitudes de los hosts autorizados y/o rechazar las solicitudes de algunos hosts. La selección puede hacerse especificando direcciones IP o identificadores de red/subred.

17.1.- La opción allow-query

La opción allow-query, en la directiva options del archivo de configuración named.conf, permite especificar los clientes DNS autorizados a interrogar al servidor BIND.

Sintaxis

Ejemplo

El servidor principal, 192.168.0.60, autoriza a todos los hosts de las redes en las que participa a interrogarlo sobre nombres y direcciones de sus zonas, pero solamente la máquina local puede solicitar una resolución hacia otros dominios.

Directiva options del archivo de configuración named.conf:

El host 192.168.0.70 solicita resoluciones de nombres al servidor DNS que acabamos de presentar:

La primera solicitud ha sido rechazada porque implica una búsqueda recursiva, la segunda funciona porque es relativa al dominio local.

Desde la máquina del servidor DNS, las dos solicitudes de resolución son aceptadas:

17.2.- La opción blackhole

La opción blackhole, en la directiva options del archivo de configuración named.conf, permite especificar los hosts que no están autorizados a interrogar al servidor BIND.

El servidor no responde nada a las solicitudes de los hosts de la lista blackhole, como si no estuviera disponible.

Sintaxis

Ejemplo

Directiva options del archivo de configuración named.conf:

El host 192.168.0.70 solicita resoluciones de nombres al servidor DNS mostrado anteriormente:

El servidor no responde a las solicitudes.

18.- Uso de una cuenta de servicio

Como todos los servidores de red, BIND es potencialmente vulnerable. La existencia de un fallo de seguridad en el ejecutable podría permitir a un cliente de red modificar el uso normal del servicio con el objetivo de acceder a información administrada por el sistema. Se desaconseja fuertemente asociar la cuenta del superusuario (UID 0) al daemon named.

En las versiones recientes del paquete de software BIND, el inicio del daemon está configurado para que se ejecute con una cuenta de usuario específica, creada durante la instalación del paquete. Esta cuenta está especificada durante el lanzamiento del ejecutable con la opción -u. Esta cuenta posee derechos suficientes para asegurar el funcionamiento correcto de BIND, pero no tiene derechos de acceso a los archivos sensibles del sistema operativo.

Ejemplo

Daemon named en un servidor Rocky 9:

El daemon está asociado a la cuenta de usuario named.

La cuenta named no puede servir para conectarse en el servidor (ultimo campo de /etc/passwd con el valor false), forma parte del grupo específico named.

Daemon named en un servidor Debian 10:

El daemon está asociado a la cuenta de usuario bind.

La cuenta bind no puede servir para conectarse en el servidor (ultimo campo de /etc/passwd con el valor /usr/sbin/nologin), forma parte del grupo específico bind.

El uso de una cuenta de servicio asociada al daemon limita sus posibilidades de acción en el sistema. No obstante, incluso un usuario que no sea superusuario puede ofrecer información importante en caso de que el servidor haya sido comprometido. Por ejemplo, todos los usuarios tienen derecho de lectura en el archivo de declaración de las cuentas de usuarios locales, /etc/passwd:

19.- BIND en modo chroot jail

Para limitar los accesos posibles del proceso que ejecuta named en la arborescencia del sistema de archivos global, podemos encerrarlo (jail) en una parte de esta arborescencia. El Daemon creerá que el directorio que se le asignará será la raíz del sistema de archivos, y no podrá salir de él.

Este método, llamado chroot jail, se utiliza frecuentemente en los servidores de redes. Asociado al uso de una cuenta de servicio de no superusuario, refuerza la seguridad limitando las consecuencias de un posible fallo de seguridad en el servicio de red.

19.1.- Creación del entorno necesario

En modo chroot jail, el daemon named ve su directorio “cárcel” como directorio raíz. Por lo tanto, tiene que poder encontrar a partir de este directorio todos los directorios y archivos que necesita.

Por ello es necesario crear en el directorio “cárcel” todos los directorios necesarios (etc, var/named o var/cache/bind, dev, etc.) y copiar o crear los archivos utilizados por el daemon.

El paquete bind-chroot instala un servidor BIND en modo chroot jail. No obstante, es importante conocer bien las etapas de configuración de un servidor en ese modo, por esto es tan necesario para la certificación LPIC-2.

19.2.- Creación del entorno chroot jail

Las etapas de configuración de un daemon named en modo chroot jail son las siguientes (los elementos que se utilizarán pueden variar en función de la distribución utilizada, los ejemplos que veremos a continuación se aplican a una distribución de tipo Red Hat):

Crear el directorio “cárcel” y la arborescencia necesaria en ese directorio

El directorio dev contendrá dos archivos especiales usados por named : null y random.

El directorio var/run/named contiene archivos que identifican el proceso named activo.

El directorio etc contiene el archivo de configuración named.conf y el director de configuración named.

El directorio var/named contiene los archivos de datos y de registro.

Copiar los archivos necesarios en los diferentes subdirectorios del directorio “cárcel”:

Crear los archivos especiales que necesita named:

Modificar el propietario y el grupo para toda la arborescencia del directorio “cárcel”:

Configurar la ejecución del daemon named en modo chroot jail, con la opción -t DirCárcel (o configurar el inicio en chroot jail usando systemd):

19.3.- Ejecución del programa en modo chroot jail

Se puede comprobar manualmente el correcto arranque del daemon named en este modo, con el comando siguiente:

named -c ArchivoConfig -u usuario -t DirCárcel

Ejemplo

Si el daemon no se inicia correctamente, hay que consultar los archivos de registro del sistema. Cuidado porque SELinux puede dar problemas (se puede desactivar temporalmente para hacer un diagnóstico, con el comando setenforce 0).

20.- Servidores DNS fraccionados (split DNS)

La mayoría de las organizaciones poseen una parte de su red accesible desde el exterior y otra reservada a un uso interno. Los servicios de redes accesibles desde el exterior (servidores HTTP, FTP…) tienen que estar referenciados en una base de nombres de un servidor DNS accesible desde el exterior (y desde el interior de la organización), por lo tanto, potencialmente amenazado. Los hosts y los servicios de redes reservados a un uso interno tienen que estar referenciados en una base de nombres de un servidor DNS, pero este último no debería ser accesible desde el exterior.

Para limitar los riesgos de intrusión o robo de datos, es habitual fraccionar el servicio DNS en distintos servidores DNS:

Servidor DNS accesible desde el exterior: este servidor solo tiene en su archivo de zona los nombres de los hosts y de los servicios accesibles desde el exterior. De esta manera, si fuera atacado por la red, no podría comunicar información relativa a la red interna de la organización.

Servidor DNS interno: este servidor contiene en su archivo de zona todos los nombres de hosts y de servicios, internos o accesibles desde el exterior. Solamente aceptará las solicitudes de resolución que lleguen desde la red interna. Cuando reciba una solicitud de resolución relativa a un nombre o dirección que no se encuentre en su zona, la transferirá al servidor DNS externo (forwarding) para que este último efectúe una búsqueda recursiva.

Clientes DNS internos: estos clientes están configurados para usar solamente el servidor DNS interno.

La mayoría de las veces, los servidores internos y externos están duplicados; un servidor principal y un servidor secundario, para la tolerancia a fallos.

21.- Intercambio seguro entre servidores DNS

Los servidores DNS intercambian información entre ellos, esto puede constituir un riesgo de seguridad. Un sistema en manos de personas malintencionadas podría recuperar archivos de zona haciéndose pasar por un servidor secundario o, al contrario, comunicar información falsa a un servidor DNS, en particular a su caché (cache poisoning), usando técnicas de usurpación de rol (DNS spoofing). Existen diferentes soluciones para reforzar la seguridad de los intercambios entre servidores DNS.

22.- Control de las transferencias de zona

Un servidor DNS principal puede ser configurado para autorizar solamente las transferencias de zona a ciertos hosts. Para ello, hay que usar la opción allow-transfer, bien en la directiva options, bien en la directiva de definición de la zona, en el archivo named.conf.

La opción allow-transfer permite especificar los solicitantes autorizados a recibir una copia del archivo de zona del servidor BIND principal de la zona.

Sintaxis

Ejemplo

El servidor principal, 192.168.0.60, solamente autoriza la demanda de una transferencia de sus zonas al servidor secundario 192.168.0.70:

Directiva options del archivo de configuración named.conf:

23.- Transacciones seguras TSIG

Las transacciones seguras (TSIG, Transaction SIGnature) permiten garantizar la identidad de los servidores DNS que se intercambian información de zona.

Los servidores comparten la clave pública de un par de claves, clave privada y pública, y tienen que suministrarla para poder hacer intercambios de información entre ellos.

También se puede usar este método para generar archivos de zona firmados digitalmente, que garanticen su origen y que sean utilizables solamente por servidores que dispongan de la clave pública.

Para que el intercambio de la clave funcione correctamente, las horas de los servidores tienen que estar sincronizadas.

23.1.- Generación de claves de transacción de hosts

El par de claves se puede generar usando el comando dnssec-keygen.

Sintaxis habitual

Ejemplo

Generación de un par de claves para las transacciones TSIG entre el servidor principal y los secundarios:

23.2.- Configuración de TSIG en named.conf

En el servidor principal y en los servidores secundarios seguros, se tiene que declarar la clave pública en el archivo named.conf, así como las características de comunicación.

Declaración de la clave

La directiva key permite declarar la clave pública, según la sintaxis siguiente:

NombreClave es el parámetro especificado durante la creación del par de claves. La clave pública “ClavePública” tiene que ser copiada a partir del contenido del archivo .key generado.

Ejemplo

En el servidor principal y en el servidor secundario, en el archivo named.conf:

En el servidor principal, hay que denegar las transferencias de zonas a los que no tienen la clave, usando la opción allow-transfer. Se puede hacer también en el servidor (usando la directiva options), o solamente para algunas zonas (en la directiva zone):

En el o los servidores secundarios, hay que indicar que tiene que proporcionarse la clave en los intercambios con el servidor principal. Para ello se utiliza una directiva server:

DirIP corresponde a la dirección IP del servidor principal.

Ejemplo

En el servidor principal Rocky 9:

En el servidor secundario Debian 10:

Después hay que recargar las configuraciones de named en los dos servidores. También hay que asegurarse de que la hora esté sincronizada en los servidores.

24.- DNSSEC

DNSSEC (Domain Name System Security Extensions) es un protocolo que tiene como objetivo reforzar la seguridad de los servidores DNS y de sus intercambios. Está definido en las RFC 4033, 4034 y 4035.

DNSSEC firma digitalmente todos los datos de los archivos de zona y las respuestas a las solicitudes de resolución. El solicitante puede de esta manera asegurarse de que los datos recibidos son auténticos, incluyendo el caso en el que los datos vienen del caché de un servidor DNS. Para ello, el cliente tiene que disponer de la clave pública asociada a la que ha servido para generar la firma.

DNSSEC también permite la transferencia de los archivos de zona firmados digitalmente, los cuales solo pueden ser leídos por los servidores DNS que tengan la clave pública. Para ello es necesario crear una clave de tipo ZONE, con el comando dnssec-keygen, y generar después el archivo de zona firmado digitalmente, con el comando dnssec-signzone.

25.- DANE

DANE (DNS-based Authentication of Named Entities) es un nuevo protocolo de protección de los intercambios efectuados usando el protocolo seguro TLS (Transport Layer Security). TLS usa certificados digitales X.509 para autenticar los diferentes participantes. Estos certificados son ofrecidos por autoridades de certificación (CA, Certification Authorities), pero en algunos casos pueden ser usurpados.

DANE permite almacenar y firmar los certificados digitales X.509 en los dominios DNS (con registros de tipo TLSA) y proporcionarlos a los clientes y a los servidores del dominio, a condición de que usen DNSSEC.1