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 Rafael Lozano is licensed under a Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 España License.

2 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 v4.2. En la primera se ha utilizado dos servidores Windows Server 2012 y un cliente Windows 8 con la siguiente configuración: Hostname Máquina Virtual SO Hardware VirtualBox Red NAT Conexiones de Red Red Interna red_windows Servidores de Nombres Puerta de Enlace Software adicional SeWiPr WS 2012 HD 30GB RAM 1,5GB Dinámica en / /24 El mismo que la máquina física Ninguno SeWiSe WS 2012 HD 30GB RAM 1,5GB CW W8 HD 15GB RAM 1 GB /24 reservada DHCP Dinámica en / Ninguno 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 Conexiones de Red Hostname Máquina Virtual SO Hardware VirtualBox Host Only Adapter Red Interna red_linux Servidores de Nombres Puerta de Enlace Software adicional SeLiPr Lubuntu HD 5GB RAM 512MB Dinámica en / /24 El mismo que la máquina física Ninguno SeLiSe Lubuntu HD 5GB RAM 256 MB /24 reservada DHCP Ninguno CL Lubuntu HD 5GB RAM 256 MB 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 2014 I

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

4 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 Dirección IP 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 En la plataforma Linux se hará algo similar. El árbol de dominio será el siguiente III

5 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

6 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. 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 La caché del cliente Bind Instalación del servidor Archivos de configuración Comprobación de la sintaxis en los archivos de configuración...44 Índice I

7 3.3 Configuración de un servidor primario Archivo de zona de búsqueda directa Archivo de zona búsqueda inversa 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é Registro Delegación de subdominio Utilidades de búsqueda Comando dig Comando host Comando nslookup Bibliografía...61 Índice II

8 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

9 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

10 nodo hacia arriba hasta la raíz. La última etiqueta es la etiqueta de la raíz. 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 Figura 2.- Etiquetas, dominios, FQDN y PQDN 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). 1.2 en Internet Figura 3.- Dominios y subdominios 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

11 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 aero biz com coop edu gov int info museum Significado Líneas aéreas Firmas de negocios (similar a "com") Organizaciones comerciales Cooperativas Instituciones educativas Instituciones gubernamentales Organizaciones internacionales Proveedores de servicios de información Museos Página 4

12 mil name net org pro Grupos militares Nombres personales (individuales) Centros de soporte de red Organizaciones sin ánimo de lucro 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

13 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

14 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 Resolución iterativa Figura 5.- Resolución recursiva 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

15 1.4.4 La caché Figura 6.- Resolución iterativa 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

16 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. 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

17 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. HINFO - Host INFOrmation (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. ARIN 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

18 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. WS2012 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

19 9. En el último paso de confirmación hacer clic en el botón Instalar. 10. Pasado un espacio de tiempo corto 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 Figura 7.- Asistente para agregar roles y características Pasamos como parámetro el nombre del cual queremos averiguar su dirección IP. Como podemos observar en el resultado de la consulta, nos indica las direcciones IP del servidor de Google Página 12

20 en españa y el servidor que realizó la consulta. Figura 8.- Consulta 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 9.- 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... Página 13

21 4. 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. 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. 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 10.- 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. Página 14

22 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. 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 inaddr.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. Figura 11.- 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 recien 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 Página 15

23 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) 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 12.- 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 16

24 Figura 13.- 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 14.- 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 17

25 Figura 15.- Registros 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. 2.5 El registro SOA Figura 16.- Registro de recurso PTR 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. 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 hace clic en el botón Incrementar se aumenta este número manualmente, lo que provocará una transferencia de zona. Servidor primario.- Nombre FQDN del servidor que está designado como servidor Página 18

26 maestro principal de esta zona. Figura 17.- Registro SOA Persona responsable.- Dirección de correo electrónico de la persona responsable de administrar el archivo de zona del dominio. Debemos tener en cuenta que un "." se utiliza en lugar de un en la dirección de correo electrónico. 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 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. Página 19

27 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 recien creada solamente aparece el servidor primario. 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. 3. El administrador de comprobará la conectividad con el servidor y si está ejecutándo 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. Página 20

28 Figura 18.- 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á 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. Página 21

29 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 pestala 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. b) Los siguientes servidores.- Solamente se envían las notificaciones a los servidores cuya dirección IP aparece en la lista inferior. Página 22

30 Figura 19.- 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. 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. 7. En la pantalla resumen hacemos clic en el botón Finalizar. Página 23

31 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. Figura 20.- 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 Página 24

