Instalación del servidor DNS bind

Si con las posibilidades que nos ofrece dnsmasq no son suficientes para nuestra red y necesitamos un servidor DNS más completo, podemos utilizar el paquete bind9. Para instalarle, podemos hacerlo con apt-get desde una consola de root:

// Instalación del servidor DNS bind# apt-get install bind9

De esta forma instalaríamos los programas necesarios para disponer de un completo servidor DNS con bind. Tan solo será necesario configurarlo y ponerlo en marcha.

Configuración del servidor DNS

El servidor DNS bind admite tres modos de funcionamiento:

Servidor DNS maestro

Servidor DNS esclavo

Servidor caché DNS

Servidor DNS maestro

En este modo de funcionamiento, nuestro servidor se comporta como un auténtico servidor DNS para nuestra red local. Atenderá directamente a las peticiones de resolución de direcciones pertenecientes a la red local y reenviará a servidores DNS externos las peticiones del resto de direcciones de Internet.

Consulta a un DNS maestro

Servidor DNS esclavo

Un servidor esclavo actuará como un servidor espejo de un servidor DNS maestro. Permanecerá sincronizado con el maestro. Se utilizan para repartir las peticiones entre varios servidores aunque las modificaciones solo se realicen en el maestro. En redes locales salvo por razones de disponibilidad, es raro que exista la necesidad de tener dos servidores DNS ya que con uno será suficiente.

Consulta a un DNS esclavo

Servidor caché DNS

En este modo de funcionamiento, nuestro servidor se comporta como si fuera un auténtico servidor DNS para nuestra red local aunque realmente no sea un servidor DNS propiamente dicho. Cuando recibe una petición de DNS por parte de un cliente de nuestra red, la trasladará a un DNS maestro que puede estar en nuestra red o fuera, almacenará en una memoria caché la respuesta y a la vez la comunicará a quien hizo la petición. Si un segundo cliente vuelve a realizar la misma petición, como nuestro servidor tiene la respuesta almacenada en su memoria caché, responderá inmediatamente sin tener que cursar la petición a ningún servidor DNS de Internet.

Disponer de un servidor caché DNS en nuestra red local aumenta la velocidad de la conexión a Internet pues cuando navegamos por diferentes lugares, continuamente se están realizando peticiones DNS. Si nuestro caché DNS almacena la gran mayoría de peticiones que se realizan desde la red local, las respuestas de los clientes se satisfarán prácticamente de forma instantánea proporcionando al usuario una sensación de velocidad en la conexión.

Es un modo de funcionamiento de sencilla configuración ya que prácticamente lo único que hay que configurar son las direcciones IP de un DNS primario y de un DNS secundario. Muchos routers ADSL ofrecen ya este servicio de caché, tan solo hay que activarlo y configurar una o dos IPs de servidores DNS en Internet. En los PCs de nuestra red local podríamos poner como DNS primario la IP de nuestro router y como DNS secundario una IP de un DNS de Internet.

Consulta a un cache DNS. En caso de fallo, se redirecciona hacia un DNS maestro

Archivos de configuracion del DNS

El archivo de configuración del DNS es el archivo /etc/bind/named.conf, pero este hace referencia a otros cuantos archivos como por ejemplo:

Archivo named.conf: Archivo principal de configuración

Archivo named.conf.options: Opciones genéricas

Archivo named.conf.local: Especificación particular de este servidor DNS

Archivo db.127:Especificación dirección de retorno

Archivo db.root: DNSs de nivel superior

Otros archivos: db.0, db.255, db.empty, db.local, rndc.conf, rndc.key, zones.rfc1918

Configuración como caché DNS

Por defecto, al instalar el paquete bind está preconfigurado como servidor caché DNS. Tan solo será necesario editar el archivo /etc/bind/named.conf.options y en la sección forwarders añadir las IPs de dos servidores DNS donde redirigir las peticiones DNS:// Configuración como caché DNS// Añadir IPs de los DNS de nuestro proveedor en /etc/bind/named.conf.optionsoptions {forwarders {80.58.0.33; 80.58.32.97;};};

Configuración DNS maestro

Por razones de accesibilidad y organizativas, deseamos asignar un nombre a todos los equipos de nuestra red, para lo que instalaremos un servidor DNS privado con un dominio ficticio, por ejemplo 'ieslapaloma.com'. Todos los PCs de nuestra red pertenecerán a dicho dominio ficticio que funcionará solo en nuestra red interna, no en Internet. En tal caso el nombre completo de los PCs terminará con 'ieslapaloma.com', por ejemplo: aula5pc2.ieslapaloma.com. Lo ideal en una situación

así es disponer de un servidor DNS que sea maestro de nuestro dominio, es decir, maestro del dominio interno 'ieslapaloma.com'.

Nuestro servidor DNS maestro para nuestro dominio ficticio interno 'ieslapaloma.com' será capaz de resolver peticiones internas de nombres de este dominio, tanto de forma directa como de forma inversa, es decir, si recibe una consulta acerca de quién es aula5pc7.ieslapaloma.com deberá devolver su IP, pongamos por ejemplo 192.168.0.107. Si la consulta es una consulta DNS inversa acerca de quién es 192.168.0.107, deberá responder aula5pc7.ieslapaloma.com. Por ello deberemos añadir en el archivo /etc/bind/named.conf.local la especificación de maestro para el dominio y para la resolución inversa, por ejemplo:

// Añadir en /etc/bind/named.conf.local// Archivo para búsquedas directaszone "ieslapaloma.com" {type master;file "/etc/bind/ieslapaloma.db";};

// Archivo para búsquedas inversaszone "0.168.192.in-addr.arpa" {type master;file "/etc/bind/192.rev";}; 

Evidentemente será necesario crear los archivos ieslapaloma.db y 192.rev que especificarán la asociación entre nombres y direcciones IP de nuestra red en un sentido y en otro respectivamente.

Archivo de zona de búsqueda directa

Supongamos que en nuestra red local tenemos un aula llamada aula5 con 12 PCs con IPs que van desde la 192.168.0.101 hasta 112 y cuyos nombres van desde aula5pc1 hasta aula5pc10, luego un servidor web (pc11) y un servidor de correo electrónico que además es servidor DNS (pc12). El archivo de configuración DNS de nuestro dominio podría ser así:// Archivo /etc/bind/ieslapaloma.db;; BIND data file for ieslapaloma.com;@ IN SOA ieslapaloma.com. root.ieslapaloma.com. (1 ; Serial604800 ; Refresh86400 ; Retry2419200 ; Expire604800 ) ; Default TTL

