DNS. DNS by Rafael Lozano is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 España License.

Transcripción

1 Este documento describe la estructura, características y funcionamiento del servicio de nombres de dominio () en Internet. Posteriormente, se explica la instalación y configuración de un servidor en plataformas Windows y Linux para que los clientes de la red puedan tener resolución de nombres. by is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 España License.

2

3 Información técnica Nivel de usuario: Avanzado Escenario: La instalación y configuración de un servidor DHCP se ha realizado y probado sobre dos redes locales virtuales independientes creadas en VirtualBox v5.1. En la primera se ha utilizado dos servidores Windows Server 2016 y un cliente Windows 10 con la siguiente configuración: Hostname Máquina Virtual SO Conexiones de Red Hardware VirtualBox Red NAT Red Interna red_windows Servidores Puerta de de Nombres Enlace Software adicional Dinámica en / /24 El mismo que la máquina física Ninguno SeWiPr WS 2016 HD 30GB RAM 2GB SeWiSe WS 2016 HD 30GB RAM 2GB / Ninguno reservada DHCP ClWi W10 HD 30GB RAM 2GB Dinámica en / Ninguno En la siguiente red se ha empleado un servidor Lubuntu y un cliente con el mismo sistema operativo, según la siguiente configuración Hostname Máquina Virtual SO Conexiones de Red Hardware VirtualBox Red NAT Red Interna red_linux Servidores Puerta de de Nombres Enlace Software adicional Dinámica en / /24 El mismo que la máquina física Ninguno SeLiPr Lubuntu HD 10GB RAM 1GB SeLiSe Lubuntu HD 10GB RAM 1GB / Ninguno reservada DHCP ClLi Lubuntu HD 10GB RAM 1GB Dinámica en / Ninguno Para que las máquinas virtuales de la red puedan comunicarse entre sí es necesario que los servidores DHCP estén configurados y funcionando correctamente, para que los clientes puedan obtener una configuración de red, tal y como se vio en el capítulo dedicado a DHCP. Así, los clientes podrán disponer de direccionamiento IP. Conocimientos previos: Es necesario tener conocimientos teóricos y prácticos de la configuración TCP/IP de una interfaz de red, en plataformas Windows y Linux. Para la parte de Linux se necesita saber el uso de un editor de texto plano, como nano o vi, además de los comandos básicos de Unix en gestión de archivos y directorios. Última revisión del documento: Septiembre 2016 I

4 Esquema de red: La conexión de red es la siguiente II

5 Zona de ejemplo En este capítulo se va a instalar y configurar dos servidores, uno primario y otro secundario. En el servidor primario crearemos una zona de búsqueda directa y otra de búsqueda inversa. Además, añadiremos diferentes registros de recursos y el servidor secundario tendrá una copia de los archivos de zona del primario. Naturalmente, todo esto se hará en una plataforma Windows y otra Linux. Para la primera crearemos el siguiente árbol de dominio. El archivo de zona de búsqueda directa para el dominio serviciosenred.local y el archivo de zona de búsqueda inversa para la red /24 contendrán los siguientes registros: Nombre Tipo Referencia sewipr.serviciosenred.local NS, A, MX sewise.serviciosenred.local NS, A selipr.serviciosenred.local A CNAME sewipr.serviciosenred.local ftp.serviciosenred.local CNAME sewipr.serviciosenred.local smtp.serviciosenred.local CNAME sewipr.serviciosenred.local pop3.serviciosenred.local CNAME sewipr.serviciosenred.local imap.serviciosenred.local CNAME sewipr.serviciosenred.local windows.serviciosenred.local Subdominio pc01.windows.serviciosenred.local A Dirección IP En la plataforma Linux se hará algo similar. El árbol de dominio será el siguiente III

6

7 Tendremos un archivo de zona de búsqueda directa para el dominio serviciosenred.local y una zona de búsqueda inversa para la red /24 el cual contendrá los siguientes registros: Nombre Tipo Referencia Dirección IP selipr.serviciosenred.local NS, A, MX selise.serviciosenred.local NS, A sewipr.serviciosenred.local A CNAME selipr.serviciosenred.local ftp.serviciosenred.local CNAME selipr.serviciosenred.local smtp.serviciosenred.local CNAME selipr.serviciosenred.local pop3.serviciosenred.local CNAME selipr.serviciosenred.local imap.serviciosenred.local CNAME selipr.serviciosenred.local linux.serviciosenred.local Subdominio pc01.linux.serviciosenred.local A V

8

9 Tabla de contenido Tabla de contenido 1. El sistema de nombres de dominio El espacio de nombres de dominio El dominio en Internet Dominios genéricos Dominios de países Dominio inverso Estructura del servicio Servidor de nombres de dominio Resolver Resolución de nombres Traducción de direcciones a nombres. Resolución inversa Resolución recursiva Resolución iterativa La caché Resolución de nombres en el servicio dinámico El archivo de zona y los registros de recursos Organismos reguladores en Windows Server Instalación del servicio Comprobación del funcionamiento del servidor Creación de una zona de búsqueda directa en el servidor primario Configurar una zona de búsqueda inversa Añadir registros de recursos a una zona El registro SOA Servidores de nombres de la zona Configuración de un servidor secundario Reenviadores Actualizaciones dinámicas Actualizaciones dinámicas en servidores miembro e independientes Delegación de subdominios Servidores raiz Servidor caché Nslookup Uso de ipconfig para Bind Instalación del servidor Archivos de configuración Comprobación de la sintaxis en los archivos de configuración Configuración de un servidor primario...46 Índice I

10 3.3.1 Archivo de zona de búsqueda directa Archivo de zona búsqueda inversa Comprobación del funcionamiento del servidor Localizar errores del servidor Error de sintaxis en los archivos de configuración Error de sintaxis en los archivos de zona Log del sistema Configuración de un servidor secundario Autorizar el servidor secundario Notificar cambios al servidor secundario Instalación y configuración del servidor secundario Configuración de los clientes para usar ambos servidores Servidor caché Reenviadores condicionales Registro Delegación de subdominio Utilidades de búsqueda Comando dig Comando host Comando nslookup Bibliografía...73 Índice II

11 1. El sistema de nombres de dominio Para identificar una entidad, los protocolos TCP/IP utilizan direcciones IP, que identifican de forma única la conexión de un ordenador en Internet. Sin embargo, los usuarios prefiere utilizar nombres en lugar de direcciones. Por tanto, se necesita un sistema que pueda traducir un nombre en una dirección y de forma inversa una dirección en un nombre. En el protocolo TCP/IP, esto es el Sistema de Nombres de Dominio ( Domain Name System). consiste en una base de datos global, jerárquica y distribuida que almacena información sobre PC's, la cual es responsable de traducir nombres en sus direcciones IP y viceversa, encaminar correo a sus apropiados destinos y otros muchos servicios. Hay varias aplicaciones en el nivel de aplicación del modelo Internet que siguen el paradigma cliente/servidor. Los programas cliente/servidor se pueden dividir en dos categorías: aquéllos que pueden ser utilizados directamente por el usuario, como el correo electrónico y aquéllos que dan soporte a otras aplicaciones. El sistema de nombres de dominio es un programa de soporte que es utilizado por otros programas como el correo electrónico. Fue ideado con el objetivo de reemplazar el esquema de nombres original de Internet, en el que todos los nombres de host y las direcciones se mantenían en un único archivo maestro central y se descargaban vía FTP a todos los computadores que los necesitaban. Pronto se vio que este esquema inicial sufría de fuertes limitaciones: No era escalable hasta un número grande de computadores. Las organizaciones locales deseaban administrar sus propios sistemas de nombres. Se necesitaba un servicio de nombres general, no uno que sólo sirviera para buscar direcciones de PC's. Para entender que hace, veamos el siguiente sencillo ejemplo. Supongamos que desde nuestro PC queremos visitar el sitio web Después de introducir la dirección web Página 1

12 en la barra de dirección del navegador, este tiene que averiguar la dirección IP del PC Para ello, hace una consulta utilizando los métodos de resolución de nombres locales, siendo uno de los principales el. Este, consulta al servidor local el cual averigua rápidamente la dirección IP del PC buscado y devuelve esta respuesta al PC que hizo la consulta. En el lenguaje, esta búsqueda se llama una consulta para un registro o lookup. Este registro describe en la relación entre un hostname y la correspondiente dirección IP. El navegador es ahora capaz de contactar con el PC usando su dirección IP. Por supuesto, el proceso de resolver un nombre en el sistema es más complicado, aunque buscar la correspondiente dirección IP para un hostname, o viceversa, es una de las tareas básicas de. Sin embargo, el protocolo tiene muchas más características y aplicaciones que se verán posteriormente. El protocolo original es descrito en RFC 1304 y RFC 1035: RFC Introduce los nombres de dominio, su uso para correo a través de Internet y soporte de direcciones de hosts, además de los protocolos y servidores utilizados para implementar. RFC Describe los detalles del sistema de dominio y el protocolo, y asume que el lector está familiarizado con los conceptos descritos en el RFC El sistema emplea el protocolo UDP en el puerto 53 para las consultas y el protocolo TCP también en el puerto 53 para las transferencias de zona. 1.1 El espacio de nombres de dominio Un espacio de nombres es el conjunto de todos los nombres válidos y reconocidos por un servicio particular, los cuales requieren una estructura y definición sintáctica. El espacio de nombres en es un espacio de nombres jerárquico. En este diseño, los nombres se definen en una estructura de árbol invertida con una raíz en la parte superior. El árbol sólo puede tener 128 niveles: del nivel 0 (raíz) al nivel 127. Figura 1.- Espacio de nombres jerárquico Cada nodo en el árbol tiene una etiqueta, que es una cadena de caracteres con un máximo de 63 caracteres. El nodo raíz es una cadena vacía. El sistema requiere que los hijos de un nodo tengan diferentes etiquetas, que garantizan la unicidad de los nombres de dominio. Cada nodo en el árbol tiene un nombre de dominio. Un nombre de dominio completo es una secuencia de etiquetas separadas por puntos. Los nombres de dominio siempre se leen desde el Página 2

13 nodo hacia arriba hasta la raíz. La última etiqueta es la etiqueta de la raíz. Figura 2.- Etiquetas, dominios, FQDN y PQDN Si la etiqueta finaliza con una cadena vacía (la de la raíz), entonces el nombre de domino se denomina nombre de dominio completamente cualificado (FQDN). Un FQDN es un nombre de dominio que contiene el nombre completo de un ordenador. Si la etiqueta no finaliza con una cadena vacía, entonces se tiene un nombre de dominio parcialmente cualificado (PQDN) El dominio Un dominio es un subárbol del espacio de nombres de dominio. El nombre del dominio es el nombre del dominio del nodo que se encuentra en la parte superior del subárbol. Podemos ver en la siguiente figura que un dominio se puede subdividir a su vez en dominios (o subdominios). Figura 3.- Dominios y subdominios 1.2 en Internet En Intemet, el espacio de nombres de dominio se divide en tres secciones diferentes: Dominios genéricos Dominios de países Dominios inversos. Los dominios genéricos y de países son nodos del árbol que se encuentran en el primer nivel, directamente conectados a la raíz del árbol. Página 3

14 También se les conoce como dominios de nivel superior (TLD Top Level Domain). Los servidores con autoridad sobre los TLD son los llamados servidores raíz del sistema. Estos son fijos, ya que rara vez cambian, siendo actualmente 13. En ambos casos, se emplean para resolver un nombre de dominio a una dirección IP. Los dominios inversos se emplean para resolver direcciones IP a nombres de dominio. Los nodos de segundo nivel del árbol corresponden a las organizaciones y empresas que están registradas dentro de los dominios genéricos o de países. Estos nombres son elegidos por estas organizaciones, las cuales deben de registrarlos para su uso exclusivo Dominios genéricos Un dominio genérico tiene un nombre de acuerdo a su funcionamiento genérico. También conocidos como internacionales o globales, porque no pertenecen a ningún país. El nombre de un dominio genérico Son mantenidos y regulados por organismos gestores de Internet (ICANN). Figura 4.- Dominios genéricos En la siguiente tabla se observan los principales dominios genéricos. Dominio Significado aero Líneas aéreas biz Firmas de negocios (similar a "com") com Organizaciones comerciales coop Cooperativas edu Instituciones educativas gov Instituciones gubernamentales int Organizaciones internacionales info Proveedores de servicios de información museum Museos Página 4

15 mil Grupos militares name Nombres personales (individuales) net Centros de soporte de red org Organizaciones sin ánimo de lucro pro Organizaciones profesionales Dentro de los dominios genéricos, existen dos categorías: los patrocinados y los no patrocinados. Los primeros reciben el apoyo de organismos privados, mientras que los segundos, por ser considerados de interés público, son mantenidos y regulados directamente por el ICANN y las entidades internacionales. Los dominios genéricos no patrocinados, como.com,.name,.net,.org,.info, etc. siguen una estricta política y reglamentación fijada por el ICANN, que de cierta forma permite dar las máximas garantías de calidad al usuario final. Los dominios genéricos patrocinados, como.aero, siguen una política y reglamentación fijada de forma compartida entre el ICANN y el organismo patrocinador Dominios de países Es un dominio de Internet reservado para un país. La etiqueta tiene una longitud de 2 caracteres. Cada país designa gestores para su dominio y establece reglas para conceder dominios de segundo nivel. Algunos países, como Austria (.at), Argentina (.ar) y España (.es) permiten que cualquier persona del mundo registre un dominio de segundo nivel en el dominio del país. Otros, como Australia (.au), Andorra (.an) y Chile (.ch) sólo permite a sus residentes adquirir un dominio de segundo nivel Dominio inverso El dominio inverso se utiliza para traducir una dirección en un nombre. Esto puede ocurrir, por ejemplo, cuando un servidor ha recibido una petición de un cliente para realizar una tarea. El servidor está configurado para prestar dicho servicio a un conjunto de clientes autorizados los cuales están registrados por su nombre. Sin embargo, la petición ha llegado a través de un paquete el cual solo tiene la dirección IP. Para determinar si el cliente se encuentra en la lista de autorizados, puede enviar una petición al servidor de para solicitar la traducción de la dirección al nombre. 1.3 Estructura del servicio El servicio sigue el modelo cliente-servidor, donde un servidor que presta el servicio de resolución de nombres, se encuentra conectado a Internet de forma permanente en espera de peticiones para traducir nombres. Los clientes, envían sus peticiones de resolución de nombres con el nombre de dominio que necesitan traducir a los servidores los cuales se encargan de devolverles la respuesta con la dirección IP Servidor de nombres de dominio utiliza servidores de nombres para distribuir la información sobre los nombres. Cada servidor es responsable de un dominio pequeño o grande. Puesto que un dominio completo no se puede almacenar en un único servidor, éste se divide entre varios servidores. Página 5

