Bind DNS sobre linux debian. BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon) es el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, PDF

Preview

Summary

Bind DNS sobre linux debian. BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon) es el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, en loscuales es un estándar de facto. Es patrocinado por la Internet Systems Consortium....

Description

Introducción al servicio DNS Introducción al servicio DNS BIND Servidor DNS Soporte para base de datos Seguridad Instalación y configuración Instalación Administración del servicio Ficheros de configuración Estructura del fichero de configuración Implementaciones Almacenamiento en caché del servidor DNS Configurar como servidor DNS de almacenamiento en caché Forwarding DNS Server Configurar como servidor DNS de reenvío Bind zonas DNS Servidor Master (primario) Servidor Slave (secundario) Asegurando un servidor BIND Bind con chroot y usuario del servicio Segurizando las actualizaciones y transferencias de zona de DNS DNSSEC Herramientas checkconf Herramienta DIG Uso de DIG Herramienta RNDC Uso de RNDC

BIND Servidor DNS BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon) es el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, en los cuales es un estándar de facto. Es patrocinado por la Internet Systems Consortium. BIND fue creado originalmente por cuatro estudiantes de grado en la University of California, Berkeley y liberado por primera vez en el 4.3BSD. Paul Vixie comenzó a mantenerlo en 1988 mientras trabajaba para la DEC. Una nueva versión de BIND (BIND 9) fue escrita desde cero en parte para superar las dificultades arquitectónicas presentes anteriormente para auditar el código en las primeras versiones de BIND, y también para incorporar DNSSEC (DNS Security Extensions). BIND 9 incluye entre otras características importantes: TSIG, notificación DNS, nsupdate, IPv6, rndc flush, vistas, procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. Es comúnmente usado en sistemas GNU/Linux.

Soporte para base de datos Las versiones anteriores de BIND no ofrecen ningún mecanismo para almacenar y recuperar datos del sitio en diferentes condiciones en archivos de texto plano. Desde la versión 9,4 de BIND, DLZ ha estado disponible como una opción que permite tiempo de compilación para el almacenamiento del sitio en una gran variedad de formatos de bases de datos como por ejemplo LDAP, Berkeley DB, PostgreSQL, MySQL u ODBC.

Seguridad Como otras herramientas que estuvieron presentes desde los primeros días de Internet, BIND 4 y BIND 8 han tenido un gran número de vulnerabilidades de seguridad a lo largo del tiempo. BIND 9, habiéndose reescrito, tiene un historial mucho mejor en cuanto a este tema, aunque es común que se sigan encontrando problemas de seguridad tanto en las versiones actuales como las anteriores.

Instalación y configuración Instalación Debian # apt update && apt install bind9 bind9utils

CentOS # yum install bind bind-utils



Administración del servicio CentOS Activar servicio al inicio del sistema. # systemctl enable named

Recargar ficheros de configuración # systemctl reload named

Estado del servicio # systemctl status named

 Debian Activar servicio al inicio del sistema. # systemctl enable bind9

Recargar ficheros de configuración # systemctl reload bind9

Estado del servicio # systemctl status bind9



Ficheros de configuración CentOS El archivo principal de configuración de bind es /etc/named.conf mientras que los ficheros de zona los encontramos en /var/named/bind . Debian En el caso de Debian el archivo principal es /etc/bind/named.conf : // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones";

Los includes nos indican que la configuración esta divida en 3 ficheros. Fichero named.conf.options : options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk.

See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders.  // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. // forwarders { // 0.0.0.0; // }; //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys

//======================================================================== dnssec-validation auto; listen-on-v6 { any; }; };

Fichero named.conf.local : // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918";

Fichero named.conf.default-zones : // prime the server with knowledge of the root servers zone "." { type hint; file "/usr/share/dns/root.hints"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; };

Estructura del fichero de configuración Las declaraciones van entre llaves y se terminan con un punto y coma. Las directivas en las declaraciones también terminan con un punto y coma.

declaración { directiva; };