IN NS dns.ieslapaloma.com.IN MX 10 mail.ieslapaloma.com.

aula5pc1 IN A 192.168.0.101aula5pc2 IN A 192.168.0.102aula5pc3 IN A 192.168.0.103aula5pc4 IN A 192.168.0.104aula5pc5 IN A 192.168.0.105

aula5pc6 IN A 192.168.0.106aula5pc7 IN A 192.168.0.107aula5pc8 IN A 192.168.0.108aula5pc9 IN A 192.168.0.109aula5pc10 IN A 192.168.0.110www IN A 192.168.0.111dns IN A 192.168.0.112mail IN A 192.168.0.112Las primeras líneas son unos parámetros relacionados con la actualización del DNS (número de serie y periodos de actuación). Las dos siguientes líneas indican quién es el servidor primario (NS = Name Server) y quien procesa el correo electrónico del dominio (MX = Mail eXchange). Las siguentes líneas especifican las IPs de los distintos PCs componentes del dominio (A = Address).

Si olvidamos algún punto y coma, dará errores y no funcionará correctamente. Para revisar los archivos disponemos de los comandos named-checkconf y named-checkzone que analizan que esté correcta la sintaxis de los mismos.

Archivo de zona de búsqueda inversa

Para poder realizar consultas inversas (de IP a nombre) será necesario crear el siguiente archivo:

// Archivo /etc/bind/192.rev;; BIND reverse data file for 192.168.0.0;@ IN SOA ieslapaloma.com. root.ieslapaloma.com. (1 ; Serial604800 ; Refresh86400 ; Retry2419200 ; Expire604800 ) ; Default TTL

IN NS dns.ieslapaloma.com.

101 IN PTR aula5pc1.ieslapaloma.com.102 IN PTR aula5pc2.ieslapaloma.com.103 IN PTR aula5pc3.ieslapaloma.com.104 IN PTR aula5pc4.ieslapaloma.com.105 IN PTR aula5pc5.ieslapaloma.com.106 IN PTR aula5pc6.ieslapaloma.com.107 IN PTR aula5pc7.ieslapaloma.com.108 IN PTR aula5pc8.ieslapaloma.com.109 IN PTR aula5pc9.ieslapaloma.com.110 IN PTR aula5pc10.ieslapaloma.com.111 IN PTR www.ieslapaloma.com.112 IN PTR dns.ieslapaloma.com.112 IN PTR mail.ieslapaloma.com. 

Una vez configurado nuestro servidor DNS, debemos indicar a nuestro servidor Linux que el servidor DNS es él mismo, lo cual se especifica en el archivo /etc/resolv.conf.

// Indicamos que nosotros mismos somos servidores DNS// y por defecto buscamos en nuestro dominio// Editar /etc/resolv.conf del servidor DNSnameserver 127.0.0.1search ieslapaloma.com

En el resto de PCs de la red, indicaremos que el servidor DNS es 192.168.0.112

// En el resto de PCs de la red indicamos quién es el DNS// Editar /etc/resolv.conf del resto de PCs de la rednameserver 192.168.0.112

Tan solo nos faltará poner en marcha nuestro servidor de nombres ejecutando en el servidor el script de inicio correspondiente:

// Arranque del servidor DNS# /etc/init.d/bind9 restart

y, mediante el comando host, el comando dig o el comando nslookup hacer alguna consulta de prueba:

DNS funcionando correctamente

Configuración DNS esclavo

Si deseamos configurar nuestro servidor DNS para que actúe como esclavo de un servidor DNS maestro, la configuración es mucho más sencilla que en el caso anterior ya que únicamente será necesario indicar en el DNS esclavo quién es el servidor DNS maestro, y en el DNS maestro, la IP del DNS esclavo.

Ejemplo, supongamos que el nombre del DNS maestro es dns.ieslapaloma.com (IP 192.168.0.112) y que el nombre del DNS esclavo es dns2.ieslapaloma.com. En el archivo 'ieslapaloma.db' de zona de búsqueda directa añadiremos la línea del segundo dns justo debajo de donde está la del primero:

// Añadir línea en /etc/bind/ieslapaloma.db del maestro....IN NS dns.ieslapaloma.com.

IN NS dns2.ieslapaloma.com. // Nueva línea.... 

De esta forma indicaremos que existen más servidores DNS para dicha zona. Lo mismo haremos en el archivo '192.rev' de la zona inversa:

// Añadir línea en /etc/bind/192.rev del maestro....IN NS dns.ieslapaloma.com.IN NS dns2.ieslapaloma.com. // Nueva línea.... 

En el archivo /etc/bind/named.conf.local del servidor DNS esclavo debemos indicar que se trata de un servidor esclavo y también debemos indicar quién es el maestro:

// Añadir en /etc/bind/named.conf.local del esclavozone "ieslapaloma.com" {type slave;file "/etc/bind/ieslapaloma.db";masters { 192.168.0.112; };};

zone "0.168.192.in-addr.arpa" {type slave;file "/etc/bind/192.rev";masters { 192.168.0.112; };}; 

En el archivo /etc/bind/named.conf.local del servidor DNS maestro podemos utilizar also-notify para mantener los DNS sincronizados. Con also-notify pasamos los cambios de zonas en el maestro al esclavo:

// Archivo /etc/bind/named.conf.local del maestrozone "ieslapaloma.com" {type master;file "/etc/bind/ieslapaloma.db";also-notify {ip_del_esclavo;}};

zone "0.168.192.in-addr.arpa" {type master;file "/etc/bind/192.rev";also-notify {ip_del_esclavo;}};

De esta forma dispondremos en la red de un servidor DNS esclavo que podrá satisfacer las peticiones DNS al igual que lo haría el maestro. Es interesante si el número de peticiones es muy elevado y se requiere distribuir la carga entre los dos servidores, o si deseamos disponer de servicio DNS de alta disponibilidad de forma que aunque el servidor maestro deje de funcionar, el servidor esclavo podrá seguir ofreciendo el servicio.

Cada vez que hagamos un cambio en los archivos /etc/bind/ieslapaloma.db y /etc/bind/192.rev del maestro, debemos acordarnos de actualizar el parámetro serial (incrementar en una unidad) para