16 Cada servidor es responsable de una zona. Una zona es una parte contigua del árbol de nombres entero. Si un servidor acepta la responsabilidad de un dominio y no divide el dominio en dominios más pequeños, el dominio y la zona se refieren a lo mismo. El servidor construye una base de datos denominado archivo de zonas y almacena información para cada nodo del dominio. Sin embargo, si el servidor decide dividir su dominio en subdominios y delegar parte de su autoridad a otros servidores, dominio y zona se refieren a cosas diferentes. La información sobre los nodos en los subdominios se almacena en los servidores de los niveles inferiores, manteniendo el servidor original algún tipo de referencia a los servidores de niveles inferiores. En el sistema podemos encontrar los siguientes tipos de servidores: Un servidor raíz es un servidor cuya zona consta de un árbol completo. Un servidor raíz normalmente no almacena ninguna información sobre dominios sino que delega su autoridad a otros servidores, manteniendo referencias a esos servidores. Hay varios servidores raíces, cada uno de los cuales cubre el espacio de nombres de dominio completo. Los servidores se distribuyen por todo el mundo. Existen 13 servidores raíz. Excepto tres, los demás se encuentran en Estados Unidos. Un servidor primario, autorizado o de contenido es un servidor que almacena un archivo sobre la zona para la que tiene autoridad. Es responsable de crear, mantener y actualizar el archivo de la zona de su dominio que almacena en su disco local. Éste es el servidor controlado por el administrador principal del dominio y que contiene todas las asociaciones entre nombres y direcciones IP que le pertenecen. Un servidor secundario es un servidor que transfiere la información completa sobre la zona de otro servidor (primario o secundario) y almacena el archivo en su disco local. El servidor secundario ni crea ni actualiza los archivos de zona. Si se necesita una actualización, ésta debe realizarla el servidor primario, que envía la versión actualizada del archivo de zona al secundario. A este proceso se le denomina transferencia de zona Resolver Los clientes hacen las consultas a los servidores a través del resolver. El resolver es un módulo del sistema operativo que se encarga de recibir las peticiones de traducción de nombres de las aplicaciones que se están ejecutando, empaquetarlas en un mensaje de acuerdo al protocolo y enviarlas al servidor que tiene configurado el sistema operativo. Posteriormente, cuando se recibe la respuesta del servidor, se la entrega a la aplicación que la solicito. 1.4 Resolución de nombres La traducción de un nombre a una dirección o de una dirección a un nombre se denomina resolución de nombres. Una aplicación en ejecución que necesita traducir un nombre a una dirección IP, o una dirección IP a un nombre, invoca al resolver, el cual envía la petición al servidor configurado en el sistema. Si el servidor tiene la información, responde al resolver; en caso contrario, o bien indica al resolver otros servidores o bien pregunta a otros servidores para obtener la información. Una vez que el resolver recibe la traducción, interpreta la respuesta para comprobar si es una resolución real o un error y finalmente entrega el resultado al proceso que solicitó la traducción. Página 6

17 1.4.1 Traducción de direcciones a nombres. Resolución inversa Un cliente puede enviar una dirección IP al servidor para que la traduzca a un nombre de dominio. A este tipo de traducción se le denomina resolución inversa. Para responder a peticiones de este tipo, el utiliza el dominio inverso. Sin embargo, en la petición, la dirección IP está invertida y se añaden dos etiquetas in addr y arpa para crear un dominio inverso. Por ejemplo, si el resolver recibe la dirección IP , el resolver invierte en primer lugar la dirección y luego le añade las dos etiquetas anteriores. El nombre de dominio enviado es in addr.arpa, que es recibido y resuelto por el servidor Resolución recursiva El cliente (resolver) puede solicitar una resolución recursiva al servidor de nombres. Esto significa que el resolver espera que el servidor proporcione la respuesta final. Si el servidor es la autoridad del nombre de dominio, comprueba en su base de datos y responde. Si el servidor no es la autoridad, envía la petición a otro servidor (normalmente el padre) y espera la respuesta. Si el padre es la autoridad, responde; en caso contrario, envía la petición a otro servidor. Cuando la petición es finalmente resuelta, la respuesta viaja de vuelta hasta alcanzar finalmente al cliente. Este proceso se denomina resolución recursiva y se muestra en la figura. Figura 5.- Resolución recursiva Resolución iterativa En este caso cuando el servidor es una autoridad para el nombre que se pretende traducir, envía la respuesta. Si no lo es, devuelve al cliente la dirección IP del servidor que cree que puede resolver el nombre. El cliente es responsable de repetir la petición al segundo servidor. Si este servidor puede resolver el nombre, responde a la petición con la dirección IP, en caso contrario devuelve la dirección IP de un nuevo servidor. Ahora el cliente tiene que volver a invocar la petición al nuevo servidor. Este proceso se denomina resolución iterativa debido a que el cliente repite la misma petición a varios servidores. En la figura el cliente consulta a cuatro servidores antes de obtener la respuesta del servidor mcgraw.com. Página 7

18 Figura 6.- Resolución iterativa La caché Cada vez que un servidor recibe una petición para un nombre que no está en su dominio, necesita buscar en su base de datos la dirección de IP de un servidor. La reducción de este tiempo de búsqueda incrementaría la eficiencia. El sistema maneja esto empleando una caché. Cuando un servidor pide una traducción a otro servidor y recibe la respuesta, almacena esta información en su memoria caché antes de enviarla al cliente. Si el mismo u otro cliente solicitan la misma traducción, puede buscar en la memoria caché y solucionar el problema. Sin embargo, para informar al cliente de que la respuesta viene de la memoria caché y no de una fuente autorizada, el servidor marca la respuesta como no autorizada. El empleo de la caché acelera la resolución, pero también es problemática. Si un servidor almacena una traducción durante mucho tiempo, puede enviar una respuesta obsoleta al cliente. Para resolver esto, se han utilizado dos técnicas. En primer lugar, el servidor con la información siempre añade información a la traducción denominada tiempo-de-vida (TTL). Este valor define el tiempo en segundos que el servidor que recibe la información puede almacenarla en la caché. Después de ese tiempo, la traducción se invalida y cualquier petición debe ser enviada de nuevo al servidor. En segundo lugar, el servicio requiere que cada servidor mantenga un contador TTL para cada traducción que almacena en la caché. La memoria caché se analiza periódicamente y aquellas entradas que han expirado se eliminan de la memoria caché. Esta es la razón por la cual los cambios realizados en el no se propagan instantáneamente a través del sistema. Dependiendo de la naturaleza de los mismos y de la configuración de cada servidor, la propagación puede tardar desde algunos minutos hasta varios días. Existen en Internet multitud de servidores de cache que no mantienen ninguna zona y solamente se dedican a almacenar resoluciones cacheadas para servirlas a sus clientes Resolución de nombres en el servicio Normalmente los usuarios de correo electrónico redactan su mensajes usando un cliente de correo y enviándolo a través de un servidor SMTP provisto por su ISP o a través de un sistema de correo vía web (webmail). En cualquier caso, una vez que el mensaje es recibido por el servidor, debe ser entregado al destinatario. Aquí interviene el sistema : 1. El servidor de correo del emisor solicita al servidor la entrada MX del dominio del Página 8

19 receptor del mensaje. MX significa mail exchanger, esto es, el nombre del servidor (o los servidores) encargado de recibir los mensajes destinados a determinado dominio. 2. El servidor devuelve el FQDN y la dirección IP del mail exchanger. 3. El servidor del emisor se conecta al servidor de correo del destinatario y entrega el mensaje según el protocolo SMTP. 4. El proceso podrá continuar si el servidor receptor del mensaje no es el último de la cadena. Existen servidores que actúan como puertas de enlace o gateways de correo electrónico, y que se encargan de recibir los mensajes de determinados dominios para luego enviarlos a otros servidores. 1.5 dinámico Cuando se diseñó el sistema, nadie tuvo en cuenta que hubiera muchos cambios de direcciones. En, cuando hay un cambio, como la inserción de un nuevo ordenador, la eliminación de un ordenador o el cambio de una dirección IP, el cambio se debe hacer en el archivo maestro de. Estos tipos de cambios son muy numerosos involucran mucha actualización manual por parte del administrador del sistema. El archivo maestro debe actualizarse dinámicamente. El sistema de nombres de dominio dinámico (D) se desarrolló para responder a esta necesidad. En D, cuando un servidor DHCP asigna una direccion IP a un nuevo ordenador, envía esta información a un servidor primario de. Este servidor actualiza su zona y actualiza a los servidores secundarios de forma activa o pasiva. En una notificación activa el servidor primario envía un mensaje a los servidores secundarios informando del cambio en la zona, mientras que en una notificación pasiva, los servidores secundarios comprueban periódicamente cualquier cambio. En este caso, una vez notificado el cambio, el secundario solicita información sobre la zona entera denominado transferencia de la zona. Para ofrecer seguridad y evitar cambios no autorizados en los registros de, D puede utilizar un mecanismo de autenticación. 1.6 El archivo de zona y los registros de recursos Anteriormente hemos visto que los servidores primarios o autorizados almacenan un archivo con los datos de la zona, con el cual pueden realizar las traducciones. Estos archivos tienen una sintaxis específica y no sólo almacenan las asociaciones de nombres y direcciones IP, sino también pueden almacenar otro tipo de información. Independientemente del tipo de información que almacenan, cada línea del archivo es un registro de recurso, el cual contiene la información necesaria para responder a una petición de traducción al servidor sobre el dominio que gestiona. En Internet existen diferentes tipos de registros de recursos, y los más habituales son: A - Address (Dirección).- Este registro se usa para traducir nombres de ordenadores a direcciones IP. CNAME - Canonical Name (Nombre Canónico).- Se usa para crear nombres de ordenadores adicionales, o alias, para los ordenadores de un dominio. Es usado cuando se están ejecutando múltiples servicios (como ftp y servidor web) en un servidor con una sola dirección IP. Cada servicio tiene su propia entrada de (como ftp.ejemplo.com y Página 9

20 NS - Name Server (Servidor de Nombres).- Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres. MX - Mail Exchange (Registro de Intercambio de Correo).- Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. PTR - Pointer (Indicador).- También conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. SOA - Start of authority (Autoridad de la zona).- Proporciona información general sobre la zona. HFO - Host FOrmation (Información del sistema informático).- Descripción del host, permite conocer el tipo de máquina y sistema operativo al que corresponde un dominio. TXT - TeXT ( Información textual).- Permite a los dominios identificarse de modos arbitrarios. LOC - LOCalización - Permite indicar las coordenadas del dominio. SRV SeRVicios.- Permite indicar los servicios que ofrece el dominio. SPF - Sender Policy Framework.- Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts están autorizados a enviar correo desde el dominio dado. El servidor que recibe consulta el SPF para comparar la IP desde la cual le llega, con los datos de este registro. Los datos de una zona comienzan con registros de tipo SOA, que contienen los parámetros de zona especificando, por ejemplo, el número de versión y la frecuencia con la que los secundarios deben comprobar la validez de sus propias copias. A continuación aparece una lista de registros de tipo NS que especifican los servidores de nombres para el dominio y una lista de registros de tipo MX que indican las preferencias y los nombres de dominio de los hosts de correo. Después de estos últimos, suelen venir los registros tipo A, con los nombres de dominio y sus correspondientes direcciones IP, y los registros tipo CNAME con los alias de los registros A. 1.7 Organismos reguladores La asignación de nombres de dominio en es un proceso regulado por un conjunto de organismos repartidos por todo el mundo. Son los siguientes: IANA - Internet Assigned Numbers Authority.- Agencia de asignación de números en Internet. Todo comienza aquí: éste es el grupo que coordina la asignación de direcciones IP, tanto IPv4 como IPv6, a nivel mundial. IANA entrega bloques de direcciones IP a los registros regionales de Internet: APNIC Asia Pacific Network Information Centre.- Centro de información de red Asia/Pacífico. Región de Asia y Pacífico. AR American Registry for Internet Numbers.- Registro americano de números de Internet. América del Norte y África sub-sahariana. LANIC Latin American and Caribbean IP Address Registry.- Registro de direcciones IP de Página 10

21 América Latina y Caribe. América Latina y algunas islas del Caribe. RIPE NCC Réseaux IP Européens.- Europa, Medio Oriente, Asia central y países africanos situados al norte del ecuador. ICANN - Internet Corporation for Assigned Names and Numbers.- Corporación de Internet para la asignación de nombres y números. Entre otras tareas, ICANN supervisa la asignación y registro de nombres de dominio. 2. en Windows Server Las redes de tamaño pequeño tienen sus propias necesidades específicas en cuanto a. Aunque algunas redes de tamaño pequeño albergan su propia zona en un servidor local, muchas prefieren emplear un ISP para que albergue la zona de la organización y configurar en la red un servidor secundario que actúa como caché local. Independientemente de si la zona se alberga localmente o no, las redes de pequeño tamaño también se configuran para que el servidor local reenvie las consultas que no puede resolver, es decir aquellas que están en zonas diferentes a la de la propia organización, al servidor del ISP. Las redes de tamaño pequeño tampoco necesitan zonas de búsqueda inversa, aunque se pueden definir. WS2016 incluye un servidor el cual está integrado con Active Directory, el cual necesita de un servidor para funcionar, y el servidor DHCP para actualizaciones automáticas. Es sencillo de configurar. 2.1 Instalación del servicio Para instalar el servico partimos desde la herramienta Administrador del servidor. A partir de aquí seguiremos los siguientes pasos: 1. Hacer clic en Agregar roles y características. 2. En el paso Antes de comenzar hacer clic en el botón Siguiente habiendo antes hecho las comprobaciones de conectividad de red y actualizaciones automáticas están hechas. 3. En el Tipo de instalación seleccionaremos Instalación basada características y en roles. Posteriormente hacer clic en el botón Siguiente. 4. En el paso Selección de un servidor seleccionar el servidor local y después hacer clic en el botón Siguiente. 5. En Roles de servidor activar la casilla correspondiente a Servidor. 6. Aparece una ventana para confirmar la instalación del servicio. Dejar activada la casilla Incluir herramientas de administración (si es aplicable) y hacer clic en el botón Agregar característica. Posteriormente hacer clic en el botón Siguiente. 7. En el paso Características hacer clic en el botón Siguiente. 8. En el paso donde informa sobre el servidor hacer clic en el botón Siguiente. Página 11

22 Figura 7.- Asistente para agregar roles y características 9. En el último paso de confirmación hacer clic en el botón Instalar. 10. Pasado un breve espacio de tiempo y si todo ha ido bien, el servicio se habrá instalado. Cuando haya terminado podemos hacer clic en el botón Cerrar. A partir de ahora veremos que en Administrador del servidor tenemos un nuevo elemento en el panel lateral:. Si hacemos clic en él veremos la lista de servidores actualmente en la red. Ahora mismo sólo hay el que acabamos de instalar Comprobación del funcionamiento del servidor El servidor instalado ahora mismo no tiene ninguna zona definida pero está prestando servicio a los clientes de la red como servidor caché. Esto significa que los clientes de la red local lo pueden emplear como servidor para navegar por Internet. En esta situación, podemos hacer una prueba enviando desde un cliente de la red una consulta a este servidor. En la siguiente figura hemos utilizado la utilidad nslookup para hacer una consulta con el nombre de dominio Esta utilidad la veremos en profundidad más adelante en este mismo documento. Por ahora solamente saber que tenemos que abrir una ventana del símbolo del sistema y teclear el siguiente comando. nslookup Pasamos como parámetro el nombre del cual queremos averiguar su dirección IP. Como Página 12

23 podemos observar en el resultado de la consulta, nos indica las direcciones IP del servidor de Google en españa y el servidor que realizó la consulta. Figura 8.- Consulta Sería conveniente que editáramos las propiedades de red de la interfaz externa y asignáramos estáticamente la dirección IP como servidor de nombres principal. Así el servidor empleará su propio servicio para resolver nombres y podrá traducir nombres de las zonas que administra él mismo. Figura 9.- Propiedades de Red. Servidor preferido Página 13

24 2.2 Creación de una zona de búsqueda directa en el servidor primario Ahora podemos configurar nuestro servidor como un servidor primario para nuestra zona. Si el servidor está conectado a Internet nos aseguraremos que el nombre de dominio de nuestra zona está registrado y que nuestro ISP deriva a nuestro servidor todas las consultas de nombres que pertenecen a nuestra zona. Si no disponemos de una zona registrada y queremos hacer pruebas podemos utilizar una zona local, la cual tiene un dominio de primer nivel.local y así nos aseguramos de que la zona que vamos a configurar no está registrada y nuestro servidor no oculte la resolución de nombres de dominio en esta zona. Para configurar una zona de búsqueda directa en nuestro servidor seguiremos los siguientes pasos: 1. En Administrador del servidor hacemos clic en en el panel izquierdo. 2. En la lista de servidores hacemos clic con el botón derecho del ratón sobre nuestro servidor y posteriormente hacemos clic en la opción Administrador de. Figura 10.- Administrador de 3. Se ha abierto la consola de configuración. Vemos que en la carpeta Zonas de búsqueda directa está vacía porque todavía no hay ninguna zona configurada. Sobre esta carpeta hacemos clic con el botón derecho del ratón y seleccionamos la opción Zona nueva Comienza el asistente de creación de una nueva zona. En la pantalla de introducción hacemos clic en el botón Siguiente. 5. Ahora debemos elegir el tipo de zona. Seleccionamos Zona principal y hacemos clic en el botón Siguiente. 6. Escribimos el nombre de nuestra zona principal: serviciosenred.local. Hacemos clic en el botón Siguiente. 7. En el siguiente paso hay que introducir el nombre del archivo de zona. Dejamos el que propone él que consiste en el nombre de dominio de nuestra zona al que ha añadido.dns. Hacemos clic en el botón Siguiente. 8. Ahora impediremos que este servidor pueda recibir actualizaciones dinámicas. Dejamos activada la opción No admitir actualizaciones dinámicas y hacemos clic en el botón Siguiente. Página 14

25 9. Por último hacemos clic en el botón Finalizar en la pantalla resumen de creación de la zona. Una vez creada la zona, podemos ver que en la carpeta Zonas de búsqueda directa del Administrador de tenemos un nuevo elemento correspondiente a la zona. Si la seleccionamos veremos en el panel derecho dos registros de recursos: el registro SOA y otro NS, apuntando ambos al servidor primario donde hemos creado la zona. Figura 11.- Registros de recursos en la zona 2.3 Configurar una zona de búsqueda inversa No suele ser necesario en redes pequeñas tener una zona inversa, dependerá de los requerimientos de cada caso en particular. Si necesitamos tener una seguiremos el siguiente proceso: 1. En Administrador del servidor hacemos clic en en el panel izquierdo. 2. En la lista de servidores hacemos clic con el botón derecho del ratón sobre nuestro servidor y posteriormente hacemos clic en la opción Administrador de. 3. Sobre la carpeta Zonas de búsqueda inversa hacemos clic con el botón derecho del ratón y seleccionamos la opción Zona nueva Comienza el asistente de creación de una nueva zona. En la pantalla de introducción hacemos clic en el botón Siguiente. 5. Ahora debemos elegir el tipo de zona. Seleccionamos Zona primaria y hacemos clic en el botón Siguiente. 6. Seleccionamos la versión del protocolo IP para la que estamos definiendo esta zona inversa. Seleccionamos IPv4 y hacemos clic en el botón Siguiente. 7. A continuación introducimos el nombre de la zona inversa. Debemos recordar que este nombre se forma invirtiendo los dígitos de la dirección de red y añadiendo las etiquetas in addr.arpa. Para facilitar la composición del nombre tenemos opción a introducir los dígitos de la dirección de red y el asistente comprondrá el nombre de la zona inversa. Posteriormente hacemos clic en el botón Siguiente. Página 15

26 Figura 12.- Zona de búsqueda inversa 8. Aceptamos el nombre de archivo que empleará para guardar los datos de la zona. Hacemos clic en el botón Siguiente. 9. Indicamos ahora si vamos a permitir o no las actualizaciones dinámicas de nuestro servidor para la zona. Posteriormente, hacemos clic en el botón Siguiente. 10. En la pantalla resumen hacemos clic en el botón Finalizar. Al igual que ocurría antes con la zona de búsqueda directa, vemos que ha aparecido un nuevo elemento en la carpeta Zonas de búsqueda inversa correspondiente a la zona recién creada. También, cuenta dos registros de recursos: el SOA y el NS del servidor que mantiene la zona. 2.4 Añadir registros de recursos a una zona El proceso de añadir registros de recursos es muy similar para los diferentes tipos que existen: A, CNAME, PTR, etc. En principio, solamente sería necesario añadir los registros de recursos para los PC's de la red que tienen una dirección IP estática o reservada. Además, sería conveniente añadir también los alias necesarios en función de los servicios que estos PC's estén prestando (www, ftp, etc.). Para añadir registros de recursos tipo A seguir el siguiente proceso: 1. En el Administrador de seleccionar la zona de búsqueda directa y en el panel derecho hacemos clic con el botón derecho del ratón. Dependiendo del tipo de registro de recurso seleccionaremos una de las siguientes opciones: a) Para un registro de recurso tipo A seleccionamos la opción Host nuevo (A o AAAA) Página 16