Implementaciones Almacenamiento en caché del servidor DNS La primera configuración será para un servidor DNS de almacenamiento en caché. Este tipo de servidor también se conoce como solucionador porque maneja consultas recursivas y generalmente puede manejar el trabajo pesado de rastrear datos DNS de otros servidores. Cuando un servidor DNS de almacenamiento en caché rastrea la respuesta a la consulta de un cliente, devuelve la respuesta al cliente. Pero también almacena la respuesta en su caché durante el período de tiempo permitido por el valor TTL de los registros. La memoria caché se puede utilizar como fuente para solicitudes posteriores con el fin de acelerar el tiempo total de ida y vuelta. Casi todos los servidores DNS que pueda tener en su configuración de red almacenarán servidores DNS en caché. Estos compensan la falta de bibliotecas de resolución de DNS adecuadas implementadas en la mayoría de las máquinas cliente. Un servidor DNS de almacenamiento en caché es una buena opción para muchas situaciones. Si no desea depender del DNS de su ISP u otros servidores DNS disponibles públicamente, crear su propio servidor de almacenamiento en caché es una buena opción. Si está muy cerca físicamente de las máquinas cliente, también es muy probable que mejore los tiempos de consulta de DNS.  Configurar como servidor DNS de almacenamiento en caché Primero, cubriremos cómo configurar Bind para que actúe como un servidor DNS de almacenamiento en caché. Esta configuración obligará al servidor a buscar respuestas de forma recursiva de otros servidores DNS cuando un cliente emita una consulta. Esto significa que está haciendo el trabajo de consultar cada servidor DNS relacionado por turnos hasta que encuentre la respuesta completa. Los archivos de configuración de Bind se guardan de forma predeterminada en un directorio en / etc / bind.  Para configurar el almacenamiento en caché, el primer paso es configurar una lista de control de acceso o ACL. Como servidor DNS que se utilizará para resolver consultas recursivas, no queremos que usuarios malintencionados abusen del servidor DNS. Un ataque llamado ataque de amplificación de DNS es especialmente problemático porque puede hacer que su servidor participe en ataques distribuidos de denegación de servicio. Un ataque de amplificación de DNS es una forma en que los usuarios malintencionados intentan derribar servidores o sitios en Internet. Para ello, intentan encontrar servidores DNS públicos que resuelvan consultas recursivas. Ellos falsifican la dirección IP de la víctima y envían una consulta que devolverá una gran respuesta al servidor DNS. Al hacerlo, el servidor DNS responde a una pequeña solicitud con una gran carga útil dirigida al servidor de las víctimas, amplificando efectivamente el ancho de banda disponible del atacante.

Alojar un servidor DNS público recursivo requiere una gran cantidad de configuración y administración especiales. Para evitar la posibilidad de que su servidor sea utilizado con fines maliciosos, configuraremos una lista de direcciones IP o rangos de red en los que confiamos. Sobre el bloque de opciones, crearemos un nuevo bloque llamado acl. Cree una etiqueta para el grupo de ACL que está configurando. En esta guía, llamaremos al grupo buenos clientes. /etc/bind/named.conf.options:

acl goodclients {    };

192.0.2.0/24; localhost; localnets;

options {    

directory "/var/cache/bind"; recursion yes;

 allow-query { goodclients; };       

dnssec-validation auto;

     

auth-nxdomain no;  # conform to RFC1035 listen-on-v6 { any; };

};

Activamos explícitamente la recursividad y luego configuramos el parámetro allow-query para usar nuestra especificación ACL. Podríamos haber utilizado un parámetro diferente, como allowrecursion para hacer referencia a nuestro grupo de ACL. Si está presente y la recursividad está activada, allow-recurssion dictará la lista de clientes que pueden utilizar servicios recursivos. Sin embargo, si no se establece allow-recursion, entonces Bind recurre a la lista allow-querycache, luego a la lista allow-query y finalmente a un valor predeterminado de localnets y localhost solamente. Dado que estamos configurando un servidor de solo almacenamiento en caché (no tiene zonas autorizadas propias y no reenvía solicitudes), la lista de consultas permitidas siempre se aplicará solo a la recursividad. Lo estamos usando porque es la forma más general de especificar la ACL. Cuando haya terminado de realizar estos cambios, guarde y cierre el archivo. En realidad, esto es todo lo que se necesita para almacenar en caché un servidor DNS. Si decidió que este es el tipo de servidor que desea usar, no dude en continuar para aprender cómo verificar sus archivos de configuración, reiniciar el servicio e implementar configuraciones de cliente. De lo contrario, continúe leyendo para aprender a configurar un servidor DNS de reenvío. Reenvío: sólo pasa la consulta DNS a otro servidor DNS (por ejemplo, su ISP). Los routers domésticos utilizan el reenvío para pasar consultas DNS desde los clientes de su red doméstica a los servidores DNS de su ISP. Por ejemplo, para foo.example.com, un servidor DNS de reenvío primero verificará su caché (ya hizo esta pregunta antes), y si la respuesta no está en su caché, pediría a su reenviador (el servidor DNS de su ISP) Para la respuesta, que respondería con una respuesta en caché, o realizaría la recursión hasta que descubriera la respuesta.