que los dns dependientes del maestro sepan que ha cambiado y actualicen su información para mantenerse perfectamente sincronizados.

Arranque y parada manual del servidor DNS

El servidor DNS, al igual que todos los servicios en Debian, dispone de un script de arranque y parada en la carpeta /etc/init.d.// Arranque del servidor DNSsudo /etc/init.d/bind9 start // Parada del servidor DNSsudo /etc/init.d/bind9 stop

// Reinicio del servidor DNSsudo /etc/init.d/bind9 restart

Arranque automático del servidor DNS al iniciar el sistema

Para un arranque automático del servicio al iniciar el servidor, debemos crear los enlaces simbólicos correspondientes tal y como se indica en el apartado Trucos > Arranque automático de servicios al iniciar el sistema.

NotaBind está pensado para ser un servidor DNS de grandes redes pero para pequeñas redes como la de un centro educativo es suficiente dnsmasq, mucho más sencillo de configurar

Sitio de Red: http://www.linuxparatodos.net/

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2006 Linux Para Todos. Algunos Derechos Reservados 2007 Factor Evolución SA de CV. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales. c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

Introducción.

Bind (Berkeley Internet Name Domain).

BIND (acrónimo de Berkeley Internet Name Domain) es una implementación del protocolo DNS y provee una implementación libre de los principales componentes del Sistema de Nombres de Dominio, los cuales incluyen:

• Un servidor de sistema de nombres de dominio (named).

• Una biblioteca resolutoria de sistema de nombres de dominio.

• Herramientas para verificar la operación adecuada del servidor DNS (bind-utils).

El Servidor DNS BIND es ampliamente utilizado en la Internet (99% de los servidores DNS) proporcionando una robusta y estable solución.

DNS (Domain Name System).

DNS (acrónimo de Domain Name System) es una base de datos distribuida y jerárquica que almacena la información necesaria para los nombre de dominio. Sus usos principales son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico correspondientes para cada dominio. El DNS nació de la necesidad de facilitar a los seres humanos el acceso hacia los servidores disponibles a través de Internet permitiendo hacerlo por un nombre, algo más fácil de recordar que una dirección IP.

Los Servidores DNS utilizan TCP y UDP en el puerto 53 para responder las consultas. Casi todas las consultas consisten de una sola solicitud UDPdesde un Cliente DNS seguida por una sola respuesta UDP del servidor. TCP interviene cuando el tamaño de los datos de la respuesta exceden los 512 bytes, tal como ocurre con tareas como transferencia de zonas.

NIC (Network Information Center).NIC (acrónimo de Network Information Center o Centro de Información sobre la Red) es una institución encargada de asignar los nombres de dominio en Internet, ya sean nombres de dominio genéricos o por países, permitiendo personas o empresas montar sitios de Internet mediante a través de un ISP mediante un DNS. Técnicamente existe

un NIC por cada país en el mundo y cada uno de éstos es responsable por todos los dominios con la terminación correspondiente a su país. Por ejemplo: NIC México es la entidad encargada de gestionar todos los dominios con terminación .mx, la cual es la terminación correspondiente asignada a los dominios de México.

FQDN (Fully Qualified Domain Name).

FQDN (acrónimo de Fully Qualified Domain Name o Nombre de Dominio Plenamente Calificado) es un Nombre de Dominio ambiguo que especifica la posición absoluta del nodo en el árbol jerárquico del DNS. Se distingue de un nombre regular porque lleva un punto al final.

EJEMPLO: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión es «maquina1» y un dominio llamado «dominio.com», el FQDN sería «maquina1.dominio.com.», asi es que se define de forma única al dispositivo mientras que pudieran existir muchos anfitriones llamados «maquina1», solo puede haber uno llamado «maquina1.dominio.com.». La ausencia del punto al final definiría que se pudiera tratar tan solo de un prefijo, es decir «maquina1.dominio.com» pudiera ser un dominio de otro más largo como «maquina1.dominio.com.mx».

La longitud máxima de un FQDN es de 255 bytes, con una restricción adicional de 63 bytes para cada etiqueta dentro del nombre del dominio. Solo se permiten los caracteres A-Z de ASCII, dígitos y el carácter «-». No se distinguen mayúsculas y minúsculas.

Desde 2004, a solicitud de varios países de Europa, existe el estándar IDN (acrónimo de Internationalized Domain Name) que permite caracteres no-ASCII, codificando caracteres Unicode dentro de cadenas de bytes dentro del conjunto normal de caracteres de FQDN. Como resultado, los limites de longitud de los nombres de dominio IDN dependen directamente del contenido mismo del nombre.

Componentes de un DNS.

Los DNS operan a través de tres componentes: Clientes DNS, Servidores DNS y Zonas de Autoridad.

Clientes DNS.

Son programas que ejecuta un usuario y que generan peticiones de consulta para resolver nombres. Básicamente preguntan por la dirección IP que corresponde a un nombre determinado.

Servidores DNS.

Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres:

• Servidor Maestro: También denominado Primario. Obtiene los datos del dominio a partir de un fichero hospedado en el mismo servidor.

• Servidor Esclavo: También denominado Secundario. Al iniciar obtiene los datos del dominio a través de un Servidor Maestro (o primario), realizando un

proceso denominado transferencia de zona.

Un gran número de problemas de operación de servidores DNS se atribuyen a las pobres opciones de servidores secundarios para las zona de DNS. De acuerdo al RFC 2182, el DNS requiere que al menos tres servidores existan para todos los dominios delegados (o zonas).

Una de las principales razones para tener al menos tres servidores para cada zona es permitir que la información de la zona misma esté disponible siempre y forma confiable hacia los Clientes DNS a través de Internet cuando un servidor DNS de dicha zona falle, no esté disponible y/o esté inalcanzable.

Contar con múltiples servidores también facilita la propagación de la zona y mejoran la eficiencia del sistema en general al brindar opciones a losClientes DNS si acaso encontraran dificultades para realizar una consulta en un Servidor DNS. En otras palabras: tener múltiples servidores para una zona permite contar con redundancia y respaldo del servicio.

Con múltiples servidores, por lo general uno actúa como Servidor Maestro o Primario y los demás como Servidores Esclavos o Secundarios. Correctamente configurados y una vez creados los datos para una zona, no será necesario copiarlos a cada Servidor Esclavo o Secundario, pues éste se encargará de transferir los datos de manera automática cuando sea necesario.