27 b) Para un registro de recurso tipo CNAME seleccionamos la opción Alias nuevo (CNAME) c) Para un registro de recurso tipo MX (intercambiador de correo) seleccionamos la opción Nuevo intercambio de correo (MX) 2. Aparece la ventana de creación del registro de recurso nuevo. En función del tipo de registro de recurso introduciremos los datos necesarios. a) Para un registro de recurso tipo A introduciremos el nombre del PC y a continuación la dirección IP. La siguiente figura vemos que solamente tenemos que introducir la última etiqueta del nombre, ya que el asistente completa el FQDN añadiendo el nombre de dominio de la zona. Si dejamos activada la casilla Crear registro del puntero (PTR) asociado creará también un registro PTR en la zona inversa si existiera. Figura 13.- Creación de un registro de recurso tipo A b) Para un registro de recurso tipo CNAME, habrá que introducir el alias y el nombre de dominio completamente cualificado (FQDN) al que apunta este alias. Al igual que antes, para el alias solamente tendremos que introducir la última etiqueta. Esta se completará con el nombre de dominio. Página 17

28 Figura 14.- Alias nuevo c) Los registros de recursos tipo intercambiadores de correo tienen un dato adicional y es la prioridad del servidor de correo para el dominio. Generalmente es un número que comienza por 10 (mayor prioridad) y aumenta de 10 en 10 para prioridades menores. Además, el registro de recurso MX se crea para el dominio principal. Figura 15.- Registro intercambiador de correo 3. Una vez se han introducido los datos hacemos clic en el botón Aceptar. Ahora podemos ver como queda el listado de registros de recursos después de haber creado varios de ellos de diferentes tipos. Como se observa en la siguiente figura tenemos un registro tipo A para el servidor, el cual tiene un alias y un registro MX. Página 18

29 Figura 16.- Registro de recursos en la zona de búsqueda directa En la zona de búsqueda inversa la creación del registro de recurso PTR es muy similar. En este caso los datos que hay que introducir son la dirección IP y el nombre de dominio al que apunta. Figura 17.- Registro de recurso PTR 2.5 El registro SOA El registro de recurso SOA (Start Of Authority) es un tipo de registro de recurso que contiene información sobre la zona como el nombre del servidor que la mantiene, la dirección de correo electrónico del administrador que gestiona la zona, frecuencia de actualización de los servidores secundarios, etc. Este registro de recurso se crea cuando se creó la zona y hay algunos datos que conviene definir mejor. Para acceder a las propiedades del registro SOA debemos hacer lo siguiente: 1. Abrir el Administrador de. 2. En el panel izquierdo y sobre la zona de búsqueda directa o inversa hacer clic con el botón derecho del ratón y seleccionar la opción Propiedades. 3. Hacer clic en la ficha Inicio de autoridad (SOA). Tal y como se ve en la figura siguiente, el registro SOA contiene la siguiente información: Número de serie.- Muestra el número utilizado para determinar si se necesita una transferencia de zona para actualizarla en los servidores secundarios. Cada vez que la zona cambia, este número aumenta en 1 para indicar una nueva versión. Los servidores comprueban y comparan este número durante las solicitudes de actualización de zona para determinar si una zona ha cambiado y si se necesita una transferencia para actualizarla. Si se Página 19

30 hace clic en el botón Incrementar se aumenta este número manualmente, lo que provocará una transferencia de zona. Servidor principal.- Nombre del servidor que está designado como servidor maestro principal de esta zona. Aparece el nombre del servidor parcialmente cualificado. Lo editamos y escribimos su nombre FQDN. Figura 18.- Registro SOA Persona responsable.- Dirección de correo electrónico de la persona responsable de administrar el archivo de zona del dominio en formato, por tanto debemos tener en cuenta que un "." se utiliza en lugar de un "@" en la dirección de correo electrónico. Por defecto aparece hostmaster y aquí introduciríamos una dirección de correo válida. En nuestro ejemplo introduciremos administrador.serviciosenred.local. Intervalo de actualización.- Tiempo que indica la frecuencia de intento de comprobación de un servidor secundario para consultar el registro SOA del servidor principal y comprobar cambios. Cuando caduca el tiempo de actualización, el servidor secundario solicita una copia del registro SOA actual desde el principal. El servidor secundario compara el número de serie del registro SOA de la actual del servidor principal y el número de serie de su propio registro SOA. Si son diferentes, el servidor secundario Página 20

31 solicitará una transferencia de zona desde el servidor principal. El valor predeterminado es 15 minutos. Intervalo de reintento.- Frecuencia con la que un servidor reintentará la transferencia de zona. Este tiempo se utilizará si el intervalo de actualización ha caducado sin que se produjese una actualización correcta. Por defecto son 10 minutos. Expira después de.- Periodo de tiempo que los servidores que almacenan copias secundarias de esta zona utilizarán para determinar cuándo deben caducar los datos de la zona si no se ha comprobado que son correctos y se han actualizado desde el servidor primario. Si una zona caduca, cualquier dato de la zona habrá caducado; es decir, como estos datos pueden ser obsoletos, se descartan y los servidores secundarios de la zona dejan de utilizarlos. Por defecto es 1 día. TTL mínimo.- Tiempo de vida mínimo predeterminado para registros de recursos de la zona. Este valor se utiliza siempre que no se especifica ningún valor TTL para un registro de recursos de la zona. El valor TTL es el tiempo que un servidor o resolución almacenará en caché registros de recursos de esta zona antes de descartarlos. TTL para este registro.- Valor de tiempo de vida para este registro de recurso. Por defecto es 1 hora. 2.6 Servidores de nombres de la zona Por defecto, una zona tiene como mínimo un servidor configurado. Este es el servidor primario donde se ha creado la zona. Sin embargo, es posible que una zona cuente con más servidores de nombres, los secundarios, los cuales mantienen una copia del archivo de la zona. Ya hemos visto anteriormente que el tipo de recurso NS se emplea para registrar los servidores de nombres de una zona. Actualmente en nuestra zona solamente disponemos de un registro de recurso NS, el del servidor primario. Para introducir el del secundario seguir los siguientes pasos: 1. Abrir el Administrador de. 2. En la zona de búsqueda directa e inversa añadir un registro A para el servidor secundario. 3. Posteriormente, sobre la zona de búsqueda directa hacer clic con el botón derecho del ratón y seleccionar la opción Propiedades. 4. Hacer clic en la ficha Servidores de nombres. Como vemos en la figura siguiente, aquí se gestiona la lista de los servidores autorizados en la zona. En principio y con la zona recién creada solamente aparece el servidor primario parcialmente cualificado. Debemos añadir el segundo servidor que actuará como servidor secundario, según el esquema de red del principio del documento. Para añadir otro servidor podemos hacer lo siguiente: 1. Hacer clic en el botón Agregar. 2. Escribir el nombre del dominio completo del servidor y hacer clic en el botón Resolver. Página 21

32 3. El administrador de comprobará la conectividad con el servidor y si está ejecutando el servicio. Cuando lo haga añadirá su dirección IP a la lista inferior. 4. Hacer clic en el botón Aceptar. Ahora debemos de tener dos servidores autorizados en la zona. El segundo es el servidor secundario y posteriormente, en este mismo capítulo, explicaremos como configurarlo. Figura 19.- Servidores de nombres 2.7 Configuración de un servidor secundario Un servidor secundario mantiene una copia de una zona que gestiona un servidor principal. Los clientes pueden tener configurados ambos servidores para resolver consultas. Si el servidor principal está fuera de servicio por cualquier causa, se puede redirigir la consulta al servidor secundario. Para instalar un servidor secundario en una red deberemos hacer las siguientes tareas: 1. Instalar el servicio en el servidor secundario. 2. Configurar en el servidor primario las zonas de búsqueda directa e inversa para que reconozcan y acepten al servidor secundario como servidor de las mismas. Esto permitirá Página 22

33 al servidor secundario realizar las comprobaciones para la actualización de las zonas y las transferencias de zona. 3. Crear las zonas de búsqueda directa, e inversa si la hubiera, en el servidor secundario. 4. Configurar el servidor DHCP para que la opción Servidores contenga también la dirección IP del servidor secundario. El primer paso ya se explicó anteriormente en este mismo documento. Instalar el role en un servidor Windows Server es similar independientemente de si es primario o secundario. Vamos a explicar el segundo. Un servidor no acepta mensajes de comprobación de actualización de una zona de cualquier origen. Esto lo haría vulnerable a ataques por denegación de servicio. Por tanto debemos configurar la zona para indicar que el servidor secundario también es un servidor autorizado de la zona y puede resolver consultas. Además, hay que indicar que este servidor puede realizar comprobaciones para ver si el archivo de zona en el servidor primario es diferente del archivo de zona que el tiene, y si es necesario, realizar una transferencia. Para realizar esta configuración hacer lo siguiente: 1. Abrir el Administrador de en el servidor primario. 2. Añadir un registro tipo A para el servidor secundario en la zona de búsqueda directa y un registro tipo PTR para la zona de búsqueda inversa. 3. Editar las propiedades de la zona de búsqueda directa y en la ficha Servidores de nombres añadir la dirección IP del servidor secundario para que quede registrado como un servidor de nombres de esta zona. 4. Hacer clic en la ficha Transferencias de zona para configurar los servidores a los que se permite hacer una transferencia de zona. Aquí dejaremos activada la casilla Permitir transferencias de zona y disponemos de tres opciones para autorizar las transferencias a otros servidores: a) A cualquier servidor.- Cualquier solicitud de transferencia de zona será atendida. b) Solo a los servidores nombrados en la pestaña Servidores de nombres.- Solo se harán transferencias a los servidores de nombres que están registrados como tales en la zona. Es la opción por defecto y la que se recomienda. c) Solo a los siguientes servidores.- Aquí indicamos las direcciones IP de los servidores a los cuales se harán transferencias de zona. 5. Además también deberíamos configurar las notificaciones. Cuando se produzca un cambio en la zona, el servidor primario enviará una notificación a los servidores secundarios configurados para que también reflejen esta actualización en sus archivos de zona. Para ello hacemos clic en el botón Notificar... en la ficha Transferencias de zona y dejamos activada la opción Notificar automáticamente. Ahora indicamos a quién se notifican los cambios y disponemos de dos opciones: a) Lista de servidores en la pestaña Servidores de nombres.- Se envían las notificaciones a los servidores de nombres registrados en la zona. Es la opción por defecto y la que se recomienda. Página 23