Recursividad: el servidor DNS que recibe la consulta se encarga de averiguar la respuesta a esa consulta recursivamente consultando servidores DNS autorizados para ese dominio. Por ejemplo, para foo.example.com, un recursor primero consultaría a los servidores raíz para qué servidores DNS son responsables del TLD .com, entonces pediría a esos servidores por example.com, entonces consultaba a los servidores por example.com para foo.example.com, obteniendo finalmente la respuesta a la consulta original. En términos de seguridad, debe separar los recursores / transportistas (normalmente los servidores DNS utilizados para dar servicio a un grupo de clientes) y los servidores DNS con autoridad (por lo general estos son responsables SOLAMENTE para responder a las consultas sobre los dominios con los que hacen autoridad; Consultas recursivas para cualquiera).

Forwarding DNS Server La segunda configuración que demostraremos es un servidor DNS de reenvío. Un servidor DNS de reenvío se verá casi idéntico a un servidor de almacenamiento en caché desde la perspectiva de un cliente, pero los mecanismos y la carga de trabajo son bastante diferentes. Un servidor DNS de reenvío ofrece la misma ventaja de mantener una caché para mejorar los tiempos de resolución de DNS para los clientes. Sin embargo, en realidad no realiza ninguna consulta recursiva. En su lugar, reenvía todas las solicitudes a un servidor de resolución externo y luego almacena en caché los resultados para usarlos en consultas posteriores. Esto permite que el servidor de reenvío responda desde su caché, sin que sea necesario que haga todo el trabajo de las consultas recursivas. Esto permite que el servidor solo realice solicitudes individuales (la solicitud del cliente reenviado) en lugar de tener que pasar por toda la rutina de recursividad. Esto puede ser una ventaja en entornos donde la transferencia de ancho de banda externa es costosa, donde sus servidores de almacenamiento en caché pueden necesitar ser cambiados con frecuencia o cuando desea reenviar consultas locales a un servidor y consultas externas a otro servidor. Configurar como servidor DNS de reenvío Si un servidor DNS de reenvío se adapta mejor a su infraestructura, podemos configurarlo fácilmente. Comenzaremos con la configuración que dejamos en la configuración del servidor de caché. El archivo named.conf.options debería verse así:  acl goodclients {    192.0.2.0/24;      

localhost; localnets;

}; options {    directory "/var/cache/bind";   

recursion yes;

  

allow-query { goodclients; };

  

dnssec-validation auto;

     

auth-nxdomain no;  # conform to RFC1035 listen-on-v6 { any; };

};