Los Servidores DNS responden dos tipos de consultas:

• Consultas Iterativas (no recursivas): El cliente hace una consulta al Servidor DNS y este le responde con la mejor respuesta que pueda darse basada sobre su caché o en las zonas locales. Si no es posible dar una respuesta, la consulta se reenvía hacia otro Servidor DNS repitiéndose este proceso hasta encontrar al Servidor DNS que tiene la Zona de Autoridadcapaz de resolver la consulta.

• Consultas Recursivas: El Servidor DNS asume toda la carga de proporcionar una respuesta completa para la consulta realizada por el Cliente DNS. El Servidor DNS desarrolla entonces Consultas Iterativas separadas hacia otros Servidores DNS (en lugar de hacerlo el Cliente DNS) para obtener la respuesta solicitada.

Zonas de Autoridad.

Permiten al Servidor Maestro o Primario cargar la información de una zona. Cada Zona de Autoridad abarca al menos un dominio y posiblemente sus sub-dominios, si estos últimos no son delegados a otras zonas de autoridad.

La información de cada Zona de Autoridad es almacenada de forma local en un fichero en el Servidor DNS. Este fichero puede incluir varios tipos de registros:

Tipo de Registro. Descripción.

A (Address)Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección IPv4 de 32 bits.

Tipo de Registro. Descripción.

AAAARegistro de dirección que resuelve un nombre de un anfitrión hacia una dirección IPv6 de 128 bits.

CNAME (Canonical Name)Registro de nombre canónico que hace que un nombre sea alias de otro. Los dominios con alias obtiene los sub-dominios y registros DNS del dominio original.

MX (Mail Exchanger)Registro de servidor de correo que sirve para definir una lista de servidores de correo para un dominio, así como la prioridad entre éstos.

PTR (Pointer)Registro de apuntador que resuelve direcciones IPv4 hacia el nombre anfitriones. Es decir, hace lo contrario al registro A. Se utiliza en zonas de Resolución Inversa.

NS (Name Server)Registro de servidor de nombres que sirve para definir una lista de servidores de nombres con autoridad para un dominio.

SOA (Start of Authority)

Registro de inicio de autoridad que especifica el Servidor DNS Maestro (o Primario) que proporcionará la información con autoridad acerca de un dominio de Internet, dirección de correo electrónico del administrador, número de serie del dominio y parámetros de tiempo para la zona.

SRV (Service)

Registro de servicios que especifica información acerca de servicios disponibles a través del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP (Extensible Messaging and PresenceProtocol) suelen requerir registros SRV en la zona para proporcionar información a los clientes.

TXT (Text)

Registro de texto que permite al administrador insertar texto arbitrariamente en un registro DNS. Este tipo de registro es muy utilizado por los servidores de listas negras DNSBL (DNS-basedBlackhole List) para la filtración de Spam. Otro ejemplo de uso son las VPN, donde suele requerirse un registro TXT para definir una llave que será utilizada por los clientes.

Las zonas que se pueden resolver son:

Zonas de Reenvío.

Devuelven direcciones IP para las búsquedas hechas para nombres FQDN (Fully Qualified Domain Name).

En el caso de dominios públicos, la responsabilidad de que exista una Zona de Autoridad para cada Zona de Reenvío corresponde a la autoridad misma del dominio, es decir, y por lo general, quien esté registrado como autoridad del dominio tras consultar una base de datos WHOIS. Quienes compran dominios a través de un NIC (por ejemplo ejemplo: www.nic.mx) son quienes se hacen cargo de las Zonas de Reenvío, ya sea a través de su propio Servidor DNS o bien a través de los Servidores DNS de su ISP.

Salvo que se trate de un dominio para uso en una red local, todo dominio debe ser primero tramitado con un NIC como requisito para tener derecho legal a utilizarlo y poder propagarlo a través de Internet.

Zonas de Resolución Inversa.

Devuelven nombres FQDN (Fully Qualified Domain Name) para las búsquedas hechas para direcciones IP.

En el caso de segmentos de red públicos, la responsabilidad de que exista de que exista una Zona de Autoridad para cada Zona de Resolución Inversa corresponde a la autoridad misma del segmento, es decir, y por lo general, quien esté registrado como autoridad del segmento tras consultar una base de datos WHOIS.

Los grandes ISP, y en algunos casos algunas empresas, son quienes se hacen cargo de las Zonas de Resolución Inversa.

Herramientas de búsqueda y consulta.

Mandato host.

El mandato host una herramienta simple para hacer búsquedas en Servidores DNS. Es utilizada para convertir nombres en direcciones IP y viceversa.

De modo predefinido realiza las búsquedas en las Servidores DNS definidos en el fichero /etc/resolv.conf, pudiendo definirse opcionalmente elServidor DNS a consultar.

host www.linuxparatodos.net

Lo anterior realiza una búsqueda en los Servidores DNS definidos en el fichero /etc/resolv.conf del sistema, devolviendo como resultado una dirección IP.

host www.linuxparatodos.net 200.33.146.217

Lo anterior realiza una búsqueda en los Servidor DNS en la dirección IP 200.33.146.217, devolviendo una dirección IP como resultado.

Mandato dig.

El mandato dig (domain information groper) es una herramienta flexible para realizar consultas en Servidores DNS. Realiza búsquedas y muestra las respuestas que son regresadas por los servidores que fueron consultados. Debido a su flexibilidad y claridad en la salida es que la mayoría de los administradores utilizan dig para diagnosticar problemas de DNS.

De modo predefinido realiza las búsquedas en las Servidores DNS definidos en el fichero /etc/resolv.conf, pudiendo definirse opcionalmente elServidor DNS a consultar. La sintaxis básica sería:

dig @servidor nombre TIPO

Donde servidor corresponde al nombre o dirección IP del Servidor DNS a consultar, nombre corresponde al nombre del registro del recurso que se está buscando y TIPO corresponde al tipo de consulta requerido (ANY, A, MX, SOA, NS, etc.)

Ejemplo:

dig @200.33.146.209 linuxparatodos.net MX

Lo anterior realiza una búsqueda en el Servidor DNS en la dirección IP 200.33.146.209 para los registros MX para el dominio linuxparatodos.net.

dig linuxparatodos.net NS

Lo anterior realiza una búsqueda en los Servidores DNS definidos en el fichero /etc/resolv.conf del sistema para los registros NS para el dominiolinuxparatodos.net.