34 b) Los siguientes servidores.- Solamente se envían las notificaciones a los servidores cuya dirección IP aparece en la lista inferior. Figura 20.- Ficha transferencias de zona La zona ya dispone de dos registros NS, el servidor primario y el secundario. Además, están configuradas las transferencias de zona y las notificaciones al servidor secundario. El siguiente paso sería instalar el rol de servidor en el servidor secundario y crear las zonas de búsqueda directa e inversa secundarias. Para ello seguir los siguientes pasos: 1. Abrir el Administrador en el servidor secundario. 2. Sobre la carpeta Zonas de búsqueda directa hacemos clic con el botón derecho del ratón y seleccionamos la opción Zona nueva En la primera pantalla del asistente hacemos clic en el botón Siguiente. 4. Seleccionamos Zona secundaria en el tipo de zona. Hacemos clic en el botón Siguiente. 5. En el nombre de zona introducimos el nombre de la zona. Hacemos clic en el botón Siguiente. Página 24

35 6. Ahora debemos indicar la dirección IP de los servidores maestros de esta zona. Introducimos y pulsamos la tecla Intro. Posteriormente hacemos clic en el botón Siguiente. Figura 21.- Servidores maestros 7. En la pantalla resumen hacemos clic en el botón Finalizar. Si vemos los registros de la zona nos dará un error ya que el servidor secundario no habrá podido cargar los registros del servidor primario. Si pulsamos F5 recargará la zona y estos registros se mostrarán. Conviene recordar que la zona secundaria es copia del archivo de zona en el servidor primario. Por tanto, no podemos realizar ninguna modificación sobre este archivo. Por último, tenemos que configurar los clientes para que dispongan en su configuración de red con ambos servidores. Para ello hay que modificar las opciones de ámbito del servidor DHCP y añadir la dirección IP del servidor secundario en la opción Servidores. Para ello seguir los siguientes pasos: 1. Abrir el Administrador DHCP en el servidor primario. 2. Desplegar el árbol DHCP y seleccionar Opciones de ámbito en el ámbito de la red. 3. Hacer doble clic sobre la opción de ámbito Servidores para editarla. 4. Escribir la dirección IP del servidor secundario y hacer clic en el botón Agregar. 5. Después de validar que el servidor secundario está ejecutando el servicio veremos la opción de ámbito Servidores con las direcciones IP del servidor primario y secundario. Hacemos clic en el botón Aceptar. Página 25

36 Figura 22.- Servidores en las opciones de ámbito A partir de ahora, cuando un cliente obtenga una concesión del servidor DHCP dispondrá de dos servidores. Si no puede contactar con el servidor primario, podrá resolver nombres de la zona en el servidor secundario. Podemos hacer una prueba parando el servidor primario y que el cliente realice una consulta. Inicialmente la enviará al servidor primario y cuando no reciba respuesta, la volverá a enviar, pero esta vez al servidor secundario. Este le responderá y obtendrá la dirección IP del nombre consultado. Para detener el servidor hacemos lo siguiente: 1. Abrir el Administrador en el servidor primario. 2. En el árbol, hacer clic con el botón derecho del ratón sobre el icono que representa al servidor y seleccionar la opción Todas las tareas. Posteriormente seleccionamos la opción Detener. 3. Pulsamos F5 para comprobar que el servidor está parado. Ahora vamos al cliente y en una ventana del símbolo del sistema hacemos una consulta al nombre del servidor secundario. Para ello podemos hacer un ping a esta máquina utilizando su nombre1. ping sewise.serviciosenred.local 1 Para poder hacer ping a un PC con Windows Server o XP hay que revisar el cortafuegos y comprobar que dispone de una regla que permita solicitudes de eco. Si no fuera así, habrá que realizar los cambios necesarios. Página 26

37 El resultado será el siguiente: Figura 23.- Resultado de la utilidad ping al servidor secundario desde el cliente La utilidad ping consulta el nombre suministrado como parámetro al servidor. Si el primario está detenido, pasará la consulta al secundario. Como podemos observar, después del nombre nos viene la dirección IP, con lo que el servidor secundario está funcionando perfectamente. 2.8 Reenviadores Ningún servidor de nombres puede responder a las consultas de todos los clientes; a veces, los clientes consultan un nombre que no se halla en una zona administrada por el servidor. En estos casos, generalmente se emplea la recursividad. Como vimos en un apartado anterior, el servidor recorre el árbol de dominios en sentido inverso hasta encontrar al servidor que administra la zona a la que pertenece el nombre que se desea consultar. Sin embargo, podemos reenviar todas las consultas que nuestro servidor no puede resolver a uno o varios reenviadores. Un reenviador es la dirección IP de un servidor al que se reenvían las consultas que nuestro servidor no es capaz de resolver. Cuando reciba la respuesta, la guardará en caché para futuras consultas similares. Con WS podemos definir un reenviador para una zona específica, es decir, podemos indicar que si un nombre pertenece a una zona en concreto, entonces todas las consultas de nombres pertecientes a esa zona se reenviarían al mismo servidor. Lógicamente, este debe ser la dirección IP del servidor que administra dicha zona. A este tipo de reenviador se le conoce como reenviador condicional. Posteriormente, podemos definir un reenviador al que se pasarían todas las consultas de nombres que no pertenecen a las zonas definidas con reenviadores condicionales. Para definir un reenviador condicional seguir los siguientes pasos: 1. Abrir el Administrador. 2. Desplegar el árbol y sobre la carpeta Reenviadores condicionales hacer clic con el botón Página 27

38 derecho del ratón. Seleccionar la opción Nuevo reenviador condicional Escribir el nombre de la zona en el cuadro de texto Dominio. 4. En la lista Direcciones IP de los servidores maestros escribir las direcciones IP de los servidores que administran la zona anterior. 5. Cuando se haya rellenado la lista hacemos clic en el botón Aceptar. Figura 24.- Reenviador condicional Cómo podemos averiguar el servidor de un dominio para incluirlo como reenviador condicional?. Tendríamos que hacer una consulta nslookup al servidor de nombres de dicho dominio. Más adelante se explica como en el apartado que explica en detalle la utilidad nslookup. Si lo que queremos es definir un reenviador, seguiremos los siguientes pasos: 1. Abrir el Administrador. 2. Desplegar el árbol y sobre el icono que representa al servidor hacer clic con el botón derecho del ratón. Seleccionar la opción Propiedades. 3. En la ventana de propiedades del servidor hacer clic en la ficha Reenviadores. 4. Hacer clic en el botón Editar. Página 28

39 5. Introducir la dirección IP del reenviador. Figura 25.- Reenviadores La cuestión es qué servidor pongo como reenviador? No hay obligatoriedad de configurar un reenviador. De hecho, la primera prueba que hicimos del funcionamiento del servidor fue hacer una consulta a y el cliente obtuvo la respuesta. Entonces, si no hay un reeenviador configurado, donde se envían las consultas de nombres que pertenecen a dominios que no administra el servidor? Emplea los servidores raíz que si tiene configurados el servidor por defecto. La única razón para configurar un reenviador es acelerar las respuestas a peticiones del servidor. Generalmente se suele poner como reenviador el servidor del ISP de nuestra conexión a Internet, y si nuestra red local está conectada a otra red local de ámbito mayor, pues podemos poner el servidor de esta. Si observamos que las consultas se ralentizan en lugar de acelerar, se recomienda quitar los reenviadores y utilizar los servidores raíz para consultas externas a nuestras zonas. 2.9 Actualizaciones dinámicas Actualmente, los servidores implementan actualizaciones dinámicas que cumplen el RFC Estas actualizaciones dinámicas permiten que los clientes de Windows actualicen sus propios Página 29

40 registros de de búsqueda directa y que los servidores de DHCP actualicen los registros de búsquedas directa e inversa de todos los clientes (siempre que esta opción esté activada en el servidor DHCP). También permiten eliminar los registros que no se han actualizado desde hace mucho tiempo, lo que reduce el crecimiento gradual que sufren los archivos de zona. Las actualizaciones dinámicas se tienen que configurar tanto en el servidor como en el DHCP. Para configurarlas en el servidor seguir los siguientes pasos: 1. Abrir el Administrador. 2. Desplegar el árbol y seleccionar con el botón derecho del ratón la zona donde queremos activar las actualizaciones dinámicas. Seleccionar la opción Propiedades. 3. En la pestaña General desplegamos la lista Actualizaciones dinámicas y elegimos Sin seguridad y con seguridad. En el caso de el servidor sea un controlador de dominio también podemos elegir Con seguridad. Figura 26.- Actualizaciones dinámicas 4. Hacer clic en el botón Aceptar. Ahora hay que indicar en el servidor DHCP que cada vez que conceda una dirección IP a un host, si este solicita su actualización en el servidor, la realice. Para ello seguir los siguientes pasos: Página 30

41 1. Abrir el Administrador DHCP. 2. Desplegar el árbol DHCP y sobre la carpeta del ámbito seleccionar DHCP con el botón derecho del ratón. Elegir la opción Propieadades. 3. Hacer clic sobre la pestaña. Figura 27.- Actualizaciones dinámicas en el servidor DHCP 4. Activar la casilla Habilitar actualizaciones dinámicas de acuerdo con la siguiente configuración. 5. Seleccionar si queremos hacer las actualizaciones tanto si los clientes las piden o no. 6. Activar la casilla Descartar registros A y PTR cuando se elimine la concesión. 7. Hacer clic en el botón Aceptar Actualizaciones dinámicas en servidores miembro e independientes Activar las actualizaciones primarias en un servidor miembro o independiente requiere una configuración adicional en el cliente Windows. En este escenario, en el que no existe un dominio de Active Directory, el cliente Windows pertenece a un grupo de trabajo, el cual se anexa al hostname del cliente para formar su nombre completo. Este nombre completo puede verse en la ficha Nombre de equipo en las propiedades del sistema y es utilizado para todas las conexiones de red del equipo. Por defecto, los clientes Windows envían su hostname completo al servidor DHCP en su Página 31

42 petición, el cual será utilizado para registrar su nombre en el servidor. Los nombres de grupo de trabajo no coinciden con los nombres de dominio, al contrario que ocurre en dominios de Active Directory. Esto implica que la actualización dinámica para los clientes que están en grupo de trabajo sobre servidores que se ejecutan en servidores miembro o independientes de la red no se realizará. Sin embargo, en los clientes Windows es posible configurar un nombre de dominio específico para el equipo o para cada conexión de red, y activar también el registro para este nombre de dominio. De esta forma, el cliente Windows enviará una solicitud de registro utilizando su hostname completamente cualificado al servidor que es responsable de la zona. Para configurar un dominio específico para el equipo debemos seguir los siguientes pasos: 1. Abrir la pantalla de información del sistema en el panel de control del equipo cliente. 2. En el apartado Configuración de nombre, dominio y grupo de trabajo del equipo hacer clic en Cambiar configuración. 3. En la pestaña Nombre de equipo de la ventana Propiedades del sistema hacer clic en el botón Cambiar. 4. En la ventana Cambios en el dominio o el nombre del equipo hacer clic en el botón Más En el cuadro de texto Sufijo principal de este equipo escribir el dominio de nuestra red. Posteriormente hacer clic en el botón Aceptar. Figura 28.- Sufijo principal del equipo Cuando se reinicie el ordenador o se renueve la concesión, el equipo cliente enviará su nombre de dominio completamente cualificado al servidor DHCP, el cual lo empleará para registrarlo en el servidor. También se podría configurar un dominio específico para cada conexión de red. Para configurar un dominio específico para una conexión de área local seguir los siguientes pasos: 1. Abrir el Centro de redes y recursos compartidos en el equipo cliente. 2. Hacer clic en el enlace Cambiar configuración del adaptador. 3. Hacer clic con el botón derecho del ratón en la conexión de red que vamos a configurar y, a Página 32

43 continuación, hacer clic en la opción Propiedades. 4. En la ficha General, seleccionar el elemento Protocolo de Internet versión 4 (TCP/IPv4) y, a continuación, en el botón Propiedades. 5. Hacer clic en el botón Opciones Avanzadas. 6. Hacer clic en la ficha. Figura 29.- Sufijo para una conexión de red 7. Escribir el nombre de dominio para esta conexión de red en el cuadro de texto Sufijo para esta conexión. 8. Activar la casilla Usar el sufijo de esta conexión para el registro. 9. Hacer clic en el botón Aceptar. Después de reiniciar el equipo cliente, cuando envíe una solicitud de concesión al servidor DHCP enviará su nombre completamente cualificado con el sufijo configurado para el equipo o para la conexión de red. El servidor DHCP lo empleará para enviar un mensaje de actualización dinámica al servidor en la zona a la que pertenezca. Si nos vamos ahora al Administrador en el servidor primario veremos que en los registros de la zona de búsqueda directa o inversa donde hayamos activado las actualizaciones dinámicas se habrá creado un registro tipo A para el cliente. Página 33

44 Figura 30.- Registro A del cliente creado mediante actualización dinámica 2.10 Delegación de subdominios El sistema proporciona la opción de dividir el espacio de nombres en una o varias zonas, que se pueden almacenar, distribuir y replicar en otros servidores. Cuando se tome la decisión de dividir el espacio de nombres para crear zonas adicionales, hay que tener en cuenta las razones siguientes para utilizar las zonas adicionales: La necesidad de delegar la administración de parte del espacio de nombres en otra ubicación o departamento dentro de la organización. La necesidad de dividir una zona grande en zonas más pequeñas para distribuir las cargas de tráfico entre varios servidores, mejorar el rendimiento de resolución de nombres o crear un entorno con una mayor tolerancia a errores. La necesidad de aumentar el espacio de nombres al agregar numerosos subdominios a la vez, como para adaptarse a la apertura de un nuevo sitio o sucursal. Para ilustrar este concepto, supongamos que tenemos el dominio serviciosenred.local y queremos crear el subdominio windows.serviciosenred.local. En el servidor primario creamos este subdominio y luego delegaremos su administración al servidor secundario que tenemos creado. Esto supone que la zona correspondiente al subdominio será creada y mantenida por el servidor secundario, que será servidor primario para la zona de este subdominio. El servidor primario no tendrá que mantener la zona del subdominio pero deberá tener alguna referencia al mismo para poder responder a consultas sobre nombres que pertenezcan a este subdominio. Resumiendo, para crear un subdominio en un servidor distinto al que mantiene la zona del dominio principal debemos hacer lo siguiente: 1. Crear la zona correspondiente al subdominio en el servidor que va a mantenerlo. A modo de ejemplo utilizaremos sewise. Añadiremos un registro tipo A para hacer una consulta de ejemplo. Página 34