32 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 nombre 1. ping sewise.serviciosenred.local El resultado será el siguiente: 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 Figura 21.- Resultado de la utilidad ping al servidor secundario desde el cliente Ningún servidor de nombres puede responder a las consultas de todos los clientes; a veces, los 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 25

33 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 cacherá 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. Figura 22.- Reenviador condicional 2. Desplegar el árbol y sobre la carpeta Reenviadores condicionales hacer clic con el botón Página 26

34 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. 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. 5. Introducir la dirección IP del reenviador. Figura 23.- Reenviadores Página 27

35 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 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 24.- Actualizaciones dinámicas Página 28

36 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: 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. 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. Figura 25.- Actualizaciones dinámicas en DHCP Página 29

37 2.9.1 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 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 26.- 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 Página 30

38 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 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 27.- 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. Página 31

39 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. Figura 28.- 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 pertezcan a este subdominio. Resumiendo, para crear un subdominio en un servidor distinto al que mantiene la zona del dominio principal debemos hacer lo siguiente: Página 32

40 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. 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. Posteriormente introducimos un registro tipo A para el nombre pc01.windows.serviciosenred.local. La zona quedaría asi: 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. Figura 29.- Subdominio windows.serviciosenred.local 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 Hacer clic en el botón Siguiente en la pantalla de bienvenida del asistente para crear una nueva delegación. Página 33

41 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. Figura 30.- Creación de una nueva delegación de subdominio 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 31.- 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, Página 34

42 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 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. 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 Página 35

43 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 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] opción A continuación se explican los parámetros del comando 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 Descripción A Especifica la dirección IP un equipo. ANY Especifica todos los tipos de datos. CNAME Especifica un nombre canónico para un alias. GID Especifica el identificador de grupo de un nombre de grupo. HINFO Especifica el tipo de CPU y sistema operativo de un equipo. MB Especifica un nombre de dominio de buzón MG Especifica un miembro de un grupo de correo. MINFO Especifica información del buzón o de la lista de correo. MR Especifica el nombre de dominio de correo cambiado. MX Especifica el intercambiador de correo. Página 36

44 NS PTR SOA TXT UID UINFO WKS 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. 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 37

45 Figura 32.- 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 33.- 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 34.- 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 38

46 Figura 35.- 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 36.- 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 39

47 Figura 37.- 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 38.- Prompt del modo interactivo Ahora solo hay que escribir el nombre buscado y pulsar la tecla Intro. Figura 39.- Consulta en modo interactivo Si queremos configurar alguna opción deberemos de anteponer set al nombre de la opción. En el ejemplo siguiente aumentamos el timeout a un minuto. Posteriormente consultamos la dirección IP del nombre Página 40

48 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 2.14 Uso de ipconfig para 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. 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 Figura 40.- Resultado de nslookup con timeout de 1 minuto 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 Página 41

49 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 La caché del cliente El resolver de Windows almacena cada registro que recibe en una caché compartida por todas las aplicaciones del sistema. Para mantener los registros en cache toma el TTL del registro hasta un máximo de 24 horas por defecto. Si el TTL es mayor, entonces solamente almacena el registro 24 horas. Este valor por defecto se puede configurar a través del registro. Clave: MaxCacheTTL Localización: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cache\Parameters Tipo de dato: Reg_DWord Valor por defecto: segundos (24 horas) El resolver de Windows también soporta caché negativa. Windows cachea las respuestas negativas durante 15 minutos por defecto, aunque también se puede configurar por el registro. Clave: MaxNegativeCacheTTL Localización: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cache\Parameters Tipo de dato: Reg_DWord Valor por defecto: 900 segundos (15 minutos) Estas claves de registro no se encuentran en la versión 7 o superior, por lo que habrá que añadirlas si queremos modificar los valores por defecto. 3. Bind 9 BIND (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 BIND (BIND 9) fue escrita desde cero en parte para superar las dificultades arquitectónicas presentes anteriormente para auditar el código en las primeras versiones de BIND, y también para incorporar SEC ( Security Extensions). BIND 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. Página 42

50 BIND 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 realizar sus pruebas que verifiquen la correcta configuración del servidor. BIND 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 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. 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 Página 43

51 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, BIND dispone de dos utilidades que comprueban la sintaxis del archivo named.conf y de los archivos de zona, informando en el 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. Página 44

52 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 ; }; 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 BIND. 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. Página 45