dig @200.33.146.217 linuxparatodos.net NS

Lo anterior realiza una búsqueda en los Servidor DNS en la dirección IP 200.33.146.217 para los registros NS para el dominio linuxparatodos.net.

Mandato jwhois (whois).

El mandato jwhois es una herramienta de consulta a través de servidores WHOIS. La sintaxis básica es:

jwhois dominio

Ejemplo:

jwhois linuxparatodos.net

Loa anterior regresa la información correspondiente al dominio linuxparatodos.net.

Software necesario.

Paquete. Descripción.

• bind Incluye el Servidor DNS (named) y herramientas para verificar su funcionamiento.

• bind-libs Biblioteca compartida que consiste en rutinas para aplicaciones para utilizarse cuando se interactúe con Servidores DNS.

• bind-chroot Contiene un árbol de ficheros que puede ser utilizado como una

Paquete. Descripción.

jaula chroot para named añadiendo seguridad adicional al servicio.

• bind-utils Colección de herramientas para consultar Servidores DNS.

• caching-nameserver

Ficheros de configuración que harán que el Servidor DNS actúe como un caché para el servidor de nombres.

Instalación a través de yum.

Si se utiliza de Red Hat™ Enterprise Linux 5, CentOS 5, CentOS 4 o White Box Enterprise Linux 4, se puede instalar utilizando lo siguiente:

yum -y install bind bind-chroot bind-utils bind-libs caching-nameserver

Instalación a través de Up2date

Si se utiliza de Red Hat™ Enterprise Linux 4, o versiones previas, se puede instalar utilizando lo siguiente:

up2date -i bind bind-chroot bind-utils caching-nameserver

Procedimientos.

Preparativos.

Idealmente se deben definir primero los siguiente datos:

1.

Dominio a resolver.

2.

Servidor de nombres principal (SOA). Éste debe ser un nombre que ya esté plenamente resuelto, y debe ser un FQDN (FullyQualified Domain Name).

3.

Lista de todos los servidores de nombres (NS) que se utilizarán para efectos de redundancia. Éstos deben ser nombres que ya estén plenamente resueltos, y deben ser además FQDN (Fully Qualified Domain Name).

4.

Cuenta de correo del administrador responsable de esta zona. Dicha cuenta debe existir y no debe pertenecer a la misma zona que se está tratando de resolver.

5.

Al menos un servidor de correo (MX), con un registro A, nunca CNAME.

6 IP predeterminada del dominio.

.

7.

Sub-dominios dentro del dominio (www, mail, ftp, ns, etc.) y las direcciones IP que estarán asociadas a estos.

Es importante tener bien en claro que los puntos 2, 3 y 4 involucran datos que deben existir previamente y estar plenamente resueltos por otro servidor DNS; Lo anterior quiere decir no pueden utilizar datos que sean parte o dependan del mismo dominio que se pretende resolver. De igual modo, el servidor donde se implementará el DNS deberá contar con un nombre FQDN y que esté previa y plenamente resuelto en otro DNS.

Como regla general se generará una zona de reenvío por cada dominio sobre el cual se tenga autoridad plena y absoluta y se generará una zona de resolución inversa por cada red sobre la cual se tenga plena y absoluta autoridad. es decir, si se es propietario del dominio «cualquiercosa.com», se deberá generar el fichero de zona correspondiente a fin de resolver dicho dominio. Por cada red con direcciones IP privadas sobre la cual se tenga control y plena y absoluta autoridad, se deberá generar un fichero de zona de resolución inversa a fin de resolver inversamente las direcciones IP de dicha zona. Regularmente la resolución inversa de las direcciones IP públicas es responsabilidad de los proveedores de servicio ya que son estos quienes tienen la autoridad plena y absoluta sobre dichas direcciones IP.

Todos los ficheros de zona deben pertenecer al usuario «named» a fin de que el servicio named pueda acceder a estos o bien modificarlos en el caso de tratarse de zonas esclavas.

Creación de los ficheros de zona.

Los siguientes corresponderían a los contenidos para los ficheros de zona requeridos para la red local y por el NIC con el que se haya registrado el dominio. 

NOTA: por favor que en las zonas de reenvío siempre se

especifica al menos un Mail Exchanger (MX)y que se utilizan tabuladores (tecla TAB) en lugar de espacio.Solo necesitará sustituir nombres y direcciones IP, y quizá añadirnuevos registros para complementar su red local.

Zona de reenvío red local /var/named/chroot/var/named/red-local.zone

$TTL 86400@ IN SOA dns.red-local. jperez.red-local. (2006031601; número de serie28800 ; tiempo de refresco7200 ; tiempo entre reintentos de consulta604800 ; tiempo tras el cual expira la zona86400 ; tiempo total de vida)@ IN NS dns@ IN MX 10 mail@ IN A 192.168.1.1intranet IN A 192.168.1.1maquina2 IN A 192.168.1.2maquina3 IN A 192.168.1.3maquina4 IN A 192.168.1.4www IN CNAME intranetmail IN A 192.168.1.1

ftp IN CNAME intranetdns IN CNAME intranet

Zona de resolución inversa red local /var/named/chroot/var/named/1.168.192.in-addr.arpa.zone

$TTL 86400@ IN SOA dns.red-local. jperez.red-local. (2006031601 ; número de serie28800 ; tiempo de refresco7200 ; tiempo entre reintentos de consulta604800 ; tiempo tras el cual expira la zona86400 ; tiempo total de vida)@ IN NS dns.red-local.1 IN PTR intranet.red-local.2 IN PTR maquina2.red-local.3 IN PTR maquina3.red-local.4 IN PTR maquina4.red-local.

Zona de reenvío del dominio /var/named/chroot/var/named/dominio.com.zone

Suponiendo que hipotéticamente se es la autoridad para el dominio «dominio.com», se puede crear una Zona de Reenvio con un contenido similar al siguiente:

$TTL 86400@ IN SOA fqdn.dominio-resuelto. cuenta.email.existente. (2006031601; número de serie28800 ; tiempo de refresco7200 ; tiempo entre reintentos de consulta604800 ; tiempo tras el cual expira la zona86400 ; tiempo total de vida)@ IN NS dns@ IN MX 10 mail@ IN A 148.243.59.1servidor IN A 148.243.59.1www IN CNAME servidormail IN A 148.243.59.1ftp IN CNAME servidordns IN CNAME servidor