45 2. Crear en el dominio principal una delegación de subdominio que haga referencia al servidor secundario donde está creado. Esto consiste simplemente en un registro NS para informar al servidor primario del servidor que se encargará de administrar el subdominio. Naturalmente, para crear este registro NS deberemos crear antes un registro A que apunte al servidor que administrará el subdominio. Primero creamos en el servidor secundario sewise la zona principal para el subdominio windows.serviciosenred.local de la misma forma que vimos en apartados anteriores. Tener en cuenta que tenemos que cualificar completamente los nombres en el registro SOA y NS. Posteriormente introducimos un registro tipo A para el nombre pc01.windows.serviciosenred.local. La zona quedaría asi: Figura 31.- Subdominio windows.serviciosenred.local Ahora debemos ir al servidor primario del dominio serviciosenred.local y crear la delegación de subdominio. Para ello seguir los siguientes pasos: 1. Abrir el administrador. 2. Desplegar el árbol y hacer clic con el botón derecho del ratón sobre la zona serviciosenred.local en la carpeta Zonas de búsqueda directa. Seleccionar la opción Delegación nueva... Figura 32.- Creación de una nueva delegación de subdominio 3. Hacer clic en el botón Siguiente en la pantalla de bienvenida del asistente para crear una nueva Página 35

46 delegación. 4. Escribir el nombre del subdominio parcialmente cualificado. El administrador se encarga de completar el nombre añadiendo el sufijo del dominio principal. Posteriormente hacer clic en el botón Siguiente. 5. Introducir la dirección IP del servidor que mantiene el subdominio. En este ejemplo será Hay que hacer clic en el botón Agregar y añadir la dirección IP. Al finalizar hacer clic en el botón Siguiente. 6. Hacer clic en el botón Finalizar. Para comprobar que nuestro subdominio está funcionando bien podemos ejecutar desde el cliente una consulta al servidor primario selipr y este debe devolver el resultado de la consulta. La siguiente pantalla ilustra esto Figura 33.- Resultado de la consulta a un nombre del subdominio Como podemos observar, hemos realizado una consulta al nombre pc01.windows.serviciosenred.local y el servidor ha devuelto la dirección IP El proceso de consulta ha sido el siguiente: 1. El cliente pregunta por la dirección IP del host con nombre de dominio pc01.windows.serviciosenred.local. Esta consulta ha sido pasada al servidor primario que el cliente tiene configurado, que en este caso es sewipr ( ). 2. El servidor sewipr no dispone del registro tipo A correspondiente al nombre consultado, ya que tiene delegado el subdominio windows.serviciosenred.local al servidor sewise. Por tanto reenvía la consulta al servidor sewise. 3. El servidor sewise, que si mantiene el subdominio windows.serviciosenred.local, responde a la consulta y devuelve al servidor sewipr la dirección IP El servidor sewipr recibe el resultado y lo devuelve a su vez al cliente que hizo la consulta. Este presenta el resultado por pantalla. Si una zona es muy grande y tiene muchos registros puede ser conveniente dividirla en subzonas y distribuir su mantenimiento entre varios servidores. Esta es la razón principal de los subdominios. Página 36

47 2.11 Servidores raiz Anteriormente vimos los servidores raiz. Aquellos que disponen de información de todo el árbol de dominios. En realidad solamente mantiene referencias a los servidores de los dominios de primer nivel. Las sugerencias raíz indican a los servidores el lugar en que deben buscar los servidores autorizados para el nivel superior de la estructura de dominio. Figura 34.- Sugerencias de raíz Las sugerencias raíz para los servidores raíz de Internet se instalan de manera automática en el archivo Caché.dns ubicado en la carpeta %SYSTEMROOT%\System32l\Dns. Se recomienda no tocar las sugerencias Servidor caché Los servidores de sólo caché son servidores que no albergan ninguna zona y que no están autorizados para ningún dominio, simplemente guardan en caché las consultas que llevan a cabo en nombre de los clientes que utilizan el servidor. Los servidores sólo caché resultan útiles para los sitios que utilizan un enlace WAN lento con otros servidores. Guardando simplemente las consultas en lugar de guardar sus propios archivos de zonas los servidores de sólo caché reducen el tráfico de red, ya que no llevan nunca a cabo Página 37

48 transferencias de zonas. Para configurar un servidor de sólo caché hay que seguir los siguientes pasos: 1. Instalar un servidor en el equipo servidor con dirección IP estática. 2. No crear ninguna zona en el servidor. 3. Comprobar que las sugerencias de raíz del servidor están correctamente configuradas o actualizadas Nslookup Nslookup.exe es una herramienta administrativa de la línea de comandos para probar y solucionar problemas de los servidores. Muestra información que puede usarse para diagnosticar la infraestructura de, es decir, nos permite comprobar si los servidores de nuestro equipo resuelven correctamente las consultas que se le envían Nslookup.exe se puede ejecutar en dos modos: interactivo y no interactivo. El modo no interactivo es útil cuando sólo se necesita resolver una consulta. La sintaxis para el modo no interactivo es la siguiente: nslookup [ opción] [nombre de host] [servidor] A continuación se explican los parámetros del comando opción Especifica uno o varios comandos nslookup como una opción de la línea de comandos. Algunos de los subcomandos más habituales son: -server direccionip nombreservidor.- Establece como servidor predeterminado para realizar las consultas. -retry=número.- Establece el número de reintentos para realizar una consulta. Por defecto se utilizan 4 reintentos. -timeout=milisegundos.- Especifica el número de milisegundos que se esperará por cada respuesta. El número predeterminado de segundos de espera es 5. -type=tiporecurso.- Especifica un tipo de registro de recursos. El tipo de registro de recursos predeterminado es A. La tabla siguiente muestra los valores válidos para este comando. Valor A ANY CNAME GID HFO MB MG MFO MR MX NS PTR Descripción Especifica la dirección IP un equipo. Especifica todos los tipos de datos. Especifica un nombre canónico para un alias. Especifica el identificador de grupo de un nombre de grupo. Especifica el tipo de CPU y sistema operativo de un equipo. Especifica un nombre de dominio de buzón Especifica un miembro de un grupo de correo. Especifica información del buzón o de la lista de correo. Especifica el nombre de dominio de correo cambiado. Especifica el intercambiador de correo. Especifica un servidor de nombres de la zona con nombre. Especifica un nombre del equipo si la consulta es una dirección IP. Si no, dirige el puntero a otra información. Página 38

49 SOA TXT UID UFO WKS Especifica el inicio de autoridad de una zona. Especifica la información de texto. Especifica el identificador de usuario. Especifica la información de usuario. Describe un servicio conocido. ls [opt] dominio [> fichero].- Muestra información sobre un dominio. Esto es útil para ver todos los hosts que hay dentro de un dominio remoto. El resultado puede volcarse en un fichero. Las opciones que podemos usar son: -a Devuelve alias y nombres canónigos. -d Devuelve todos los datos del dominio -t Filtrará por tipo exit.- Sale de nslookup. nombre de host Busca información del host utilizando el servidor de nombres predeterminado actualmente, si no se especifica otro servidor. Para buscar un equipo fuera del dominio actual, cualificar completamente el nombre del host con un punto final. servidor Especifica que este servidor se utilice como servidor de nombres. Si se omite, se usará el servidor de nombres predeterminado. help? Muestra un breve resumen de los subcomandos de nslookup. La sintaxis para el modo interactivo es la siguiente: nslookup [ ] [servidor] Si queremos ejecutar nslookup en modo interactivo y utilizar un servidor diferente al predeterminado deberemos utilizar el guión en lugar del nombre de host y a continuación indicar la dirección IP o el nombre del servidor que queramos utilizar. Al entrar en modo interactivo mostrará un prompt. A partir de entonces solo hay que teclear la consulta a resolver para que muestre el resultado. Si queremos utilizarl alguna opción de las anteriores, debemos anteponer set al nombre del comando y omitir el guión. La longitud de la línea de comandos debe ser menor de 256 caracteres. Si el nombre de host buscado es una dirección IP y la consulta se va a realizar para un tipo de registro de recursos A o PTR, se devolverá el nombre del equipo. Si el nombre de host es un nombre parcialmente cualificado, el nombre predeterminado del dominio se anexa al nombre. Vamos a ver algunos ejemplos que ejecutaremos desde el cliente de windows. Comenzaremos por uno sencillo en el que deseamos consultar la dirección IP del cliente de windows en el dominio serviciosenred.local. Página 39

50 Figura 35.- Resultado de la consulta clwi Como podemos apreciar en la imagen anterior hemos utilizado el modo no interactivo. Solamente se ha pasado como parámetro el nombre del host parcialmente cualificado y por defecto se ha añadido el sufijo de la configuración de red para formar el nombre totalmente cualificado. El servidor utilizado ha sido sewipr y el resultado de la consulta es la dirección IP A continuación vamos a realizar una consulta inversa del servidor secundario. Para ello indicaremos la dirección IP de éste. Figura 36.- Resultado de una consulta inversa En el siguiente ejemplo queremos buscar la dirección IP del host el cual se encuentra fuera del dominio por defecto del equipo, por tanto tendremos que cualificarlo completamente para evitar que le anexe el sufijo de la configuración de red. Figura 37.- Resultado de la consulta Podemos emplear un servidor diferente al predeterminado para realizar la consulta. El siguiente ejemplo hacemos una consulta de la dirección IP de utilizando el servidor del propio dominio yahoo.com. Página 40

51 Figura 38.- Resultado de la consulta al servidor ns1.yahoo.com En el siguiente ejemplo estamos consultando la dirección IP del nombre y aumentamos el timeout a un minuto. Figura 39.- Resultado de la consulta con un timeout de 1 minuto En el siguiente ejemplo consultamos la dirección IP de los servidores de correo de gmail.com. Nótese que tenemos que indicar el tipo de registro a consultar. Cuando se consultan registros tipo MX o NS debemos de indicar como nombre de host el nombre de dominio ya que estos registros se definen para el dominio completo. Página 41

52 Figura 40.- Resultado de la consulta para los servidores de correo de gmail.com En modo iterativo primero ejecutaremos nslookup sin opciones ni parámetros, salvo la dirección IP del servidor que queramos utilizar en lugar del predeterminado. En este caso hay que sustituir el nombre de host por el guion. Al hacerlo veremos el siguiente prompt Figura 41.- Prompt del modo interactivo Ahora solo hay que escribir el nombre buscado y pulsar la tecla Intro. Figura 42.- Consulta en modo interactivo Si queremos configurar alguna opción deberemos de anteponer set al nombre de la opción. Página 42

53 En el ejemplo siguiente aumentamos el timeout a un minuto. Posteriormente consultamos la dirección IP del nombre Figura 43.- Resultado de nslookup con timeout de 1 minuto Si la solicitud de búsqueda da error, nslookup imprime un mensaje de error. La tabla siguiente enumera los posibles mensajes de error. Mensaje de Error Tiempo de espera agotado Sin respuesta del servidor No hay registros Dominio inexistente Conexión rechazada No se puede tener acceso a la red Error del servidor Rechazado Error de formato Descripción El servidor no respondió a una solicitud transcurrido un período de tiempo tras determinado número de reintentos. Puede cambiar el período de tiempo de espera con el subcomando set timeout. Puede establecer el número de reintentos con el subcomando set retry. No se está ejecutando ningún servidor de nombres en el equipo servidor. El servidor de nombres no tiene registros de recursos del tipo de consulta actual para el equipo, aunque el nombre del equipo es válido. El tipo de consulta se especifica con el comando set querytype. No existe el equipo o el nombre del dominio. No se pudo establecer la conexión con el servidor de nombres o con el servidor finger. Este error suele producirse en las solicitudes ls y finger. El servidor de nombres detectó una incoherencia interna en su base de datos y no pudo devolver una respuesta válida. El servidor de nombres no atendió la solicitud. El servidor de nombres encontró que el paquete de solicitud no tenía el formato apropiado. Esto puede indicar que hay algún error en nslookup. Página 43