53 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 IN para direcciones IP o HS para objetos de la clase Hesiod. Para las redes TCP/IP, tenemos que especificar IN. 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 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. $ORIGIN 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 IN SOA selipr usuario ( ;serial 8h ;refresh 4h ;retry 4w ;expire 1d ) ;minimum ;Registros NS con los servidores de IN NS IN NS selise ;Intercambio de correo IN MX 10 selipr ;Definimos alias para servicios con CNAME ftp IN CNAME selipr www IN CNAME selipr smtp IN CNAME selipr pop3 IN CNAME selipr imap IN CNAME selipr ;Registros A Página 46

54 selipr IN A selise IN A sewipr IN 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. $ORIGIN serviciosenred.local. La directiva $ORIGIN 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 IN A tendríamos que haber puesto selipr.serviciosenred.local IN 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 IN SOA selipr usuario ( ;serial 8h ;refresh 4h ;retry 4w ;expire 1d ) ;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, IN indica la clase del registro, que en este caso es Internet. SOA establece que es el inicio de un archivo de zona. Página 47

55 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 Serial.- BIND 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 BIND 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 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 hará IN NS IN NS selise Los siguientes registros de recursos definen los servidores de nombres autorizados en la IN 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 IN CNAME selipr www IN CNAME selipr smtp IN CNAME selipr pop3 IN CNAME selipr imap IN CNAME 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 IN A selise IN A sewipr IN A Página 48

56 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. $ORIGIN in addr.arpa. $TTL IN SOA selipr.serviciosenred.local. usuario.serviciosenred.local. ( ; serial ; refresh (8 horas) ; retry (4 horas) ; expire (4 semanas) ; minimum (1 día) ) ; servidor de nombres IN NS IN NS selise.serviciosenred.local. ; equipos de la red 1 IN PTR selipr.serviciosenred.local. 10 IN PTR selise.serviciosenred.local. Las directivas $ORIGIN y $TTL tienen la misma función anterior. En este caso el valor de $ORIGIN 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 IN 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 $ORIGIN 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 de IN NS IN NS selise.serviciosenred.local. Igual que antes, hay que definir el servidor de nombres autorizado para la zona y debe estar completamente cualificado. 1 IN PTR selipr.serviciosenred.local. Página 49

57 10 IN PTR 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 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: 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, BIND 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 BIND 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 Página 50

58 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; 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 BIND9 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. Página 51

59 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. 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 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.5 Servidor caché Por defecto, al instalar BIND está preconfigurado como servidor caché. Tan solo será necesario editar el archivo /etc/bind/named.conf.options y en la sección forwarders añadir las direcciones IP de dos servidores donde redirigir las peticiones. Página 52

60 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é. Generalmente estos servidores de nombres estarán en Internet y son los del ISP. 3.6 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 el 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. Término Canal Antes de ver como configurar los logs debemos tener claro algunos conceptos. Categoría Módulo Severidad Significado 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 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 definidmos los canales y posteriormente las categorías de mensaje se asignan a los canales definidos Página 53

61 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: channel "nombre_del_canal" { ( file ruta [ versions ( número unlimited ) ][ size tamaño ] syslog syslog_facility stderr null ); [ severity (critical error warning notice info debug [ level ] dynamic ); ] [ print category yes no; ] [ print severity yes no; ] [ print time yes 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 default_syslog default_debug default_stderr Lo que hace Manda importancia info al syslog con el destino daemon Guarda en el fichero named.run, severidad puesta a dynamic Manda mensajes a la salida de error estándar de named, importancia info Página 54

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

63 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.7 Delegación de subdominio La delegación consiste en la cesión del control de una zona del espacio de nombres a otro 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. 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 56

64 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 $ORIGIN linux.serviciosenred.local. $TTL IN SOA selise usuario ( ;serial 8h ;refresh 4h ;retry 4w ;expire 1d ;minimum IN NS selise selise IN A pc01 IN A 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 $ORIGIN linux.serviciosenred.local. ; Definimos el servidor de nombres para el IN NS selise selise IN 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. IN NS selise selise IN A Página 57

65 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. 3.8 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 nombre tipo Especifica el nombre o dirección IP del servidor que empleará para la consulta. Por defecto emplea los que aparecen en /etc/resolv.conf Es el nombre del registro de recurso que se está consultando. Debe estar completamente cualificado. 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 para los registros de tipo A. Lo más habitual es para comprobar si el servidor actualmente configurado en el host puede resolver un nombre. Por ejemplo, para buscar el servidor primario podríamos utilizar el siguiente comando desde el cliente. dig selipr.serviciosenred.local El resultado sería el siguiente: ; <<>> DiG P1 <<>> selipr.serviciosenred.local ;; global options: +cmd ;; Got answer: ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: Figura 41.- Consulta a un host de la subzona Página 58