Zona de resolución inversa del dominio /var/named/chroot/var/named/1.243.148.in-addr.arpa.zone

Suponiendo que hipotéticamente se es la autoridad para el segmento de red 148.234.1.0/24, se puede crear una Zona de Resolución Inversa con un contenido similar al siguiente:

$TTL 86400@ IN SOA fqdn.dominio-resuelto. cuenta.email.existente. (2006031601 ; número de serie28800 ; tiempo de refresco7200 ; tiempo entre reintentos de consulta604800 ; tiempo tras el cual expira la zona86400 ; tiempo total de vida)@ IN NS dns.dominio.com.1 IN PTR servidor.dominio.com.2 IN PTR maquina2.dominio.com.

3 IN PTR maquina3.dominio.com.4 IN PTR maquina4.dominio.com.

Cada vez que haga algún cambio en algún fichero de zona, deberá cambiar el número de serie (serial) a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendría que reiniciar el equipo, algo poco conveniente.

En distribuciones basadas en Red Hat Enterprise Linux 4 y versiones previas, este archivo se encuentra localizado como /etc/named.conf,mientras que en aquellas basadas en Red Hat Enterprise Linux 5 se deberá localizar en /var/named/chroot/etc/named.conf. Si el archivo no existiera, habrá que crearlo con el siguiente contenido.

Configuración de parámetros en el fichero /etc/named.conf

options { directory "/var/named/";dump-file "/var/named/data/cache_dump.db";statistics-file "/var/named/data/named_stats.txt";allow-recursion {127.0.0.1;192.168.1.0/24;};forwarders { 200.33.146.209;200.33.146.217;};forward first;};zone "." { type hint; file "named.ca";};zone "0.0.127.in-addr.arpa" { type master; file "0.0.127.in-addr.arpa.zone";allow-update { none; };};zone "localhost" { type master; file "localhost.zone";allow-update { none; };};zone "dominio.com" { type master; file "dominio.com.zone";allow-update { none; };};zone "1.243.148.in-addr.arpa" { type master; file "1.243.148.in-addr.arpa.zone";allow-update { none; };};zone "red-local" { type master; file "red-local.zone";allow-update { none; };};zone "1.168.192.in-addr.arpa" { type master; file "1.168.192.in-addr.arpa.zone";allow-update { none; };};include “/etc/rndc.key”;

Seguridad adicional en DNS para uso público.

Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico.

Un DNS configurado para permitir consultas recursivas indiscriminadamente puede permitir al servidor sufrir o bien participar de un DDoS. Solución al problema consiste añadir en el fichero /etc/named.conf, en la sección de opciones (options), el parámetro allow-recursion definiendo la red, las redes o bien los ACL que tendrán permitido realizar todo tipo de consultas en el DNS, sean locales o de otros dominios.

Fichero /etc/named.conf

options { directory "/var/named/";dump-file "/var/named/data/cache_dump.db";statistics-file "/var/named/data/named_stats.txt";allow-recursion {127.0.0.1;192.168.1.0/24;};forwarders { 200.33.146.209;200.33.146.217;};forward first;};zone "." { type hint; file "named.ca";};zone "dominio.com" {type master;file "dominio.com.zone";allow-update { none; };};zone "1.243.148.in-addr.arpa" {type master;file "1.243.148.in-addr.arpa.zone";allow-update { none; };};

Lo anterior hace que solo 192.168.1.0/24 pueda realizar todo tipo de consultas en el DNS, ya sea para un nombre de dominio hospedado de forma local y otros dominios resueltos en otros servidores (ejemplos: www.yahoo.com, www.google.com, www.linuxparatodos.net, etc.). El resto del mundo solo podrá realizar consultas sobre las zonas dominio.com y 1.243.148.in-addr.arpa, que están hospedados de forma local.

Seguridad adicional en DNS para uso exclusivo en red local.

Si se va a tratar de un servidor de nombres de dominio para uso exclusivo en red local, y se quieren evitar problemas de seguridad de diferente índole, puede utilizarse el parámetro allow-query, el cual servirá para especificar que solo ciertas direcciones podrán realizar consultas al servidor de nombres de dominio. Se pueden especificar directamente direcciones IP, redes completas o listas de control de acceso que deberán definirse antes de cualquier otra cosa en el fichero /etc/named.conf.

Archivo named.conf

acl "redlocal" {127.0.0.1;

192.168.1.0/24; 192.168.2.0/24;192.168.3.0/24;};options {directory "/var/named/";dump-file "/var/named/data/cache_dump.db";statistics-file "/var/named/data/named_stats.txt";allow-recursion { redlocal; };forwarders { 200.33.146.209;200.33.146.217;};forward first;allow-query {redlocal;192.168.1.15;192.168.1.16;};};zone "red-local" {type master; file "red-local.zone";allow-update { none; };};zone "1.168.192.in-addr.arpa" {type master; file "1.168.192.in-addr.arpa.zone";allow-update { none; };}include “/etc/rndc.key”;

Las zonas esclavas.

Las zonas esclavas se refieren a aquellas hospedadas en servidores de nombres de dominio secundarios y que hacen las funciones de redundar las zonas maestras en los servidores de nombres de dominio primarios. El contenido del fichero de zona es el mismo que en servidor primario. La diferencia está en la sección de texto utilizada en /etc/named.conf, donde las zonas se definen como esclavas y definen los servidores donde está hospedada la zona maestra.

Archivo named.conf Servidor DNS secundario.

zone "dominio.com" { type slave;file "dominio.com.zone";masters { 192.168.1.254; };};zone "1.243.148.in-addr.arpa" { type slave;file "1.243.148.in-addr.arpa.zone";masters { 192.168.1.254; };};zone "red-local" {type slave;file "red-local.zone";masters { 192.168.1.254; };};zone "1.168.192.in-addr.arpa" { type slave;file "1.168.192.in-addr.arpa.zone";masters { 192.168.1.254; };};

Adicionalmente, si desea incrementar seguridad y desea especificar en el Servidor DNS Primario que servidores tendrán permitido ser servidores de nombres de dominio secundario, es decir, hacer transferencias, puede utilizar el parámetro allow-transfer del siguiente modo:

Archivo named.conf Servidor DNS Primario.