54 2.14 Uso de ipconfig para La utilidad en línea de comando ipconfig dispone de algunas opciones para interactuar con un servidor. Concretamente hay tres, las cuales pasamos a ver a continuación. ipconfig /registerdns Esta opción inicia el registro dinámico de forma manual de los nombres y las direcciones IP del sistema que están configurados en el equipo. Esta opción puede ayudar a solucionar un problema de registro de nombres con errores o un problema de actualización dinámica entre un cliente y un servidor sin necesidad de reiniciar el cliente. El comando actualiza todas las concesiones de direcciones DHCP y registra todos los nombres relacionados que el equipo cliente configura y usa. ipconfig /displaydns Permite ver el contenido de la caché de resolución de un cliente, lo que incluye las entradas cargadas previamente desde el archivo Hosts local, así como los registros de recursos obtenidos recientemente para las consultas de nombres resueltas por el sistema. El servicio Cliente utiliza esta información para resolver rápidamente los nombres consultados con más frecuencia antes de consultar sus servidores configurados. ipconfig /flushdns Borra el contenido de la caché de resolución de nombres de un cliente. 3. Bind 9 BD (Berkeley Internet Name Domain, anteriormente Berkeley Internet Name Daemon) es una implementación en código abierto del protocolo. Es comúnmente usado en sistemas Unix y Linux, en los cuales es un estándar de facto. La versión actual de BD (BD 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 BD, y también para incorporar SEC ( Security Extensions). BD 9 incluye entre otras características importantes: TSIG, notificación, nsupdate, IPv6, rndc flush, vistas, procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. BD consta de tres partes: El servidor.- Es el programa named (name daemon), el cual responde a las consultas que se le plantean siguiendo las reglas especificadas en el protocolo. Biblioteca resolver.- El resolver es el programa que resuelve consultas enviándolas a las servidores adecuados. Una biblioteca resolver es una colección de componentes software que un programador puede añadir a un software en desarrollo lo que le dará la capacidad de resolver consultas. Por ejemplo, un programador que está desarrollando un nuevo navegador web no necesita crear la parte que busca nombres, ya que puede añadir la biblioteca resolver y enviar las consultas a los componentes de la biblioteca resolver. Esto ahorra tiempo de desarrollo del nuevo navegador web y se asegura que el nuevo navegador cumple los estándares. Herramientas software para probar servidores.- Estas son las herramientas que usamos para prueba y que se incluyen en la distribución para que los administradores de red puedan Página 44

55 realizar sus pruebas que verifiquen la correcta configuración del servidor. BD es desarrollada y mantenida por ISC (Internet Systems Consortium) en desde donde se puede descargar el código fuente y la documentación necesaria. 3.1 Instalación del servidor En este capítulo se verá la instalación desde binarios para distribuciones Debian/Ubuntu que emplean la herramienta apt get para la instalación de paquetes binarios. Para ello, abrir una ventana de terminal y como usuario root ejecutar el siguiente comando: apt get install bind9 dnsutils La instalación desde paquete binario incluye el script que pone en marcha el servidor al arrancar el ordenador, así que tan solo será necesario configurarlo. El segundo paquete instala algunos comandos que permiten realizar pruebas en el servidor Bind. Cuando se produzcan cambios en la configuración del servidor será necesario reiniciar Bind con la ejecución de este comando como usuario root. service bind9 restart 3.2 Archivos de configuración La configuración se almacena en varios ficheros texto que se encuentran en el directorio /etc/bind. El archivo principal de la configuración es /etc/bind/named.conf, el cual contiene las opciones genéricas del servidor y la declaración de las zonas de búsqueda. Sin embargo, para añadir claridad a la configuración, tanto las opciones del servidor como las declaraciones de zona se han definido en dos archivos aparte que se incluyen aquí con la directiva include. Por tanto, inicialmente, este archivo sólo contiene la configuración necesaria para definir los servidores raíz y ha definido zonas de búsqueda para resolver el equipo local (localhost). Para añadir zonas de búsqueda tenemos que emplear el archivo /etc/bind/named.conf.local y las opciones genéricas del servidor se añaden al archivo /etc/bind/named.conf.options. Resumiendo, disponemos de los siguientes archivos de configuración principal: /etc/bind/named.conf.- Archivo de configuración principal de Bind. Se recomienda no modificar este archivo. /etc/bind/named.conf.options.- Archivo con las opciones genéricas del servidor. /etc/bind/named.conf.local.- Archivo con la declaración de las zonas de búsqueda. Aparte de estos tres, existen más archivos de configuración, ya que cada zona de búsqueda tiene su propio archivo de configuración en el que se definen los registros de recursos. Los servidores raíz están declarados en el archivo /etc/bind/db.root el cual no es necesario modificar Comprobación de la sintaxis en los archivos de configuración La sintaxis de los archivos de configuración es especialmente propensa a errores. Un punto olvidado u otro tipo de error trivial en un nombre de dominio pueden provocar que el servidor no resuelva consultas o incluso que no pueda arrancar. Para evitarlo, BD dispone de dos utilidades que comprueban la sintaxis del archivo named.conf y de los archivos de zona, informando en el Página 45

56 caso de que hubiera un error. Para comprobar el archivo de configuración named.conf o named.conf.local tenemos la herramienta named checkconf que emplearíamos como sigue: named checkconf named.conf named.conf.local Solamente hay que pasarle como parámetro el nombre de archivo que queremos comprobar. Si está correctamente escrito, no produce ningún resultado en la salida estándar. Si, por el contrario, existe algún error de sintaxis, lo visualizará. Para los archivos de zona disponemos de named checkzone que se emplearía así: named checkzone dominio archivo_zona Hay que indicar el dominio que representa el archivo de zona y también éste. Por ejemplo, para la zona serviciosenred.local configurada en el archivo serviciosenred.local.db, comprobaríamos su sintaxis así: named checkzone serviciosenred.local serviciosenred.local.db Si quisieramos comprobar la sintaxis de la zona de resolución inversa para la red /24 que está configurada en el archivo db haríamos la comprobación así: named checkzone in addr.arpa db 3.3 Configuración de un servidor primario En este modo de funcionamiento, nuestro servidor se comporta como un auténtico servidor para nuestra red local. Atenderá directamente a las peticiones de resolución de direcciones pertenecientes a la zona local y reenviará a servidores externos las peticiones del resto de nombres en Internet. Nuestro servidor maestro para nuestro dominio serviciosenred.local 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 selipr.serviciosenred.local deberá devolver su IP, en este caso Si la consulta es una consulta inversa acerca del nombre del PC con dirección IP , deberá responder selipr.serviciosenred.local. Una zona de búsqueda directa o inversa se define en el archivo named.conf.local mediante una declaración zone. Posteriormente, habrá que definir un archivo para cada zona el cual contiene los recursos de registros. Una declaración de zona tiene la siguiente sintaxis: zone nombre_zona { opciones de zona }; Las opciones que se incluyen dentro de la sección configuran la zona de búsqueda para este servidor. Por ejemplo, para la zona serviciosenred.local debemos añadir la siguiente declaración en el archivo /etc/bind/named.conf.local. zone serviciosenred.local { type master; file /etc/bind/zonas/serviciosenred.local.db ; }; Página 46

57 Como se puede observar, la zona se denomina con el nombre del dominio serviciosenred.local. El tipo de servidor para esta zona es primario ( master) y el fichero de zona es /etc/bind/zonas/serviciosenred.loca.db. El nombre de archivo de zona es libre, pero es habitual que sea el mismo nombre que el del dominio y añadiendo el sufijo.db. Para declarar una zona de búsqueda inversa, debemos añadir la siguiente declaración de zona en el mismo archivo anterior zone in addr.arpa { type master; file /etc/bind/zonas/ db ; }; En ambos casos estamos indicando que los archivos de zona se encontrarán ubicados en el directorio /etc/bind/zonas el cual es un subdirectorio del directorio raíz de BD. Sin embargo, estos archivos se pueden introducirse en cualquier lugar del disco, aunque sería necesario realizar retoques en la configuración de seguridad del equipo para que el proceso named pudiera leer estos archivos. Sin embargo, podemos colocarlo en un subdirectorio de /etc/bind y no sería necesario realizar ninguna configuración adicional. A continuación se definen los archivos correspondientes a cada zona Archivo de zona de búsqueda directa Los datos que hay en el archivo de zona de búsqueda se dividen en Registros de Recursos (RR), las unidades de información más pequeñas disponibles mediante. Cada RR tiene un tipo. Los RR s en los archivos de zona comparten el mismo formato: [dominio] [ttl] [clase] tipo datos_recurso Los campos están separados por espacios o tabulaciones. Una entrada puede continuar a lo largo de varias líneas si aparece un paréntesis de apertura antes de la siguiente línea y al final del último campo hay un paréntesis de cierre. Los comentarios comienzan con punto y coma. A continuación se describe cada campo: dominio.- Es el nombre de dominio al que se aplica la entrada. Si se omite, se aplica el dominio del anterior RR. ttl.- Para obligar a los sistemas de resolución de nombres a eliminar información pasado un cierto tiempo, cada RR tiene asociado un tiempo de vida útil (TTL). Este campo especifica el tiempo, en segundos, que la información será válida tras obtenerla del servidor. Es un número decimal con un máximo de ocho dígitos. clase.- Es una clase de dirección, como para direcciones IP o HS para objetos de la clase Hesiod. Para las redes TCP/IP, tenemos que especificar. Si no se especifica una clase, se presupone que es la clase del anterior RR. tipo.- Describe el tipo del RR. Los tipos más comunes son A, SOA, PTR y NS. Las siguientes secciones describen los diferentes tipos de RR. datos_recurso.- Contiene los datos asociados al RR. El formato de este campo depende del tipo de RR. A continuación vamos a detallar el archivo de zona para serviciosenred.local con los registros de Página 47

58 recursos especificados en la información técnica del principio de este documento. Esta zona estará definida en /etc/bind/zonas/serviciosenred.local.db, tal y como se especificó en la declaración de la zona del apartado anterior. $ORIG serviciosenred.local. $TTL 1d ;Siempre que se haya un cambio en el dominio, actualizar el valor serial ;en el registro SOA. El formato más fácil es: YYYYMMDDI, ;con I como un contador en el caso de que se haga más ;de un cambio en el mismo día. ;El registro SOA selipr usuario h 4h 4w 1d ) ( ;serial ;refresh ;retry ;expire ;minimum ;Registros NS con los servidores de NS NS selise ;Intercambio de correo MX 10 selipr ;Definimos ftp www smtp pop3 imap alias para servicios con CNAME CNAME selipr CNAME selipr CNAME selipr CNAME selipr CNAME selipr ;Registros selipr selise sewipr A A A A Pasemos a analizar con detenimiento este archivo. Su aspecto parece bastante complejo pero debemos tener en mente que cada línea es un registro de recursos, excepto las primeras que se emplean para definir datos genéricos a todos los recursos. $ORIG serviciosenred.local. La directiva $ORIG establece el nombre del dominio de la zona. El punto final es imprescindible ya que el dominio tiene que estar completamente cualificado y el punto final hace referencia a la raíz del sistema de nombres. Podríamos omitir esta directiva, pero en cada registro donde pusiéramos un nombre de dominio habría que cualificarlo completamente. Por ejemplo, en la definición del registro selipr A tendríamos que haber puesto Página 48

59 selipr.serviciosenred.local A La siguiente línea es la definición del TTL. Este dato indica a los equipos clientes que consultan el servidor la frecuencia con la que se debe actualizar sus propias cachés. $TTL 1d El valor 1d establece un valor por defecto para el tiempo de vida de un día. En general, un valor referido a un espacio de tiempo puede establecerse como un número que especifica los segundos. También se pueden establecer mediante un número y una letra que indica el periodo de tiempo. Los valores pueden tener estos formatos: w.- Semana d.- Día h.- Hora m.- Minuto s.- Segundo Si el sitio es muy estático, es mejor establecer valores altos. Si se introducen cambios con frecuencia, es mejor utilizar un valor menor. Cuanto más pequeño es el TTL, más solicitudes llegarán al SOA selipr usuario h 4h 4w 1d ) ( ;serial ;refresh ;retry ;expire ;minimum Este registro define el inicio de autoridad (SOA, Start of Authority) y como puede apreciarse tiene un formato especial en el último campo, el cual a su vez se divide en varios subcampos. sustituye al nombre del dominio, indica la clase del registro, que en este caso es Internet. SOA establece que es el inicio de un archivo de zona. El registro SOA tiene los siguientes elementos en el campo de datos: MNAME.- El servidor de nombres maestro para la zona. En este caso el servidor será selipre.serviciosenred.local. RNAME.- La dirección de correo del administrador del dominio. Aunque se indique usuario.serviciosenred.local ya sabemos que es una dirección de en formato, es decir, sería usuario@serviciosenred.local. Serial.- BD convierte los archivos de zona en un formato de archivo binario. Al hacer cambios al archivo de zona, también debe cambiar el número de serie o BD no reconocerá esas modificaciones. Refresh.- Indica a los servidores secundarios la frecuencia con la que deben actualizarse. Retry.- Si el servidor primario de una zona falla en responder la solicitud de actualización de un servidor secundario, esto indica al servidor secundario la frecuencia con la Página 49

60 que debería reenviar su solicitud. Expire.- Si el servidor maestro falla en un periodo de tiempo más largo, esto indica al servidor secundario cómo seguir utilizando sus datos actuales. Una vez haya transcurrido el tiempo de expiración, los datos se considerarán inválidos y no se usarán, momento en que el dominio no se resolverá. Minimum, o caché TTL negativo.- Las respuestas negativas, como las correspondientes a solicitudes de registros inexistentes, también deberían ser almacenadas en caché en los servidores no autorizados. Establecer este valor evitará que el servidor se vea golpeado por un cúmulo de solicitudes repetidas en un espacio corto de tiempo. Un uso común de esto se da cuando se está cambiando a un nuevo servidor de nombres en una dirección IP diferente. Establecer un valor pequeño en el servidor, unos cuantos días antes de cerrarlo, asegurará que la propagación del cambio se NS NS selipr selise Los siguientes registros de recursos definen los servidores de nombres autorizados en la MX 10 selipr A continuación viene el el servidor de correo. Si hay más de un servidor de correo para el dominio, el número establece la prioridad. Números menores indican mayor prioridad. ftp www smtp pop3 imap CNAME CNAME CNAME CNAME CNAME selipr selipr selipr selipr selipr Los registros CNAME definen alias para el servidor. Estos alias se emplearán para acceder a diferentes servicios como ftp, web y correo electrónico. Cada uno de ellos hace referencia al servidor selipr que se define en sus respectivo registro tipo A. selipr selise sewipr A A A Finalmente llegamos a los registros A que es la dirección IP de cada uno de los equipos. Hemos definido tres registros tipo A para tres equipos. El servidor, un servidor secundario y el servidor primario de Windodws Archivo de zona búsqueda inversa La sintaxis del archivo de búsqueda inversa es muy similar al de búsqueda directa. El contenido del archivo /etc/bind/zonas/ db sería el siguiente. $ORIG in addr.arpa. $TTL SOA selipr.serviciosenred.local. usuario.serviciosenred.local. ( ; serial ; refresh (8 horas) ; retry (4 horas) ; expire (4 semanas) ; minimum (1 día) Página 50

61 ) ; servidor de nombres NS NS selise.serviciosenred.local. ; equipos de la red 1 PTR selipr.serviciosenred.local. 10 PTR selise.serviciosenred.local. Las directivas $ORIG y $TTL tienen la misma función anterior. En este caso el valor de $ORIG es la zona de búsqueda inversa. Recordemos que el nombre de dominio inverso es la dirección de subred invertida y a las que se le ha añadido las etiquetas in addr y arpa. A continuación viene el registro SOA selipr.serviciosenred.local. usuario.serviciosenred.local. ( ; serial ; refresh (8 horas) ; retry (4 horas) ; expire (4 semanas) ; minimum (1 día) ) Aquí también hay un registro SOA, pero con la diferencia de que el nombre del servidor maestro para la zona y la dirección de correo del administrador del dominio deben estar completamente cualificados, ya que el valor de $ORIG no es el mismo que en el archivo de zona de búsqueda directa. Además, los tiempos están en segundos, en lugar de especificarlos con sus periodos NS NS selipr.serviciosenred.local. selise.serviciosenred.local. Igual que antes, hay que definir el servidor de nombres autorizado para la zona y debe estar completamente cualificado PTR PTR selipr.serviciosenred.local. selise.serviciosenred.local. Por último se definen los registros punteros. El primer valor de cada registro es el último byte de la dirección IP. El resto de la dirección se completa con el dominio inverso. PTR es el tipo de registro y finalmente el nombre de dominio completamente cualificado. 3.4 Comprobación del funcionamiento del servidor Una vez hemos instalado Bind y configurado las zonas directa e inversa que administra podemos realizar pruebas desde la red local para verificar que está funcionando perfectamente. En este punto debemos recordar que el servidor debe poder resolver cualquier nombre, es decir, pertenezca o no a una zona administrada por nuestro servidor. Recién instalado Bind ya tenía capacidad para resolver nombres reenviando las consultas a los servidores raíz. Para poder realizar consultas en los clientes debemos instalar el paquete dnsutils, el cual incluye las herramientas para probar servidores, como nslookup o dig. Así que debemos ejecutar el siguiente comando en una ventana de terminal del cliente. Página 51

62 apt get install dnsutils Cuando termine la instalación podemos hacer una consulta con nslookup con el nombre del servidor Figura 44.- Consulta desde el cliente Vemos que ha respondido , con lo que está resolviendo nombres en nuestra zona. También podemos ver que hemos hecho una consulta de un nombre parcialmente cualificado y en la respuesta nos aparece el nombre completamente cualificado. Esto es así porque en la concesión del servidor DHCP el tipo de opción dominio primario está puesto a serviciosenred.local. Ahora vamos a realizar una consulta de un nombre en Internet, como El resultado es el siguiente Figura 45.- Resultado de la consulta De nuevo ofrece una respuesta. Ahora podemos hacer una consulta a la zona inversa. En el siguiente ejemplo pedimos el nombre del ordenador con dirección IP y vemos que nos devuelve correctamente selise.serviciosenred.local. Página 52

63 Figura 46.- Consulta inversa Una vez comprobado que el servidor funciona correctamente debemos configurar el servidor primario para que lo utilice para resolver sus consultas de nombres. De esta forma podrá resolver nombres de la zona que él mismo administra. La forma de hacerlo dependerá de si el servidor obtiene las direcciones IP de sus servidores de forma automática, con una concesión DHCP junto con el resto de los parámetros IP, o hemos configurado la tarjeta de red de forma estática. Si estamos en el primer caso tendremos que configurar el cliente DHCP para que cuando obtenga una concesión de un servidor DHCP incluya la dirección IP como servidor antes que las direcciones IP de los servidores que le vienen con la concesión. Para ello debemos editar el archivo /etc/dhcp/dhclient.conf y añadir las siguientes líneas prepend domain name servers ; prepend domain search serviciosenred.local ; La primera ya viene incluida pero está comentada. Solamente eliminamos el # del inicio de línea y añadimos la otra debajo. Cuando desactivemos ( ifdown) y activemos (ifup) la tarjeta de red podemos comprobar el contenido del archivo /etc/resolv.conf. Figura 47.- Desactivación de la tarjeta de red externa La figura anterior se muestra la desactivación de la tarjeta de red externa. En la siguiente aparece la activación. Página 53

64 Figura 48.- Desactivación de la tarjeta de red externa Ahora mostramos el contenido del archivo /etc/resolv.conf. Figura 49.- Contenido del archivo resolv.conf Aunque esta forma de configurarlo parezca algo engorrosa hay que hacerlo así. En ningún caso editar directamente el archivo /etc/resolv.conf ya que este archivo es generado automáticamente cuando la tarjeta de red recibe una concesión, con lo que cualquier cambio que hagamos será sobreescrito. En el caso de que la tarjeta de red se configure de forma estática podemos establecer manualmente las direcciones IP de los servidores. Podemos utilizar el applet del NetworkManager que aparece en casi todas las distribuciones Linux. Sin embargo, personalmente prefiero utilizar el modo clásico de configuración de la red con el archivo /etc/network/interfaces. En la siguiente imagen aparece la configuración completa de la tarjeta de red externa como si estuviera configurada estáticamente en lugar de automática como la tenemos. auto enp0s3 iface enp0s3 inet static address netmask network broadcast gateway dns nameservers dns search serviciosenred.local Cuando volvamos a activar la tarjeta veremos /etc/resolv.conf es el mismo que aparece antes. que el contenido del fichero 3.5 Localizar errores del servidor Si he cometido algún error en la sintaxis de la configuración de Bind o de algún archivo de zona no lo puedo saber hasta que pruebe el servidor. Si no hace lo que se supone tiene que hacer, cómo Página 54

65 puedo localizar el error? Cuando reinicio Bind no me muestra ningún mensaje, así que no puedo saber si está correctamente configurado o no. En esta situación tengo varias posibilidades en función del tipo de error que hayamos podido cometer Error de sintaxis en los archivos de configuración Si he cometido algún error de sintaxis y no he escrito bien alguna de las directivas en el archivo /etc/bind/named.conf.local o /etc/bind/named.conf.options puedo averiguarlo rápidamente empleando la utilidad named checkconf vista anteriormente. Veamos el siguiente ejemplo: si elimino las comillas finales del nombre de zona en una declaración zone nos mostrará lo siguiente Figura 50.- Comprobación de sintaxis con named-checkconf Vemos que nos indica un error en la línea 11 del archivo /etc/bind/named.conf.local. A veces el error no lo localiza bien, ya que me indica la línea 11 cuando lo tengo en la línea 9. Al encontrarse unas comillas abiertas ha continuando leyendo el archivo hasta encontrar las siguientes comillas en la directiva file. En este caso, aunque no ha sido muy preciso, nos ha indicado un error. Nos corresponde a nosotros revisar el fichero utilizando las pistas que nos ofrece named checkconf Error de sintaxis en los archivos de zona Algo parecido tenemos con los archivos de zona. En este caso disponemos de la utilidad named checkconf la cual nos indica si hemos cometido algún error en la sintaxis del archivo de zona. Por ejemplo, supongamos que al escribir un dominio en la directiva ORIG olvidamos completarlo con el punto final. Al ejecutar la comprobación del archivo de zona directa veremos lo siguiente. Figura 51.- Comprobación de un archivo de zona directa Nos indica que el registro SOA no está al principio del archivo. En este caso los mensajes de error no son muy explícitos, aunque tenemos la seguridad de que hay un error y debemos revisar el archivo. En este otro ejemplo he olvidado escribir el número de serie en el registro SOA. Figura 52.- Comprobación del archivo de zona directa Ahora ha sido más preciso. Me indica que en la línea 8, donde tenemos el registro SOA, hay un error de número inválido, ya que el número de serie es un número entero y ha encontrado 5h, el tiempo de actualización con los servidores secundarios. Página 55

66 Un detalle importante para no volvernos locos usando named checkzone es que el dominio que se le pasa como primer argumento y el dominio en el archivo de zona tienen que coincidir. De lo contrario nos dará múltiples errores en un archivo de zona que podría estar perfectamente escrito. Veamos el siguiente ejemplo Figura 53.- Comprobación de archivo de zona con dominio incorrecto En la imagen anterior vemos que comprobamos el archivo de zona serviciosenred.local con el dominio serviciosenred.com. Evidentemente va a fallar e indica un error por cada registro encontrado diciendo que está fuera de la zona ya que pertenecen a un dominio diferente. También nos dice que no hay un registro SOA ni NS Log del sistema Hay otros errores que no son de sintaxis, y estos no los pueden detectar las utilidades anteriores. Por ejemplo, supongamos que declaramos una zona y escribimos perfectamente el archivo de zona siguiendo la sintaxis. Tanto named checkconf como named checkzone nos indicarán que no hay errores. Sin embargo, si escribimos el nombre del archivo de zona en la directiva file y este nombre, o el path, no coincide con el nombre y la ubicación del fichero de zona, entonces tendremos un error más difícil de detectar. También, es posible que hayamos escrito mal el nombre del dominio en la directiva file, el cual no coincidirá con el nombre de dominio en el archivo de zona. En estos casos tendremos que utilizar el log del sistema para averiguar que ha pasado. El sistema operativo utiliza el archivo /var/log/syslog para registrar eventos, sucesos, errores, etc. del propio sistema operativo o de algún servicio instalado que no tenga un log propio. También podemos configurar un registro de errores propio para Bind, ya que el log del sistema contiene los mensajes de muchos servicios y del propio kernel del sistema y están todos mezclados, dificultando la localización del error. Aquí emplearemos el registro log. Cuando Bind se reinicia, escribe unas líneas en el archivo /var/log/syslog. Para comprobar si todo ha ido bien lo mejor es consultar el final del archivo justo después de reiniciar Bind. Por ejemplo, supongamos que hemos equivocado el path del archivo en la declaración de zone y reiniciamos Bind. Inmediatamente después ejecutamos este comando. tail 20 /var/log/syslog grep named El comando tail nos muestra las líneas finales de un archivo de texto. En este caso le pedimos las últimas 20 del archivo con el log del sistema. La salida del comando se envía como entrada al comando grep para que solamente muestre las líneas que contienen la palabra named. Todas las líneas enviadas al log del sistema por Bind se etiquetan con el demonio del servidor de nombres. Por ejemplo, la siguiente imagen muestra las líneas log cuando reiniciamos Bind y hemos escrito Página 56

67 mal el path del archivo de zona en la declaración zone. Figura 54.- Archivo log Hemos discriminado algunas líneas que no nos interesan. Vemos que cuando intenta cargar la zona serviciosenred.local no puede porque no encuentra el archivo ( file not found). Sin embargo vemos que el resto de zonas si las ha cargado bien. Aquí también se volcarían errores de sintaxis, por lo que si hacemos algún cambio en los archivos de configuración o los archivos de zona y hemos olvidado comprobarlos con las utilidades named checkconf y named checkzone podemos comprobar si hay errores de sintaxis en el log del sistema. En el siguiente ejemplo hemos olvidado poner el punto y coma después de cerrar la llave en la declaración zone. Figura 55.- Archivo log. Error en la sintaxis Vemos que nos ofrece el mismo mensaje que habría dado la comprobación del archivo de configuración. En el siguiente ejemplo hemos cometido un error en el archivo de zona. Hemos suprimido el número 10 en la precedencia del intercambiador de correo, es decir, en el registro MX. Al consultar el log del sistema veremos lo siguiente Figura 56.- Archivo log. Error en el archivo de zona Ahora se observa que no ha cargado el archivo de zona por haberse encontrado un error en su sintaxis. En este caso el error se encuentra en la línea 18 e indica que el nombre selipr no es un número válido, ya que el campo datos del registro de tipo MX necesita un número entero, la prioridad del servidor de correo, y el nombre del servidor de correo. Es importante señalar en este punto que un error en un archivo de zona evita que se carguen los datos de esa zona, pero si los archivos de configuración de Bind son correctos el servidor arrancará y funcionará bien excepto para la zona errónea, en la que no podrá resolver nombres. Por supuesto, si el error está en los archivos de configuración Bind no arrancará y por tanto los clientes de la red local no tendrán resolución de nombres. 3.6 Configuración de un servidor secundario Una vez que se tiene un servidor primario configurado y en funcionamiento podemos añadir a la red un servidor secundario que nos proporciona tolerancia a fallos en la red. Si el primario falla, el secundario puede seguir dando servicio a los clientes. Para ello es necesario cuatro pasos: Página 57

68 1. Configurar los archivos de zona directa e inversa de tal forma que el servidor secundario aparezca como uno de los servidores de nombres autorizados del dominio. 2. Configurar el servidor primario para que notifique los cambios en los archivos de zona al secundario (opcional). 3. Instalar el servicio de nombres el equipo que hará las veces de secundario, y luego configurarlo para que tenga en cuenta su papel de secundario. 4. Actualizar las configuraciones de los clientes para que sus direcciones de servidores de nombres sean las del servidor primario y las del servidor secundario. Una vez se realicen estos pasos, cada vez que se modifiquen los archivos de zona del sitio del servidor primario y se incremente el número de serie, BD enviará una notificación a todos los servidores secundarios (cualquier servidor en el archivo de zona con un registro NS) avisando que se ha hecho un cambio. Entonces el BD de cada uno de estos servidores comparará sus propios archivos de zona para ver si tiene la misma versión o no. Si la versión que el servidor primario ha notificado es más reciente, entonces llevará a cabo una transferencia de zona y obtendrá la nueva versión. Si todo está configurado adecuadamente, nunca necesitará hacer cambios en su servidor secundario. Todos los cambios a partir de aquí se harían en el servidor primario. La excepción es si se añade una nueva zona en el primario, tendrá que añadirla a los servidores secundarios también si quiere que sean servidores secundarios de la nueva zona Autorizar el servidor secundario El primer paso implica la modificación de los archivos de bases de datos de zona en el servidor primario. En ambos hay que incluir dos registros: el primero es de tipo NS para especificar que el servidor secundario está autorizado en el dominio. El segundo es un puntero A para este servidor. En nuestro caso no es necesario hacerlo, ya que al definir las zonas directa e inversa en el servidor primario ya se incluyeron. En el caso de que no se hubiera hecho, habría que incluirlos Notificar cambios al servidor secundario Este paso es opcional y se consigue con dos directivas en la declaración de la zona en el archivo named.conf.local del servidor primario. La primera es allow transfer la cual incluye una lista de direcciones IP de los servidores secundarios a los cuales está permitido enviar transferencias de zona. Esta directiva se puede omitir ya que por defecto el servidor primario envía las transferencias a todos los hosts, pero conviene especificarla para permitir transferencias de zona únicamente para los servidores secundarios. La segunda directiva es also notify la cual indica una lista con las direcciones IP de los servidores a los cuales se les envían notificaciones de cambios en la zona. También se puede omitir, ya que por defecto, el servidor primario envía notificaciones a todos los servidores que tienen un registro tipo NS en el fichero de zona. Las declaraciones de las dos zonas anteriores deben podrían ahora de la siguiente manera: zone serviciosenred.local. { type master; Página 58

69 file /etc/bind/zonas/serviciosenred.local.db ; allow transfer { ; }; also notify { ; }; }; zone in addr.arpa { type master; file /etc/bind/zonas/ db ; allow transfer { ; }; also notify { ; }; }; Cuando el servidor secundario recibe una notificación de cambio en la zona, compara la versión de su zona con la del servidor primario y si son diferentes, inicia una transferencia Instalación y configuración del servidor secundario El tercer paso es instalar BD9 en el servidor secundario. Posteriormente hay que editar el archivo /etc/bind/named.conf.local y declarar las mismas zonas anteriores del servidor primario, pero hay que indicar que el servidor es secundario y especificar cuál es el servidor primario para poder hacer las transferencias. La definición de ambas zonas sería la siguiente zone serviciosenred.local { type slave; file serviciosenred.local.db ; masters { ; }; }; zone in addr.arpa { type slave; file db ; masters { ; }; }; Como se puede observar, ahora el tipo es slave (esclavo o secundario). La directiva masters define una lista con los servidores primarios de los que puede recibir notificaciones de cambios en la zona. Respecto a la directiva file debemos tener en cuenta las siguientes consideraciones. En principio, al ser un servidor secundario no haría falta especificar una directiva file para indicar el nombre del archivo de zona ya que este servidor no es responsable de mantener el archivo de zona. Solamente recibe una copia del archivo de zona del servidor primario. Sin embargo, conviene especificar esta directiva porque cuando el servidor secundario arranca comprueba primero si tiene en la declaración de zona secundaria una directiva file y si es así carga el fichero para posteriormente comprobar si ha habido algún cambio con respecto al archivo de zona en el servidor primario. En el caso de que haya algún cambio inicia una transferencia para actualizar su propio fichero. Si la directiva file se omite, simplemente carga del servidor primario la zona y trabaja con esta copia temporal. Por tanto, es recomendable indicar un fichero copia de la zona ya que si al arrancar el servidor secundario el primario está caído, no podrá cargar la zona. Página 59

70 Sin embargo, al especificar la directiva file hay que tener cuidado con el directorio donde se guardará la copia del archivo de zona. Si es especifica un directorio, tendrá que ser una directorio donde Bind pueda escribir, ya que tiene que crear el fichero. Si la configuración de seguridad del equipo impide a Bind crear ficheros copia de zona, no podrá resolver consultas de esa zona. Lo mejor es indicar únicamente el nombre del fichero de zona en la directiva file sin directorio, lo que provocará que los ficheros copia de zona se crearán en el directorio /var/cache/bind. Figura 57.- Archivos de zona secundaria Configuración de los clientes para usar ambos servidores El cuarto y último paso es modificar la configuración de red de los clientes para que tengan como servidor primario al y como servidor secundario al Hay que tener presente que los clientes pueden estar configurados de forma estática o dinámica. En el primer caso hay que editar el archivo de resolución de nombres, el /etc/resolv.conf y poner lo siguiente search serviciosenred.local nameserver nameserver En éste archivo se indica los servidores de nombres con la directiva nameserver. El orden de consulta corresponde al orden en que aparecen las direcciones IP de los servidores. En primer lugar se pone el primario y en segundo el secundario. También, se puede configurar estáticamente la resolución de nombres de un equipo en el fichero /etc/network/interfaces. En este caso en la sección de configuración de una tarjeta de red habría que añadir las siguientes directivas. dns nameservers dns search serviciosenred.local Si la configuración de los clientes es dinámica, entonces tendremos que modificar el archivo de configuración del servidor DHCP. En este caso hay que editar el archivo /etc/dhcp/dhcpd.conf y en la declaración de ámbito hay poner la siguiente directiva. option domain name servers , ; 3.7 Servidor caché Un servidor caché permite aliviar la enorme carga de trabajo de los servidores autoritativos. Un servidor caché generalmente no gestiona zonas, aunque podría hacerlo. Simplemente recibe consultas de los clientes y las reenvía a otro servidor mediante recursión. Cuando recibe el resultado de una consulta la devuelve al cliente que la hizo, pero también la almacena en su caché para poder responder rápidamente a la misma petición que se puede producir Página 60

71 en el futuro por parte del mismo u otro cliente. La respuesta que recibe viene marcada con un TTL que será el tiempo que el servidor caché mantenga la repuesta en su caché. Por defecto, al instalar BD está configurado para enviar consultas de nombres que no puede resolver a los servidores raíz. Sin embargo, configurarlo como caché producirá un mejor rendimiento en la resolución de nombres. Primero debemos activar la recursión para nuestros cliente en la red local. Para ello tendremos que editar el archivo /etc/bind/named.conf.options y dentro de la sección options añadiremos la siguiente directiva. recursion yes; Además deberemos añadir una sección forwarders con las direcciones IP de los servidores donde redirigir las peticiones. forwarders { ; ; }; La sección forwarders se emplea para especificar las direcciones IP de los servidores de nombres que resolverán las consultas que no están disponibles en la caché o en zonas que gestiona nuestro servidor. Generalmente estos servidores de nombres estarán en Internet y son los del ISP o si nuestra red está conectada a una red privada de ámbito mayor, a los de nuestra organización. Además, debemos establecer la directiva forward con el valor only para que no intente enviar la consulta a otros servidores en el caso de que los servidores establecidos en la sección forwarders no le respondan. Esta directiva también se incluye en la sección options del mismo archivo. forward only; Por último, debemos activar SEC para evitar errores de firma digital en las respuestas de los reenviadores (no valid DS o no valid RRSIG en el archivo log del sistema). La primera directiva hay que añadirla, la segunda modificarla porque ya se encuentra en el fichero pero con el valor auto. dnssec enable yes; dnssec validation yes; El aspecto final de una sección options con todos estos cambios sería la siguiente: options { directory /var/cache/bind ; recursion yes; forward only; forwarders { ; ; }; dnssec enable yes; dnssec validation yes; //Esta directiva se deja tal y como aparece por defecto Página 61

72 auth nxdomain no; # conform to RFC1035 listen on v6 { any; }; }; Reiniciamos el servidor y realizamos una prueba. Haremos una consulta con la utilidad dig a un nombre que no está cacheado y Bind la reenviará al servidor con dirección IP Observamos en la figura siguiente que ha tardado 68 milisegundos en obtener la respuesta. Figura 58.- Consulta a al servidor con caché configurada Si volvemos a realizar la misma consulta veremos que el tiempo de respuesta es sensiblemente inferior. Por tanto la caché está funcionando perfectamente. Página 62

73 Figura 59.- Repetición de la consulta anterior El archivo que almacena la caché es /var/cache/bind/named_dump.db. Con el siguiente comando podemos volcar el contenido de la caché en el fichero anterior. rndc dumpdb cache Ahora podemos visualizarlo con cat o grep Reenviadores condicionales Hay situaciones en las que resultaría mejor tener más control sobre el reenvío de consultas. Por ejemplo, podemos reenviar consultas de nombres que pertenecen a un dominio a un servidor concreto. Lógicamente será al servidor que administre dicho dominio. Por ejemplo, podemos utilizar los servidores de Google para que resuelva nombres que pertenecen al dominio google.com. Para ello habría que incluir la siguiente declaración de zona en el archivo /etc/bind/named.conf.local. // Reenviador condicional a google.com zone "google.com" { type forward; forward only; forwarders { ; ; ; ; }; }; En este caso la declaración forwarders que incluye a los reenviadores se aplican únicamente Página 63

74 al dominio google.com. La directiva forward only se comporta igual que antes con los reenviadores genéricos, es decir, si los reenviadores no resuelven la consultas, el servidor no debe intentar hacerlo por otros medios. 3.8 Registro En Bind resulta especialmente recomendable utilizar logs propios en lugar de los del sistema. Por defecto, Bind registra los errores del servidor en el log del sistema, que es compartido por múltiples servicios y aplicaciones del sistema operativo. Sin embargo, para facilitar la monitorización del funcionamiento del servidor o si necesitamos registrar las consultas de los clientes, resulta adecuado configurar el log de Bind el cual nos permitirá decidir qué y dónde vamos a registrar. Antes de ver como configurar los logs debemos tener claro algunos conceptos. Término Significado Canal Un canal es el destino donde los mensajes pueden ir. Puede ser el log del sistema, un fichero o /dev/null. Todos los mensajes que genera Bind tienen asignada una clase; por ejemplo, mensajes sobre actualizaciones dinámicas o mensajes acerca de respuestas a consultas. El nombre del módulo de origen que genera un mensaje. La gravedad del mensaje de error; a lo que syslog se refiere como prioridad Categoría Módulo Severidad Los logs en Bind se configuran con una declaración logging en el fichero named.conf o en el named.conf.local. Primero se definen canales, que son los posibles destinos de los mensajes. Luego se les dice a varias categorías de mensajes que vayan a un canal particular. Cuando se genera un mensaje, se le asigna una categoría, un módulo y una severidad en su punto de origen. Después es distribuido a todos los canales asociados con esa categoría y módulo. Cada canal tiene un filtro de severidad que define qué nivel de severidad debe tener un mensaje para pasar. Los canales que llevan al syslog también son filtrados de acuerdo a las reglas del /etc/syslog.conf. Esta es la sintaxis de la declaración logging. logging { definición_de_canal; definición_de_canal;... category nombre_categoría { nombre_canal; nombre_canal;... }; }; Como podemos apreciar anteriormente, primero definimos los canales y posteriormente las categorías de mensaje se asignan a los canales definidos Una definición de canal es ligeramente diferente dependiendo de si el canal es un fichero o un canal syslog. Se debe elegir file o syslog para cada canal; un canal no puede ser ambas cosas a la vez. Su sintaxis es: Página 64

75 channel "nombre_del_canal" { ( file ruta [ versions ( número unlimited ) ][ size tamaño ] syslog syslog_facility stderr null ); [ ] [ [ [ }; severity (critical dynamic ); ] print category yes print severity yes print time yes no; error warning notice info debug [ level no; ] no; ] ] Cada definición de canal debe incluir un destino que dice si los mensajes del canal van a un fichero, al log del sistema, a la salida de error estándar o se descarta. Los posibles destinos son: file.- El destino es un fichero de disco. En este caso hay que especificar la ruta del fichero, el número de versiones y el tamaño. Por defecto es 1 sin límite. syslog.- Envía el mensaje al log del sistema. syslog_facility especifica que nombre de lugar al guardar el mensaje. Puede ser cualquiera de los estándar. En la práctica, sólo daemon y de local0 a local7 son elecciones razonables. stderr.- Envía el mensaje a la salida estándar de error. null.- Se descarta el mensaje. El resto de sentencias en una definición de canal son opcionales. severity puede tomar los valores (en orden descendente) critical, error, warning, notice, info o debug. Este último con un nivel numérico opcional. El valor dynamic también es válido y representa el nivel de depuración actual del servidor Por defecto es info. Aquellos mensajes con un nivel de severidad mayor o igual al indicado se aceptarán. Las diversas opciones print añaden o suprimen prefijos del mensaje. El syslog incluye la fecha, hora y el host de origen en cada mensaje guardado, pero no la importancia o la categoría. En Bind, el fichero de origen (módulo) que generó el mensaje también está disponible como opción print. Adquiere sentido entonces activar print time sólo para canales fichero, pues los registros del syslog ponen la fecha y hora ellos solos. La tabla siguiente muestra los cuatro canales predefinidos por defecto. Nombre del canal Lo que hace default_syslog Manda importancia info al syslog con el destino daemon default_debug Guarda en el fichero named.run, severidad puesta a dynamic default_stderr Manda mensajes a la salida de error estándar de named, importancia info null Se descartan todos los mensajes Una vez se han definido los canales se asignan a las categorías de mensaje mediante la sentencia category. Página 65

76 Categoría Qué incluye default Categorías sin una asignación explícita de canal. general Mensajes sin clasificar en ninguna categoría. config Análisis y procesado de ficheros de configuración. queries/client Un mensaje corto de log por cada consulta que el servidor recibe. unmatched Mensajes que el servidor no es capaz de clasificar. dnssec Mensajes de SEC. lame servers Servidores que se supone que sirven una zona, pero no lo están(a). statistics Estadísticas agrupadas del servidor de nombres. panic Errores fatales (duplicados en esta categoría). update Mensajes sobre actualizaciones dinámicas. ncache Mensajes sobre caché negativa. xfer in Transferencias de zonas que el servidor está recibiendo. xfer out Transferencias de zonas que el servidor está enviando. db/database Mensajes sobre operaciones con bases de datos. packet Volcados de paquetes recibidos y enviados(b). notify Mensajes acerca del protocolo de notificaciones "zona modificada". cname Mensajes del tipo "...points to a CNAME". security Peticiones aprobadas/denegadas. os Problemas del sistema operativo. insist Comprobaciones de fallos de consistencia interna. maintenance Sucesos periódicos de mantenimiento. load Mensajes de carga de zonas. response checks Comentarios sobre paquetes de respuesta malformados o inválidos. resolver Traducción de, p.e., búsquedas recursivas para clientes. network Operaciones de red. Por ejemplo, veamos la siguiente definición de log. logging { //Canal para logear las consultas de los clientes channel consultas_cliente { file /var/log/named/consultas_bind.log versions 5 size 20m; Página 66

77 severity info; print time yes; print severity yes; print category yes; }; channel errores { file /var/log/named/errores_bind.log versions 2 size 5m; severity error; print time yes; print severity yes; print category yes; }; category queries { consultas_cliente; }; category default { default_syslog; errores }; }; Hemos definido dos canales: uno para monitorizar las consultas y otro para los errores. Los logs de las consultas se envían al fichero consultas_bind.log. Habrá cinco copias del fichero de hasta 20 Mb. Los mensajes tendrán nivel de severidad mínimo info y se guardarán la fecha/hora, severidad y categoría. El canal errores se vuelcan en errores_bind.log con dos copias de hasta 5 Mb. Solamente se envían mensajes de severidad error o critical. Finalmente los mensajes generados por la categoría consultas se envían al primer canal y los errores se envían al syslog y el canal errores. Sobre el directorio de los ficheros log debemos tener presente la siguiente consideración. En el ejemplo hemos puesto que los ficheros log se almacenan en /var/log/named. Este directorio está configurado en la seguridad del sistema 2 como destino de ficheros log para el servicio Bind. Sin embargo no está creado y por tanto tiene que crearse con máscara de permisos 775, usuario propietario root y grupo bind. De lo contrario el servicio no arrancará. Si se indica un path relativo para los ficheros log, entonces este path será relativo a /var/cache/bind. Si quisieramos otro directorio diferente habría que crearlo con los mismos propietarios y máscara de permisos que /var/log/named y además habría que modificar la configuración de seguridad para que Bind no tuviera problemas para escribir en estos archivos. Si no se ha definido el log se emplea por defecto el siguiente. logging { category default { default_syslog; default_debug; }; category unmatched { null; }; }; 3.9 Delegación de subdominio La delegación consiste en la cesión del control de una zona del espacio de nombres a otro 2 Cuando hablamos de la configuración de seguridad del sistema nos referimos a Apparmor el cual permite asociar un perfil de seguridad a cada aplicación del sistema que permite restringir las capacidades de esa aplicación. Página 67

78 servidor. Cuando un dominio se hace grande puede resultar conveniente dividirlo en subdominios y delegar la administración de estos en otros servidores. En cada uno de estos subdominios se incluyen los hosts que pertenecen a cada uno de ellos y en el dominio principal seguiría existiendo hosts que pertenecerían a él. Cada vez que un host necesitara resolver un nombre que pertenece a un subdominio, enviaría la consultar a su servidor que controla la zona principal y este reenviaría la consulta al servidor que controla el subdominio. Cuando este le devuelva la respuesta, el servidor que controla la zona principal la enviará al host que hizo la consulta. En el siguiente ejemplo vamos a delegar la zona linux.serviciosenred.local en el servidor secundario SeLiSe con el que estamos realizando pruebas. Comenzaremos creando una zona de búsqueda directa en el servidor secundario. Para ello editar el archivo /etc/bind/named.conf.local en el servidor secundario y añadir las siguientes líneas. zone linux.serviciosenred.local { type master; file /etc/bind/zonas/linux.serviciosenred.local.db ; }; Hemos declarado la subzona que va a controlar y sobre la que vamos a delegar el control. Ahora hay que crear el fichero con los datos de la zona al que incluiremos lo siguiente. ;Fichero linux.serviciosenred.local $ORIG linux.serviciosenred.local. $TTL SOA selise usuario ( h 4h 4w 1d NS selise selise A pc01 A ;serial ;refresh ;retry ;expire ;minimum Ahora tenemos que configurar el servidor de la zona principal para que indique la delegación de la subzona. En el archivo /etc/bind/named.conf.local hay que añadir las siguientes líneas. zone "linux.serviciosenred.local" { type forward; forwarders { ;}; }; Como se puede observar, ahora el tipo de zona es forward, indicando que se ha delegado su administración. La lista forwarders especifica la dirección IP del servidor secundario que se encarga de la administración de la subzona. Por último, hay que modificar el fichero de zona principal /etc/bind/zonas/serviciosenred.local.db para añadir dos registros que necesitaremos para que sepa donde buscar los registros de la subzona delegada. Se añadirían las siguientes líneas ; Definiciones de subdominio Página 68

79 $ORIG linux.serviciosenred.local. ; Definimos el servidor de nombres para el NS selise selise A Aunque también simplemente podríamos haber añadido el servidor sobre el que hemos delegado la subzona añadiendo el siguiente registro tipo NS. ; Definimos el servidor de nombres para el subdominio linux.serviciosenred.local. NS selise selise A Podemos hacer una prueba pasando desde un host cliente una consulta con el nombre pc01.linux.serviciosenred.local al servidor principal y obtenemos el siguiente resultado. Figura 60.- Consulta a un host de la subzona 3.10 Utilidades de búsqueda En Linux existen varias herramientas en línea de comando que permiten realizar consultas a los servidores Comando dig La utilidad dig es una herramienta que permite realizar consultas. Devuelve los datos en un formato directamente utilizable por el servidor. Su sintaxis es la siguiente. dig [opciones] [@servidor] [nombre] [tipo] x dirección_ip Especifica que se desea realizar una búsqueda inversa del host con la dirección IP Especifica el nombre o dirección IP del servidor que empleará para la consulta. Por defecto emplea los que aparecen en /etc/resolv.conf nombre Es el nombre del registro de recurso que se está consultando. Debe estar completamente cualificado. tipo Indica el tipo de registro de recurso que se consulta. Además de los tipos estándar en, también se puede indicar ANY para buscar cualquier tipo. Si se omite hace una búsqueda Página 69