Consejos para configurar el servidor DNS en Empresas con RHEL

Ya sea interno o con cara al Internet, la configuración del servidor DNS puede ser sólo una brisa con estos consejos básicos.

Los nombres se utilizan normalmente para la comunicación precisa entre los servidores. Estos nombres se resuelven en direcciones IP. En un entorno de red pequeño, es posible hacer esto en función de cada huésped, pero en redes más grandes, usted necesitará DNS para hacerse cargo de esta tarea. He aquí un resumen de lo que hay que hacer para la configuración del servidor DNS en Red Hat Linux Enterprise de (RHEL).

Comprendiendo los requisitos

Un sistema de nombres de dominio (DNS) puede usarse tanto para servidores internos o como un servicio que es ofrecido por el Proveedor de Internet. No hay nada equivocado con los hospedados en Internet DNS, especialmente si la cantidad de servidores que tiene que ser manejado por el DNS es pequeña. Si usted tiene que poner una mayor cantidad de servidores DNS, o si necesita un DNS dinámico que permite a los equipos cliente para registrar la dirección IP que ha obtenido desde el servidor DHCP con DNS, necesitará su propia configuración del servidor DNS.

 

Preparación para la configuración del DNS

Antes de iniciar la instalación real, hay algunas cosas a tener en cuenta. En primer lugar, puede que tenga que registrar un nombre de dominio DNS. Si desea que sus nombres de host a ser resuelto por los clientes en cualquier parte del mundo, necesita un nombre registrado. Si es para uso interno, también puede utilizar un nombre privado que no ha sido registrado. En ese caso, sigue siendo una buena idea utilizar un nombre que no sea utilizado por alguien más, pero usar uno que sea claramente reconocible como un nombre local de sólo DNS, como example.local.

Incluso si el nombre de dominio que desea utilizar está disponible sólo a nivel interno, puede conectar el servidor DNS a la jerarquía DNS en todo el mundo. Eso significa que su servidor DNS interno puede salir y resolver nombres de Internet. De forma predeterminada, un servidor DNS que no es capaz de resolver un nombre por sí mismo contactará con un servidor de nombres del dominio (DNS) raíz o utilizara un promotor para obtener externamente la información de resolución del nombre. A continuación, el servidor DNS pondrá en caché la información que ha encontrado para rápidamente entregar la información requerida hacia una etapa posterior.

A raíz de la decisión sobre el nombre de dominio, es necesario pensar en el tipo de servicios de DNS que desea ofrecer. En el enfoque más simple, se puede instalar un servidor de nombre DNS sólo de caché. Este es un servidor DNS que no tiene una base de datos con registros de recursos por sí mismo, pero obtendrá todo, desde los servidores de nombres externos. La ventaja de implementar un servidor de nombres de sólo memoria caché es la velocidad, todo lo que se almacena en caché local no necesita ser traído desde Internet.

Como alternativa, puede ejecutar un servidor maestro y, opcionalmente, uno o más servidores esclavos de nombres DNS. Cada dominio necesita al menos un servidor de nombres maestro, que coordina los cambios de registros de recursos. Para fines de redundancia y disponibilidad, un maestro puede ser soportado por uno o más esclavos de modo que en caso de que caiga el maestro, los esclavos están todavía disponibles para servir a los registros de recursos a partir de la base de datos de DNS.

A continuación, debe decidir si desea usar el DNS dinámico también. En DNS dinámico, el servidor DHCP sincroniza su información con DNS. De esta manera, usted puede asegurarse que una serie que se ha hecho de una nueva dirección IP tendrá su información actualizada en DNS también.

La última decisión a tomar es la seguridad. Si un servidor maestro de nombres DNS actualiza la base de datos en un servidor de nombres esclavo, es bueno estar seguro de que es el maestro el que está impulsando los cambios. Para garantizar la autenticidad del otro host en las actualizaciones de DNS, pueden usarse las claves de firma de transacción. Como administrador, debe asegurarse de que estas teclas se configuran y están disponibles en todos los hosts que participan en la comunicación DNS.

Configuración de un servidor de nombres de sólo caché

Una vez que haya decidido como quiere configurar su entorno de DNS, puede iniciar la instalación. En Red Hat, esto se hace mediante la instalación del paquete bind. A partir de este paquete obtendrá el servidor con el nombre y su archivo de configuración named.conf. La construcción de un servidor de nombres de sólo caché sobre la base de esta configuración es fácil y consiste en sólo dos tareas:

  • Decirle al proceso nombrado que escuche en todas las interfaces de red, y
  • Configurar un reenviador.

Para agregar estas opciones, abra el archivo named.conf con su editor de texto favorito y en primer lugar encuentre la línea que dice listen-on-port 53. La línea se mostrará entre paréntesis para definir qué direcciones IP va a escuchar el servidor DNS y se asegura de que puede leer el puerto correcto. Después de eso, busque la línea que dice forwarders y utilice la dirección IP del servidor DNS de su proveedor de Internet - o cualquier otro servidor DNS que desee - para reenviar las solicitudes DNS. La lista siguiente muestra lo que el contenido de la named.conf debe ser similar. Guarde los cambios y utilice el comando de servicio nombrado restart para reiniciar el servidor DNS. En este punto usted tiene un servidor DNS de sólo caché. En un seguimiento a este artículo, usted aprenderá cómo configurar el servidor DNS como un servidor maestro de nombres para su dominio.

Ejemplo: Contenido del archivo /etc/named.conf

//

// named.conf

//

//Suministrado por Red Hat, el paquete bind para configurar el ISC BIND nombrado (8)

// servidor DNS como un servidor de nombres de sólo caché (solo como solucionador de un DNS local).

//

//Ver /usr/share/doc/bind*/sample/como ejemplo de archivo de configuración nombrado.

//

options {

listen-on port 53 { any; };

listen-on-v6 port 53 { any; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt";

allow-query { any; };

forwarders { 8.8.8.8; };

recursion yes;

dnssec-enable yes;

dnssec-validation no;

dnssec-lookaside auto;

/*Ruta a la clave ISC DLV*/

bindkeys-file "/etc/named.iscdlv.key";

};

logging {

channel default_debug {

file "data/named.run";

severity dynamic;

};

};

zone "." IN {

type hint;

file "named.ca";

};

include "/etc/named.rfc1912.zones";

SOBRE EL AUTOR: Sander van Vugt es un entrenador independiente y consultor que radica en los Países Bajos. Él es un experto en Linux de alta disponibilidad, virtualización y rendimiento y ha completado varios proyectos que implementan los tres. Él es también el autor de varios libros sobre Linux, como por ejemplo Beginning the Linux Command Line,Beginning Ubuntu Server Administrationy Pro Ubuntu Server Administration.

Investigue más sobre Redes y comunicaciones