Usaremos la misma lista de ACL para restringir nuestro servidor DNS a una lista específica de clientes. Sin embargo, necesitamos cambiar la configuración para que el servidor ya no intente realizar consultas recursivas por sí mismo. Para hacer esto, no cambiamos la recursividad a no. El servidor de reenvío sigue proporcionando servicios recursivos respondiendo consultas de zonas para las que no tiene autoridad. En su lugar, necesitamos configurar una lista de servidores de almacenamiento en caché a los que reenviar nuestras solicitudes. Esto se hará dentro del bloque de opciones {}. Primero, creamos un bloque dentro llamado reenviadores que contiene las direcciones IP de los servidores de nombres recursivos a los que queremos reenviar solicitudes. En nuestra guía, usaremos los servidores DNS públicos de Google (8.8.8.8 y 8.8.4.4):  . . . options {    directory "/var/cache/bind";   

recursion yes;

  

allow-query { goodclients; };

   forwarders {        8.8.8.8;        8.8.4.4;      

}; . . .

Posteriormente, deberíamos establecer la directiva de reenvío en "solo", ya que este servidor reenviará todas las solicitudes y no debería intentar resolver las solicitudes por sí solo. El archivo de configuración se verá así cuando haya terminado: . . . options {   

directory "/var/cache/bind";

     

recursion yes; allow-query { goodclients; };

  

forwarders {

       8.8.8.8;        8.8.4.4;      

}; forward only;

  

dnssec-validation auto;

      };

auth-nxdomain no;  # conform to RFC1035 listen-on-v6 { any; };

Bind zonas DNS Para que un servidor sea máster primario de una zona debe tener la misma declarada en el archivo. Fichero named.conf.local . zone "ejemplo.network" {      

type master; file "/etc/bind/db.ejemplo.network";

};

Fichero db.ejemplo.network . ; ; BIND data file for local loopback interface ; $ORIGIN ejemplo.network. $TTL 604800 @

IN

SOA ejemplo.network. admin.ejemplo.network. (   2 ; Serial 604800 86400

; Refresh ; Retry

2419200 604800 )

; Expire ; Negative Cache TTL

; ; IP del host 'ejemplo.network' @

IN

A

192.168.1.220

; Servidores de delegación ejemplo.network. IN NS

ns1.ejemplo.network.

ejemplo.network.

ns2.ejemplo.network.

IN

NS

; Registros NS ns1 IN A 192.168.1.210 ns2 IN

A

192.168.1.210

La directiva $ORIGIN sirve para agregar un dominio a los nombres de dominio incompletos. Un nombre se considera incompleto (o relativo) si no tiene un punto al final. $TTL define el tiempo de vida predeterminado para cada registro sin dicho parámetro declarado. Elcarácter ; convierte el texto que está a la derecha en la misma línea en comentario. Cada línea situada a continuación contiene un RR, es decir un registro de recurso. Cada registro tiene de izquierda a derecha, el dominio (o nombre completo del host) en el cual se encuentra el RR, el TTL (es opcional) la clase de RR (que a menos que que se use Chaosnet o Hesiod es IN), y los datos del recurso. La arroba "@" significa en estos casos el nombre de la zona terminado con un punto. 

Servidor Master (primario) Es el servidor con autoridad donde se mantiene la copia principal de los datos de la zona. Este servidor se basa en la directiva allow-transfer que permite la trasferencia de zonas al servidor indicado:

allow-transfer { 192.168.1.115; }; # slave server ip

Tal directiva se especifica dentro de la sección options o la seccion zone , en el caso de la sección options se entiende como global y todas las zonas se trasfieren. La declaración de zona tiene el siguiente aspecto: zone "nameserver.intranet" {      

type master; # se indica que esta esta zona es del tipo "master" file "/etc/bind/db.nameserver.intranet";

}



Servidor Slave (secundario) Es el servidor secundario, el cual carga el contenido de la zona copiándolo (generalmente) desde un servidor Master Primario. Esta operación se denomina transferencia de zona. En el caso de un servidor secundario se deshabilita la transferencia de zonas, este no envía sus zonas a ningún otro servidor: allow-transfer { none; };

 Se declara la zona en el servidor secundario indicando el nombre de fichero de registros y desde donde obtenerlo: zone "nameserver.intranet" {    type slave;   

file "db.nameserver.intranet"; masters { 192.168.1.110; }; # desde que servidor va a trasferir la zona.

};



Asegurando un servidor BIND Bind con chroot y usuario del servicio Ejecutar bind con chroot agrega una capa de seguridad adicional al hacer que el servicio se ejecute en un directorio "jaula". El entorno chroot deberá contar los archivos especiales tales como /dev/zero , /dev/random , /etc/localtime , y de acuerdo a la distribución, /etc/passwd , /dev/null , etc.

Instalación en CentOS # yum install bind-chroot

Luego detenemos el servicio ordinario y arrancamos el servicio enjaulado: # systemctl stop named && systemctl start named-chroot # systemctl status named

named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled) Active: inactive (dead) sep 29 02:05:11 centos7.testing.home named[13252]: running sep 29 02:05:11 centos7.testing.home named[13252]: zone example.com/IN: sending notifies (s...0) sep 29 02:05:11 centos7.testing.home systemd[1]: Started Berkeley Internet Name Domain (DNS). sep 29 02:05:34 centos7.testing.home systemd[1]: Stopping Berkeley Int...