zone "dominio.com" {type master; file "dominio.com.zone";allow-update { none; };allow-transfer {200.33.146.217;200.33.146.209;};};zone "1.243.148.in-addr.arpa" {type master; file "1.243.148.in-addr.arpa.zone";allow-update { none; };allow-transfer {200.33.146.217;200.33.146.209;};};zone "red-local" {type master; file "red-local.zone";allow-update { none; };allow-transfer {192.168.1.15;192.168.1.16;};};zone "1.168.192.in-addr.arpa" {type master; file "1.168.192.in-addr.arpa.zone";allow-update { none; };allow-transfer {192.168.1.15;192.168.1.16;};};

Reiniciar servicio y depuración de configuración.

Al terminar de editar todos los ficheros involucrados, solo bastará reiniciar el servidor de nombres de dominio.

service named restart

Si queremos que el servidor de nombres de dominio quede añadido entre los servicios en el arranque del sistema, deberemos realizar lo siguiente a fin de habilitar named junto con el arranque del sistema:

chkconfig named on

Realice prueba de depuración y verifique que la zona haya cargado con número de serie:

tail -80 /var/log/messages |grep named

Lo anterior, si está funcionando correctamente, debería devolver algo parecido a lo mostrado a continuación:

Aug 17 17:15:15 linux named[30618]: starting BIND 9.2.2 -u namedAug 17 17:15:15 linux named[30618]: using 1 CPU

Aug 17 17:15:15 linux named: Iniciación de named succeededAug 17 17:15:15 linux named[30622]: loading configuration from '/etc/named.conf'Aug 17 17:15:15 linux named[30622]: no IPv6 interfaces foundAug 17 17:15:15 linux named[30622]: listening on IPv4 interface lo, 127.0.0.1#53Aug 17 17:15:15 linux named[30622]: listening on IPv4 interface eth0, 192.168.1.1#53Aug 17 17:15:15 linux named[30622]: command channel listening on 127.0.0.1#953Aug 17 17:15:16 linux named[30622]: zone 0.0.127.in-addr.arpa/IN: loaded serial 3Aug 17 17:15:16 linux named[30622]: zone 1.168.192.in-addr.arpa/IN: loaded serial 2006031602Aug 17 17:15:16 linux named[30622]: zone localhost/IN: loaded serial 1Aug 17 17:15:16 linux named[30622]: zone mi-dominio.com.mx/IN: loaded serial 2006031602Aug 17 17:15:16 linux named[30622]: runningAug 17 17:15:16 linux named[30622]: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2006031602)Aug 17 17:15:16 linux named[30622]: zone mi-dominio.com.mx/IN: sending notifies (serial 2006031602)

1.1. Servidor DNS

Bind es el servidor DNS mas popular en entornos Linux. Necesitábamos tenerlo instalado, y así lo hicimos:

dns# apt-get install bind

apt-get es un gran programa que, al indicarle que instale otro programa (install bind) él solo se baja de internet dicho programa y todo lo que haga falta para que funcione, lo instala y lo deja apunto para que solo tengamos que configurar lo que necesitamos.

Ahora que tenemos bind instalado (en mi caso la versión 8.3.3-REL-NOESW), falta configurarlo adecuadamente.

Normalmente, para configurar un programa en linux, basta editando los archivos apropiados del programa. Los archivos de configuración del bind se encuentran en /etc/bind/. El primer fichero que editaremos será el named.conf, que es el fichero principal de bind. Una recomendación es hacer una copia de seguridad del archivo original antes de editarlo. Utilizaremos el editor llamado vi o vim puesto que es uno de los editores más comunes en entornos Unix/Linux:

Teclearemos lo siguiente:

# cp /etc/bind/named.conf /etc/bind/named.conf.old# vi /etc/bind/named.conf

Nos fijamos que en la segunda página se repite bastante una parte de código parecida a esto:

zone "localhost" {type master;file "/etc/bind/db.local";};

Bien, nos dirigiremos al final del archivo y añadiremos lo siguiente:

zone "dominio.org" {type master;file "/etc/bind/db.dominio.org";};

Esas líneas definen una nueva zona, dominio.org, sobre la que se ejerce el control, y el fichero (file) de configuración de esta zona se encontrará en /etc/bind/db.dominio.org. Guardaremos los cambios y saldremos (:wq).

Ahora falta crear el fichero db.dominio.org, y como que el formato del archivo es parecido al ya existente /etc/bind/db.local, haremos una copia de éste con el nombre db.dominio.org sobre el cual modificaremos a nuestro parecer:

# cp /etc/bind/db.local /etc/bind/db.dominio.org# vi /etc/bind/db.dominio.org

El archivo db.dominio.org tiene que quedar parecido a este:

-Inicio del archivo (esto no debe incluirse)-

;; BIND data file for dominio.org;$TTL 604800dominio.org. IN SOA dns.dominio.org. root.localhost. (

1 ; Serial604800 ; Refresh86400 ; Retry2419200 ; Expire604800 ) ; Negative Cache TTL

IN NS dns.dominio.org.

IN A 80.80.80.80

IN MX 10 mail.dominio.org.

dns IN A 80.80.80.80

mail IN A 80.80.80.80

www IN CNAME dns

ftp IN CNAME dns

-Fin (esto tampoco debe incluirse)-

Para entender esto:

Lo que sigue después de ";" es ignorado como código, se interpretan como comentario. En las siguientes líneas se entiende que dominio.org se encuentra en la máquina dns.dominio.org (host local de la máquina donde está el servidor DNS), y el encargado de este dominio es root.localhost. (no olvidar poner los puntos en dominio.org. dns.dominio.org. y root.localhost.). El Serial, Refresh y todo esto lo dejamos como está, son tiempos de expiración y otros. Luego se le indica que el servidor DNS (NS) se encuentra en dns.dominio.org. (otra vez lo del punto final) y utiliza como servidor de email (MX)con prioridad máxima (10) (se puede poner la prioridad que se quiera, y la máxima, caso de especificar varios registros MX, es aquella con un número menor) la máquina mail.dominio.org., cuya dirección IP en Internet es 80.80.80.80, y por consiguiente, que el alias dns también está en 80.80.80.80. En este caso, que no hemos puesto punto al final de dns, automáticamente bind lo interpreta de maneraque le añade dominio.org al final, quedando de la manera dns.dominio.org. Lo mismo ocurre con www, ftp y mail pero la etiqueta CNAME matiza que se tratan de tres alias de dns, por lo que si sigues la cadena, tenemos que valen la misma IP que dns, que es lo que nos interesa: tener el servidor web, ftp, dns y mail en la misma máquina. De esta manera, www.dominio.org, ftp.dominio.org, mail.dominio.org y dns.dominio.org se refieren a la misma IP de nuestro ordenador.

Después de esta confusa explicación, debemos poner en marcha named (bind):

# /etc/init.d/bind restart

Lo de restart es porque al haber hecho antes apt-get install bind él solo se ejecuta después de instalarse, con la configuración por defecto que lleva.

Ahora podemos comprobar si todo ha ido bien con el comando siguiente:

# dig @localhost dominio.org

Tendría que salir algo parecido a esto:

; <<>> DiG 9.2.1 <<>> @localhost dominio.org;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63073;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:;dominio.org. IN A

;; ANSWER SECTION:dominio.org. 604800 IN A 80.80.80.80

;; AUTHORITY SECTION:dominio.org. 604800 IN NS dns.dominio.org.

;; ADDITIONAL SECTION:dns.dominio.org. 604800 IN A 80.80.80.80

dig se encarga de mirar la configuración de dominio.org utilizando como servidor DNS el que nosotros le indiquemos después de la @. Ya que nos interesa que utilice el servidor DNS que hemos montado nosotros para probar si funciona correctamente, que se encuentra en nuestra máquina local, le escribiremos después de la @ localhost.

Podríamos decir que ya tenemos nuestro propio servidor DNS.

Pero no estamos aún, el ordenador que hace de servidor está detrás de un router, en una red interna, y deberemos abrir el puerto 53 del router (puerto que utiliza el bind para las peticiones DNS) y redirigirlo al puerto 53 del servidor DNS de la intranet.

Desde el servidor Linux haremos un telnet a la IP del router:

# telnet 192.168.0.1Trying 192.168.0.1...Connected to 192.168.0.1.Escape character is '^]'.login:

Introduciremos el login y la contraseña adecuada y una vez dentro del router teclearemos lo siguiente:

3Com-DSL>add nat tcp vc internet public_port 53 private_port 53 private_address 192.168.0.5

3Com-DSL>add nat udp vc internet public_port 53 private_port 53 private_address 192.168.0.5

Esto hace lo dicho anteriormente: abre el puerto 53 del router (public_port 53) y envía las peticiones que le llegan, a la máquina 192.168.0.5 que se encuentra dentro de la red (private_address 192.168.0.5) , al puerto 53 de esa máquina (private_port 53). Con lo de tcp y udp indicamos que se valide por esos dos protocolos (esta operación que hace el router se denomina NAT, Network Address Translation / Traducción de dirección de red).

Le decimos al router que guarde los cambios y reinicie para que los cambios tengan efecto:

3Com-DSL>save all3Com-DSL>reboot

Esperamos un par de minutos más, y todo está listo para que, cuando en el registro de dominio.org se nos pregunte por un servidor DNS, poner el que hemos montado: dns.dominio.org como primario y cualquier otro servidor DNS como secundario.

No lo expliqué antes, pero nos piden dos servidores, uno primario y otro secundario, por si el primario dejara de funcionar alguna vez, podamos seguir visitando la web gracias al DNS secundario. En este caso, pusimos como secundario un DNS de Terra, que podría haber sido cualquier otro. Si nuestro servidor DNS se apagara por alguna razón, se cogería el secundario, pero como el de Terra no tiene ninguna información acerca de dominio.org, no podría mostrarnos la página. De todas maneras, si se apagara el servidor DNS, tampoco podríamos dar servicio de WEB, ya que se trata del mismo ordenador.

Los cambios de configuración en el DNS son lentos, y no será hasta unas horas después (incluso hasta 48 horas) que podremos comprobar los resultados.

Primer problema afrontado y superado, pasemos a la configuración del servidor apache para que funcione definitivamente www.dominio.org .

http://www.sorgonet.com/collaborations/servidor-ies/

3 DNS secundario y transferencia de zonasEn los servicios DNS, los servidores secundarios o esclavos guardan una copia de la base de

datos, o bien una parte de ella, del servicio DNS de forma que si se produce un fallo en el

servidor principal las consultas podrán ser satisfechas por los servidores secundarios. Dada su

misión como alternativa ante fallos del servidor principal es obvio que los servidores secundarios

deberían compartir las mínimas infraestructuras con el servidor principal, como por ejemplo

alimentación eléctrica, si falla en los dos sistemas perdemos el servicio, o la conexión a un

switch si los dos están conectados al mismo componente de red, si falla este perderemos la

conectividad con el servicio.

El paso de información entre el servidor primario y los secundarios se realiza de forma

automática, sólo se requiere configurar los servicios de forma que se complemente sus

parámetros de IP, zonas a transferir y los permisos o claves correspondientes para que las

transferencias de zonas se realice forma segura.

Para la configuraciones de ejemplo seguiremos los ficheros contenidos en bind_secundario.zip.

Para el secundario los ficheros de configuración a modificar en /etc/bind son:

named.conf.options modificamos forwarders como en el principal.

named.conf.local modificamos según las zonas que deben transferirse a nuestro servidor secundario, básicamente

cambia type que ahora vales slave, se indica el nombre de los ficheros sobre los que se realiza la copia de la base de

datos, pero sin especificar la ruta que por defecto es /var/cache/bind y con la directiva master indicamos la IP del servidor

principal del cual esperamos la copia de esa zona, según nuestro ejemplo:

controls {

inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; };

};

 zone "depinfo.iesjc" {

type slave;

file "sec.db.depinfo.iesjc";

allow-query { any; };

masters { 192.168.1.111; };

};

 zone "1.168.192.in-addr.arpa" {

type slave;

file "sec.db.192.168.1";

masters { 192.168.1.111; };

};

Recordemos que para que nuestros sistemas conozcan este servidor secundario deberá aparecer en el

fichero /etc/resolv.conf como se ha visto anteriormente.

Una vez configurado el servicio del servidor secundario reiniciamos el servicio y comprobamos que en /var/cache/bind

se han creado los ficheros con las copias de las bases de datos. En caso afirmativo para probar el funcionamiento del

servidor secundario tan solo debemos parar el servicio del sistema principal y comprobamos que las consultas siguen

funcionando, si paramos también el secundario comprobaremos que el servicio ya no está disponible.