Servidor DNS en Fedora9 (1)

PRIMERA PARTE

Servidor DNS en Fedora [BIND 9.5 EN FEDORA 9]

Ing. Agustín Ríos Reyes

18/02/2009

Este documenta trata la configuración básica de un servidor DNS en Linux fedora 9, con el paquete BIND 9.5.esta configuración representa un ejemplo en una LAN, y solo trata la configuración del servidor DNS, posterior mente se tratara la configuración de otros servicios como correo electrónico y un servidor web, pero esto será en la segunda entrega.

9

Servidor DNS en Fedora……. 2009

2


BIND 9.5

[email protected]

9

Índice

Índice…………………………………………………………………………………………………………...2 Introducción……………………………………………………………………………………………………3

1.Conceptos previos……………………………………………………………………………………………4

1.1.¿Qué significa DNS? ………………………………………………………………………………………4

1.2.¿Porque usar un servidor DNS? ……………………………………………………………………...……4

1.3.¿Cómo funciona el DNS? …………………………………………………………………………….……4

1.3.1.El Espacio de Nombres de Dominio………………………………………………………………..……4

1.3.2.El Espacio de Nombres de Dominio en Internet…………………………………………………………5

1.3.3.Delegación…………………………………………………………………………………………..……6

2. Componentes de un DNS……………………………………………………………………………………6

2.1. Clientes DNS………………………………………………………………………………………………6

2.2. Servidores DNS……………………………………………………………………………………………6

2.3. Zonas de Autoridad…………………………………………………………………………………..……7

2.3.1. Zonas de Reenvío…………………………………………………………………………………..……8

2.3.2. Zonas de Resolución Inversa……………………………………………………………………………8

3. Instalación de los paquetes……………………………………………………………………………..……8

3.1. Paquetes necesarios para la configuración…………………………………………………………...……8

3.2. Comprobando que los paquetes estén instalados. …………………………………………………...……9

3.3. Instalar los paquetes necesarios. …………………………………………………………………….……9

4. Configuración del servidor……………………………………………………………………………..……9

4.1. Archivos de configuración. ……………………………………………………………………….……..10

4.1.1. El archivo named.conf …………………………………………………………………………...……10

4.1.2. El archivo named.rfc1912.zones ………………………………………………………………………10

4.1.3. Archivos de zonas. ……………………………………………………………………………….……10

4.1.3.1. Archivo de zona de reenvió (nitsugario.com.zone) ………………………………………………….11

4.1.3.2. Archivo de zona de resolución inversa (192.168.1 )…………………………………………………11

4.2. Configuración de los archivos y creación del los archivos de zonas…………………………………….11

4.2.1. Creación de archivos de zonas. ………………………………………………………………………..11

4.2.1.1. Zona de reenvió nitsugario.com……………………………………………………………………...11

4.2.1.1.1. Descripción del archivo nitsugario.com.zone……………………………………………………..12

4.2.1.2. Zona de resolución inversa 1.168.192.in-addr.arpa…………………………………………………14

4.2.1.2.1. Descripción del archivo 192.168.1…………………………………………………………...……15

4.2.2. Configuración del archivo named.rfc1912.zones………………………………………………...……15

4.2.2.1. Descripción del archivo named.rfc1912.zones………………………………………………………16

4.2.3. Configuración del archivo named.conf…………………………………………………………...……17

4.2.3.1 Descripción del contenido del archivo named.conf……………………………………………….…17

5. Comprobando que funcione la configuración………………………………………………………...……18

5.1. Iniciando el servidor…………………………………………………………………………………...…18

5.2. Parando el servidor ………………………………………………………………………………………19

5.3. Reiniciando el servidor: …………………………………………………………………………………19

5.4. Añadir el servidor al arranque del sistema…………………………………………………………….…19

5.5. Depuración de la configuración………………………………………………………………………….19

5.6. Pruebas con ping………………………………………………………………………………………20

Bibliografía………………………………………………………………………………………………21


3


BIND 9.5

[email protected]

9

Introducción

En la actualidad ay millones de computadoras conectadas a internet, las cuales brindan servicios web y otras que son de usa privado de empresas. Todas estas computadoras están identificadas con una dirección IP, pero

como hacer para identificar y mantener la pista de todas estas computadoras cuando pertenecen a tantos

países, redes y grupos administrativos distinto? Para esta tarea titánica ay dos elementos que mantienen todo esto junto y en orden:

El sistema de nombres de dominio “DNS” (Domain Name System), cuya función es saber quién es cada host

con respecto a una dirección IP y un Nombre único en la red.

El otro elemento es el sistema de enrutamiento de internet, que se encarga de conocer cómo están conectadas

entre sí todas estas computadoras y equipos.

Este documento solo abarcaremos la parte concerniente al Sistema de nombres de dominio. Estudiaremos sus

definiciones, elementos características, y el modo de configurar uno en nuestra casa.

Utilizaremos el sistema operativo Linux Fedora 9 y el paquete por excelencia para hacer esta tarea BIND en

su versión 9.5.

BIND (acrónimo de Berkeley Internet Name Domain) es una implementación del protocolo DNS y provee

una implementación libre de los principales componentes del Sistema de Nombres de Dominio, los cuales

incluyen:

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

· Una biblioteca resolutoria de sistema de nombres de dominio. · Herramientas para verificar la operación adecuada del servidor DNS (bind-utils).

El Servidor DNS BIND es ampliamente utilizado en la Internet (99% de los servidores DNS)

proporcionando una robusta y estable solución.

Alguna duda o comentario sobre este documento enviar un mensaje a mi correo: [email protected]

“Recuerda que si te equivocas o cometes un erro en algo, recuerda has aprendido una forma de cómo no hacerlo (Agustín Ríos)”.

Este documento y su contenido pueden ser copiados o distribuido

siempre que se mantenga el nombre del autor.


4


BIND 9.5

[email protected]

9

1. Conceptos previos

1.1. ¿Qué significa DNS?

DNS acrónimo de Domain Name System que interpretado en español es Sistema de Nombres de Dominio.

1.2. ¿Porque usar un servidor DNS? Al comienzo de TCP/IP, puesto que las redes no eran muy extensas, o en otras palabras que el número de

equipos conectados a la misma red era bajo, los administradores de red crearon archivos llamados tablas de

conversión manual. Estas tablas de conversión manual eran archivos secuenciales, por lo general llamados hosts o hosts.txt, y asociaban en cada línea la dirección IP del equipo con el nombre literal relacionado,

denominado nombre del ordenador.

Sin embargo, el anterior sistema de tablas de conversión exigía una actualización manual de las tablas para la totalidad de los equipos en caso de incluir o modificar el nombre de una máquina. Por lo tanto, con el

aumento en tamaño de las redes y sus interconexiones, fue necesario implementar un sistema de gestión para

los nombres que fuese jerárquico y fácil de administrar. El sistema llamado Sistema de Nombres de Dominio (DNS) fue desarrollado en noviembre de 1983 por Paul Mockapetris (RFC 882 y RFC 883) y luego revisado

en 1987 en las RFC 1034 y 1035. El DNS ha sido sometido a varias RFC.

Este sistema ofrece:

un espacio de nombre jerárquico que permite garantizar la singularidad de un nombre en una estructura arbórea, como por ejemplo sistemas de archivo Unix.

un sistema de servidores de distribución que permite que el espacio de nombre esté disponible.

un sistema de cliente que permite "resolver" nombres de dominio, es decir, interrogar a los

servidores para encontrar la dirección IP que corresponde a un nombre.

1.3. ¿Cómo funciona el DNS? El Sistema de Nombres de Dominio permite a los usuarios de una red TCP/IP utilizar nombres jerárquicos y

descriptivos para localizar fácilmente ordenadores (hosts) y otros recursos en dicha red, evitando de esta

manera tener que recordar la dirección IP de cada ordenador al que se desea acceder. En esencia, DNS es una base de datos distribuida que contiene asociaciones de nombres simbólicos (de hosts) a direcciones IP. El

hecho de que sea distribuida permite delegar el control sobre diferentes segmentos de la base de datos a

distintas organizaciones, pero siempre de forma que los datos de cada segmento están disponibles en toda la

red, a través de un esquema cliente-servidor.

Los programas denominados servidores de nombres (name servers) constituyen la parte servidora del

esquema cliente-servidor. Los servidores de nombres contienen información sobre algunos segmentos de la base de datos y los ponen a disposición de los clientes, llamados solucionadores o resolvers.

1.3.1. El Espacio de Nombres de Dominio

La base de datos distribuida de DNS está indexada por nombres de dominio. Cada nombre de dominio es

esencialmente una trayectoria en un árbol invertido denominado espacio de nombres de dominio. La estructura jerárquica del árbol es similar a la estructura del sistema de ficheros UNIX. El árbol tiene una

única raíz en l nivel superior llamada raíz (root). Cada nodo del árbol puede ramificarse en cualquier número

de nodos de nivel inferior. La profundidad del árbol está limitada a 127 niveles.


5


BIND 9.5

[email protected]

9

Cada nodo en el árbol se identifica mediante una etiqueta no nula que puede contener hasta 63 caracteres,

excepto el nodo raíz, identificado mediante una etiqueta nula. El nombre de dominio completo de cualquier nodo está formado por la secuencia de etiquetas que forman la trayectoria desde dicho nodo hasta la raíz,

separando cada etiqueta de la siguiente mediante un punto. De esta forma, el nombre del nodo especifica de

forma unívoca su localización en la jerarquía. A este nombre de dominio completo o absoluto se le conoce como nombre de dominio completamente cualificado o Fully Qualified Domain Name (FQDN). Al ser nula

la etiqueta que identifica el nodo raíz, el FQDN de cualquier nodo del árbol siempre acaba con un punto. La

única restricción que se impone en el árbol de nombres es que los nodos hijos del mismo padre tengan etiquetas diferentes.

Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión es «maquina1» y un

dominio «dominio.com», el FQDN sería «maquina1.dominio.com.», de modo define de modo único al dispositivo mientras que pudieran existir muchos anfitriones llamados «maquina1», solo puede haber uno

llamado «maquina1.dominio.com.». La ausencia del punto al final definiría que se pudiera tratar tan solo de

un prefijo, es decir «maquina1.dominio.com» pudiera ser de un dominio más largo como maquina1.dominio.com.mx».

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

«-». No se distinguen mayúsculas y minúsculas.

En el esquema jerárquico de nombres DNS, se denomina dominio a cualquier subárbol del espacio de nombres de dominio. De esta forma, cada dominio puede contener, a su vez, otros dominios. Generalmente,

los hosts están representados por las hojas del árbol, aunque es posible nombrar a un host con una etiqueta

correspondiente a un nodo intermedio del árbol (en este caso, tendríamos un dominio y un nodo que se llaman igual).

La información sobre los nombres de dominio DNS se guarda mediante los denominados registros de

recursos en los servidores DNS de la red. Concretamente, cada servidor DNS contiene los registros de recursos necesarios para responder a las consultas sobre la parte del espacio de nombres en la que tiene

autoridad.

1.3.2. El Espacio de Nombres de Dominio en Internet

El estándar DNS no impone muchas reglas sobre las etiquetas de los nombres de dominio, ni tampoco asocia un significado determinado a las etiquetas de un determinado nivel del espacio de nombres.

Cuando manejamos una parte de este espacio, podemos decidir el significado y la sintaxis de nuestros

nombres de dominio. Sin embargo, en el espacio de nombres Internet existente, se ha impuesto una estructura de nombres bien definida, especialmente en los dominios de primer nivel.

Los dominios originales de primer nivel dividían originalmente el espacio de nombres de Internet en siete dominios: com, edu, gov, mil, net, org, e int. Posteriormente, para acomodar el crecimiento y la

internacionalización de Internet, se reservaron nuevos dominios de primer nivel que hacían referencia a

países individuales.

Actualmente, los dominios originales se denominan dominios de primer nivel genéricos y han surgido

nuevos nombres que se ajustan a los tiempos que corren.


6


BIND 9.5

[email protected]

9

1.3.3. Delegación

Es importante resaltar que el objetivo principal del diseño del sistema de nombres de dominio fue su

administración descentralizada. Este objetivo se consigue a través de la delegación. La delegación de dominios funciona de forma parecida a la delegación de tareas en una organización. Un responsable de

proyecto divide el proyecto en pequeñas tareas y asigna (delega) la responsabilidad de las mismas a

diferentes empleados.

De la misma forma, una organización que administra un dominio puede dividirla en subdominios. Cada

subdominio puede ser delegado a diferentes organizaciones, lo cual implica que esa organización será

responsable de mantener los datos (registros de recursos) de ese subdominio. Esa organización puede libremente cambiar los datos e incluso volver a dividir el dominio delegado en subdominios y delegarlos. El

dominio padre solamente contiene enlaces a los responsables del subdominio delegado, de forma que pueda

hacer referencia a ellos cuando se le planteen consultas sobre nombres en dicho subdominio delegado.

Realmente, la subdivisión de un dominio en subdominios y la delegación de dichos subdominios son cosas

distintas. En primer lugar, un dominio que tenga capacidad de autogestión (autoridad), siempre puede decidir

subdividirse en diferentes subdominios, manteniendo él en principio la autoridad sobre todos ellos. Posteriormente, la organización que gestiona el dominio puede decidir además delegar la autoridad de

algunos (o todos) sus subdominios en otras organizaciones. La delegación es una acción que siempre decide

el dominio padre, y éste puede revocarla cuando desee, volviendo a retomar la autoridad sobre el subdominio que había delegado.

2. Componentes de un DNS

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

2.1. Clientes DNS Son programas que ejecuta un usuario y que generan peticiones de consulta para resolver nombres.

Básicamente preguntan por la dirección IP que corresponde a un nombre determinado.

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

nombres:

Servidor Maestro(o primario)

Obtiene los datos del dominio a partir de un fichero hospedado en el mismo servidor.

Servidor Esclavo(o secundario)

Al iniciar obtiene los datos del dominio a través de un servidor un Servidor Maestro, realizando un proceso

denominado transferencia de zona.

Un gran número de problemas de operación de servidores DNS se atribuyen a las pobres opciones de

servidores secundarios para las zonas de DNS. De acuerdo al RFC 2182, el DNS requiere que al menos tres

servidores existan para todos los dominios delegados (o zonas).

Una de las principales razones para tener al menos tres servidores para cada zona es permitir que la

información de la zona misma esté disponible siempre y forma confiable hacia los Clientes DNS a través de Internet cuando un servidor DNS de dicha zona falle, no esté disponible y/o esté inalcanzable.

Contar con múltiples servidores también facilita la propagación de la zona y mejoran la eficiencia del sistema en general la brindar opciones a los Clientes DNS si acaso encontraran dificultades para realizar una

consulta en un Servidor DNS. En otras palabras: tener múltiples servidores para una zona permite contar con

redundancia y respaldo del servicio.


7


BIND 9.5

[email protected]

9

Con múltiples servidores, por lo general uno actúa como Servidor Maestro o Primario y los demás como

Servidores Esclavos o Secundarios. Correctamente configurados y una vez creados los datos para una zona, no será necesario copiarlos a cada Servidor Esclavo o Secundario, pues éste se encargará de transferir los

datos de manera automática cuando sea necesario.

Los Servidores DNS responden dos tipos de consultas:

Consultas Iterativas (no recursivas) El cliente hace una consulta al Servidor DNS y este le responde con la mejor respuesta que pueda darse basada sobre su caché o en las zonas locales. Si no es posible dar una respuesta, la consulta se reenvía hacia

otro Servidor DNS repitiéndose este proceso hasta encontrar al Servidor DNS que tiene la Zona de Autoridad

capaz de resolver la consulta.

Consultas Recursivas

El Servidor DNS asume toda la carga de proporcionar la una respuesta completa para la consulta realizada

por el Cliente DNS. El Servidor DNS desarrolla entonces Consultas Iterativas separadas hacia otros Servidores DNS (en lugar de hacerlo el Cliente DNS) para lograr la respuesta.

2.3. Zonas de Autoridad

Permiten al Servidor Maestro o Primario cargar la información de una zona. Cada Zona de Autoridad abarca

al menos un dominio y posiblemente sus sub-dominios, si estos últimos no son delegados a otras zonas de autoridad.

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

TIPO DE REGISTRO DESCRIPCIÓN

A (Address)

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

AAAA Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección

IPv6 de 128 bits.

CNAME (Canonical Name)

Registro de nombre canónico que hace que un nombre sea alias de otro. Los dominios con alias obtienen los sub-dominios y registros DNS del dominio

original.

MX (Mail Exchange) Registro de servidor de correo que sirve para definir una lista de servidores de

correo para un dominio, así como la prioridad entre éstos.

PTR (Pointer) Registro de apuntador que resuelve direcciones IPv4 hacia el nombre anfitriones.

Es decir, hace lo contrario al registro A. Se utiliza en zonas de Resolución Inversa.

NS (Name Server) Registro de servidor de nombres que sirve para definir una lista de servidores de

nombres con autoridad para un dominio.

SOA

(Start of Authority)

Registro de inicio de autoridad que especifica el Servidor DNS Maestro (o

Primario) que proporcionará la información con autoridad acerca de un dominio de

Internet, dirección de correo electrónico del administrador, número de serie del

dominio y parámetros de tiempo para la zona.

SRV (Service) Registro de servicios que especifica información acerca de servicios disponibles a

través del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP

(Extensible Messaging and Presence Protocol) suelen requerir registros SRV en la zona para proporcionar información a los clientes.

TXT (Text) Registro de texto que permite al administrador insertar texto arbitrariamente en un

registro DNS. Este tipo de registro es muy utilizado por los servidores de listas

negras DNSBL (DNS-based Blackhole List) para la filtración de Spam. Otro ejemplo de uso son las VPN, donde suele requerirse un registro TXT para definir

una llave que será utilizada por los clientes.


8


BIND 9.5

[email protected]

9

Las zonas que se pueden resolver son:

2.3.1. Zonas de Reenvío Devuelven direcciones IP para las búsquedas hechas para nombres FQDN (Fully Qualified Domain Name).

En el caso de dominios públicos, la responsabilidad de que exista una Zona de Autoridad para cada Zona de

Reenvío corresponde a la autoridad misma del dominio, es decir, y por lo general, quien esté registrado como autoridad del dominio tras consultar una base de datos WHOIS. Quienes compran dominios a través de un

NIC (por ejemplo: www.nic.mx) son quienes se hacen cargo de las Zonas de Reenvío, ya sea a través de su

propio Servidor DNS o bien a través de los Servidores DNS de su ISP.

Salvo que se trate de un dominio para uso en una red local, todo dominio debe ser primero tramitado con un

NIC como requisito para tener derecho legal a utilizarlo y poder propagarlo a través de Internet.

2.3.2. Zonas de Resolución Inversa Devuelven nombres FQDN (Fully Qualified Domain Name) para las búsquedas hechas para direcciones IP.

En el caso de segmentos de red públicos, la responsabilidad de que exista de que exista una Zona de Autoridad para cada Zona de Resolución Inversa corresponde a la autoridad misma del segmento, es decir, y

por lo general, quien esté registrado como autoridad del segmento tras consultar una base de datos WHOIS.

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

3. Instalación de los paquetes

3.1. Paquetes necesarios para la configuración

Primero que nada se requiere tener instalado los siguientes paquetes.

bind:

Este paquete incluye el Servidor DNS (named) y herramientas para verificar su funcionamiento.

bind-libs: Este paquete contiene Bibliotecas compartida que consiste en rutinas para aplicaciones para utilizarse cuando

se interactúe con Servidores DNS.

bind-chroot:

Contiene un árbol de ficheros que puede ser utilizado como una jaula chroot para named añadiendo

seguridad adicional al servicio.

bind-utils:

Este paquete contiene una Colección de herramientas para consultar Servidores DNS.

Caching-nameserver:

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


9


BIND 9.5

[email protected]

9

3.2. Comprobando que los paquetes estén instalados. Para comprobar que los paquetes estén instalados utilizáremos el comando “rpm -q nombrepaquete” en una

terminal. Este se hace para todos los paquetes que se quieran verificar, si el paquete está instalado nos

devolverá el nombre del paquete y su número de versión. Esto sería algo así:

[root@nitsugario ~]# rpm -q bind

bind-9.5.0-29.b2.fc9.x86_64

[root@nitsugario ~]# rpm -q bind-libs

bind-libs-9.5.0-29.b2.fc9.x86_64

[root@nitsugario ~]# rpm -q bind-chroot

bind-chroot-9.5.0-29.b2.fc9.x86_64

[root@nitsugario ~]# rpm -q bind-utils

bind-utils-9.5.0-29.b2.fc9.x86_64

[root@nitsugario ~]# rpm -q cachinh-nameserver El paquete caching-nameserver no está instalado

3.3. Instalar los paquetes necesarios. si la respuesta es coma la que mostro el paquete aching-nameserver , tendremos que instalar los paquetes,

una forma fácil para instalar todos los paquetes es utilizando el comando yum, de la siguiente forma:

[root@nitsugario ~]# yum -y inatall bind bind-libs bind-chroot bind-utils caching-nameserver

Si se utiliza de Red HatTM Enterprise Linux 4, o versiones posteriores, se puede instalar utilizando lo

siguiente:

[root@nitsugario ~]# up2date -i bind bind-chroot bind-utils caching-nameserver

Nota: para la utilización del comando yum y up2date, se requiere tener acceso a internet.

Nota: recuerda que para poder instalar paquetes, debes tener privilegios de súper usuario.

Una vez instalado todo lo necesario, podemos empezar a configurar nuestro servidor.

4. Configuración del servidor

Primero voy explicar cómo se conformara el ejemplo que vamos a utilizar. Se esta utilizando Fedora 9, el

servidor está conectado a una red privada (LAN),el cual tiene una dirección IP que es la 192.168.1.2 y en la

red están otras dos maquinas que son las PCs de mi hermano Cesar (IP 192.168.1.1, SO. Windows XP) y la PC de mi hermana Luz Elena (IP 192.168.1.3, SO Windows XP). Para esta red he escogido el dominio

“nitsugario.com”, el cual tendrá los servicios y www, pop3, smtp, ftp, estor servicios serán configurados

posterior mente.


10


BIND 9.5

[email protected]

9

4.1. Archivos de configuración.

4.1.1. El archivo named.conf:

este archivo es el principal para la configuración de named y es el que nos indica porque puerto escuchara el servidor, porque dirección IP, es donde se agregan las zonas de los dominós, indica quienes tienen permisos

de realizar búsquedas y otros parámetros mas que se explicaran más adelante.

Se encuentra en el directorio /etc. Para acceder a él, usamos el comando “cd ” de la siguiente forma.

[root@nitsugario ~]# cd /etc

para ver el contenido del directorio usamos el comando “ls”. [root@nitsugario etc]# ls

4.1.2. El archivo named.rfc1912.zones: En este archivo se declaran las zonas existentes en el servidor, zona de reenvió y zona de resolución inversa,

así como llamada a los archivos en los que se encuentra la configuración de dichas zonas.

Se encuentra en el directorio /etc. Para acceder a el, usamos el comando “cd ” de la siguiente forma.

[root@nitsugario ~]# cd /etc

4.1.3. Archivos de zonas. Estos archivos los tenemos que crear nosotros (archivo de zona de reenvió y archivo de zona de resolución

inversa) y guardarlos con un nombre que sea representativo a la función que realiza o a la información que contienen. Estos documentos se tienen que guardar en el directorio var/named/chroot/var/named.


11


BIND 9.5

[email protected]

9

4.1.3.1. Archivo de zona de reenvió (nitsugario.com.zone):

En este archivo se especifica la dirección IP asociada a un nombre de un dominio, servicio o subdominio. Él nombre elegido para este archivo fue nitsugario.com.zone

4.1.3.2. Archivo de zona de resolución inversa (192.168.1 ): En este archivo se especifica un nombre asociado a una dirección IP de un dominio, servicio o subdominio.

Él nombre elegido para este archivo fue 192.168.1. Que representa la dirección de red con la que se

trabajara, este nombre puede ser cualquier otro.

4.2. Configuración de los archivos y creación del los archivos de zonas.

4.2.1. Creación de archivos de zonas.

Los siguientes corresponderían a los contenidos para los ficheros de zona requeridos para la red local (dominio nitsugario.com) y por el NIC con el que se haya registrado el dominio. Note por favor que en las

zonas de reenvío siempre se especifica al menos un Mail Exchanger (MX) y que se utilizan tabuladores

(tecla TAB) en lugar de espacio. Solo necesitará sustituir nombres y direcciones IP, y quizá añadir nuevos registros para complementar su red local o lo que quiera hacer.

4.2.1.1. Zona de reenvió nitsugario.com Nombre del archivo: nitsugario.com.zone

Se guarda en: /var/named/chroot/var/named/ Contenido del archivo:

$TTL 86400 @ IN SOA nitsugario.com. [email protected]. (

2009021701; número de serie

28800 ; tiempo de refresco 7200 ; tiempo entre reintentos de consulta

604800 ; tiempo tras el cual expira la zona

86400 ; tiempo total de vida

)

nitsugario.com. IN NS ns1.nitsugario.com.

nitsugario.com. IN MX 10 ns1.nitsugario.com. localhost IN A 127.0.0.1

nitsugario.com. IN A 192.168.1.2

ns1 IN A 192.168.1.2

cesar IN A 192.168.1.1 luz IN A 192.168.1.3

www IN A 192.168.1.2

pop3 IN A 192.168.1.2 smtp IN A 192.168.1.2

ftp IN A 192.168.1.2

Nota: Cada vez que haga algún cambio en algún fichero de zona, deberá cambiar el número de serie

(serial) a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendría que reiniciar el equipo, algo poco conveniente.

Nota: un punto y coma, ";", en el archivo indica que todo lo que hay a su derecha es un comentario.


12


BIND 9.5

[email protected]

9

4.2.1.1.1. Descripción del archivo nitsugario.com.zone A continuación desmenuzaremos el contenido del archivo nitsugario.com.zone, indicando para que sirve

cada línea escrita en el.

Línea 1. $TTL 86400 :

Directiva obligatoria a partir de la versión 9 de Bind (RFC1035 y RFC2308), indica el tiempo de vida (TTL,

del inglés, Time To Live) de la información contenida en el fichero. Es decir, el tiempo

máximo de validez, tras el cual deberá refrescarse o actualizarse (para comprobar que no haya cambiado). Es lo que se conoce como caché positiva/negativa (del inglés, positive/negative caching), como se especifica

en el RFC2308. Por defecto se usan segundos (604800 segundos equivale a siete días exactos), pero pueden

usarse también semanas ($TTL 1w), días ($TTL 7d), horas ($TTL 168h) y minutos ($TTL 10080m). Estas abreviaturas se usan asimismo en el registro SOA, que se explica a continuación.

Línea 2, @ IN SOA nitsugario.com. [email protected]. :

El registro SOA (del inglés, Start Of Authority) se encuentra siempre tras las directivas y proclama

información relevante sobre la autoridad de un dominio al servidor de nombres. Es siempre el primer

recurso en un fichero de zona. El símbolo "@" (arroba) equivale a la directiva $ORIGIN (o el nombre de la

zona si dicha directiva no se ha usado − caso más frecuente) como espacio de nombres de dominio definido por este registro. Este sería el esqueleto de este registro:

@ IN SOA <primary−name−server> <hostmaster−email> ( <serial−number>

<time−to−refresh>

<time−to−retry> <time−to−expire>

<minimum−TTL> )

El servidor de nombres primario que es el autorizado de este dominio se usa en <primary−name−server> y el correo electrónico de la persona a contactar acerca de este espacio de nombres (del inglés, namespace) se

sustituye en <hostmaster−email> (fíjese el lector que no tiene porqué corresponder con una dirección del

propio dominio, como es el caso de la zona nitsugario.com).

El campo <serial−number> es un número que se incrementa cada vez que se modifica un fichero de una

zona, de forma que Bind se dé cuenta de que tiene que recargar esta zona. Se recomienda usar la fecha de

modificación en formato AAAAMMDD, donde AAAA es el año en formato de cuatro cifras, MM es el mes en dos cifras, y DD es el día de mes en dos cifras, seguido de un número de dos cifras, empezando por el 01.

De este modo se podrán realizar hasta cien cambios por día.

El campo <time−to−refresh> le dice a los servidores secundarios (esclavos) cuánto tiempo deben esperar

antes de preguntar a su servidor principal (maestro) si se ha hecho algún cambio en la zona.

El valor del campo <serial−number> es usado por los esclavos para determinar si se está usando información

anticuada que deba actualizarse.

El campo <time−to−retry> especifica a los servidores esclavos el intervalo de tiempo a esperar antes de solicitar una actualización en el caso de que el servidor de nombres principal no esté respondiendo. Si el

servidor maestro no ha respondido a la petición de actualización antes de que expire el tiempo del campo

<time−to−expire>, el esclavo dejará de actuar como servidor el autorizado de ese espacio de nombres (zona).

El campo <minimum−TTL> solicita a otros servidores de dominio que almacenen en su caché la

información de esta zona durante al menos la cantidad de tiempo en él especificada.


13


BIND 9.5

[email protected]

9

Nota: El campo <primary−name−server> termina en un punto, que es obligatorio poner, y que

representa, según lo explicado en el apartado introductorio del artículo, el servidor de nombres raíz. Asimismo, este punto aparecerá en todas las referencias explícitas al dominio a lo largo del fichero. Cuando

se configura un host o subdominio, por ejemplo ftp, se hace una referencia implícita y Bind añade

automáticamente el dominio, que saca de la "@" del registro SOA. En cualquier caso, es posible usar

referencias implícitas o explícitas indistintamente.

Línea 3, nitsugario.com. IN NS ns1.nitsugario.com. :

indican los servidores de nombre que tienen autoridad sobre el dominio. Nótese que, a partir de aquí, en la zona nitsugario.com se explicita, como se ha comentado en el punto anterior, el nombre del dominio

completo así como el prefijo.

Línea 4, nitsugario.com. IN MX 10 ns1.nitsugario.com. :

se trata de un registro MX (del inglés, Mail eXchanger) e indica dónde mandar el correo destinado a un

espacio de nombres controlado por esta zona. El dígito que sigue a la palabra MX representa la prioridad

respecto a otros registros MX para la zona, que se especificarían en posteriores líneas, siguiendo el mismo formato pero variando dicho dígito (incrementándolo a medida que pierdan prioridad frente a anteriores

registros). Es decir, cuanto más bajo es el valor de preferencia, mayor prioridad adquiere.

Línea 5, localhost IN A 127.0.0.1 :

Registro que relaciona el host local con su IP de loopback.

Línea 6, nitsugario.com. IN A 192.168.1.2 :

Registro que relaciona el nombre de dominio de segundo nivel (el "principal" de la zona) con la IP donde

está hospedado. Este es el registro más usado, pues cualquier petición a nitsugario.com será resuelta

mediante este registro, se use el protocolo de comunicaciones que se use (por ejemplo, http://nitsugario.com).

Línea 7, ns1 IN A 192.168.1.2: A partir de aquí empieza la traducción de subdominios del dominio para el cual somos el autorizado: los

dominios de tercer nivel y sucesivos. Fíjese en que debe crearse un registro para cada uno, sin posibilidad de

"agrupar" de ningún modo. Asimismo, nótese que, al ser subdominios de la zona, se ha omitido el sufijo

nitsugario.com., que se encuentra implícito debido a que no termina en "." (punto).Es simplemente una cuestión de claridad y ahorro de espacio, pues las representaciones en ambas zonas son − repetimos de nuevo

− igualmente correctas. Otros registros similares se citan, agrupados, a continuación:

cesar IN A 192.168.1.1

luz IN A 192.168.1.3

www IN A 192.168.1.2 pop3 IN A 192.168.1.2

smtp IN A 192.168.1.2

ftp IN A 192.168.1.2

A propósito del concepto de alias (www, pop3, smtp y ftp son de hecho el mismo host) existe una

controvertida discusión sobre si es mejor usar el tipo de registro CNAME (del inglés, Canonical NAME) o

IN A. Muchos gurús de Bind recomiendan no usar registros CNAME en absoluto, si bien esa discusión se escapa de los objetivos de este artículo. En cualquier caso, es muy recomendable seguir la regla de que los

registros MX, CNAME y SOA nunca deben referenciar un registro CNAME, sino exclusivamente algo con

un registro tipo "A".

Por lo tanto, no es aconsejable usar:

web CNAME www


14


BIND 9.5

[email protected]

9

Pero sí sería correcto:

web CNAME ns1 También es seguro asumir que un CNAME no es un host adecuado para una dirección de correo electrónico:

[email protected], sería incorrecta dada la configuración de arriba. La manera de evitar esto

es usar registros "A" (y quizás algunos otros también, como el registro MX) en su lugar. El autor de este artículo se decanta por el uso de IN A y recomienda dicha práctica.

4.2.1.2. Zona de resolución inversa 1.168.192.in-addr.arpa En estos momentos, los programas son ya capaces de convertir los nombres en nitsugario.com a direcciones

a las cuales pueden conectarse. Pero también se requiere una zona inversa, capaz de permitir al DNS

convertir una dirección en un nombre. Este nombre es usado por muchos servidores de diferentes clases (ftp, irc, www y otros) para decidir si quieren "hablar" con el cliente o no y, si es el caso, quizás incluso cuánta

prioridad se le debe asignar. Para poder tener acceso completo a todos estos servicios en Internet es necesaria

una zona inversa.

Nombre del archivo: 192.168.1

Se guarda en: /var/named/chroot/var/named/

Contenido del archivo:

$TTL 86400 @ IN SOA nitsugario.com. [email protected]. (

2009021701 ; número de serie

28800 ; tiempo de refresco

7200 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona

86400 ; tiempo total de vida

)

@ IN NS ns1.nitsugario.com.

2 IN PTR ns1.nitsugario.com. 1 IN PTR cesar.nitsugario.com.

3 IN PTR luz.nitsugario.com.

2 IN PTR www.nitsugario.com.

2 IN PTR pop3.nitsugario.com. 2 IN PTR smtp.nitsugario.com.

2 IN PTR ftp.nitsugario.com.

Nota: Cada vez que haga algún cambio en algún fichero de zona, deberá cambiar el número de serie

(serial) a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de

otro modo tendría que reiniciar el equipo, algo poco conveniente.

Nota: un punto y coma, ";", en el archivo indica que todo lo que hay a su derecha es un comentario.


15


BIND 9.5

[email protected]

9

4.2.1.2.1. Descripción del archivo 192.168.1 A continuación desmenuzaremos el contenido del archivo 192.168.1, indicando para que sirbe cada línea

escrita en el.

De nuevo, los conceptos son los mismos (la "@" − arroba − indica el dominio de la zona nitsugario.com., el

"." − punto − del final hace referencia al servidor de nombres raíz y el registro "SOA" tiene exactamente la

misma estructura y funcionalidad), excepto las dos últimas líneas:

Línea @ IN NS ns1.nitsugario.com. :

Indican a qué servidores de nombres debe preguntarse por la traducción inversa de una dirección IP de esta

zona.

Línea 2 IN PTR ns1.nitsugario.com. :

Este es el registro que se usará para devolver el nombre que queremos que corresponda con la dirección IP que nos pertenece (cuidado al crear estos registros, pues debe hacerse referencia exclusivamente a

direcciones IP que sean de nuestra propiedad o provocaríamos un conflicto). En este caso se indica que la

dirección 2 (implícitamente se le añade el sufijo.1.168.192.in−addr.arpa, lo que indica que se trata de

"nuestra" dirección IP 192.168.1.2) equivale al host ns1.nitsugario.com.

Es obvio que aquí "falta información", pues la dirección IP 192.168.1.2 equivale, en realidad, a más hosts, tal y como hemos especificado en el fichero 192.168.1. Esto es cierto los cuales son:

2 IN PTR www.nitsugario.com. 2 IN PTR pop3.nitsugario.com.

2 IN PTR smtp.nitsugario.com.

2 IN PTR ftp.nitsugario.com.

También falta mencionar las demás IP de las otras dos maquinas que están en la red. Y para estas cambia el

número inicial que es el que corresponde a su IP.

1 IN PTR cesar.nitsugario.com.

3 IN PTR luz.nitsugario.com.

Estos dos son diferentes por sus IPs que serian, para cesar la dirección 192.168.1.1 y para Luz 192.168.1.2.

4.2.2. Configuración del archivo named.rfc1912.zones

El contenido del archivo será:

zone "nitsugario.com" {

type master;

file "nitsugario.com.zone"; allow-update { none; };

};

zone "1.168.192.in-addr.arpa" {

type master; file "192.168.1";

allow-update { none; };

};


16


BIND 9.5

[email protected]

9

4.2.2.1. Descripción del archivo named.rfc1912.zones

Línea zone "nitsugario.com" { :

Indica que se está creando la zona nitsugario.com.

Línea type master; :

Significa que el servidor de dominios es primario o maestro de la zona.

Línea file "nitsugario.com.zone"; :

Es el fichero donde especificaremos la configuración de esa zona, el cual guardamos en el directorio

/var/named/chroot/var/named/. Y que ya explicamos.

Línea allow-update { none; }; :

Significa que no admite actualizaciones automáticas.

En este archivo puede a ver más para metro, los cuales son usados para aumentar la seguridad del servidor.

Los cuales pueden ser.

allow−query { any; }; :

Significa que se permiten consultas (del inglés, queries) externas a la zona.

Esto es algo útil y necesario, a menos que se quiera ser muy paranoico con la seguridad. Simplemente se ofrece de forma técnicamente ordenada la información que es públicamente accesible.

allow−transfer { slaves; }; :

Posibilita la transferencia automática de esta configuración a los servidores secundarios de las zonas bajo

nuestro control que se especifiquen en la lista slaves. Se profundizará más en el punto de transferencia de

zonas.

Se han usado dos palabras especiales, any y slaves, que requieren una mención especial. Efectivamente,

además de hacer notar la sintaxis similar a la del lenguaje de programación C, con la que se debe ser extremamente cuidadoso, hay dos comentarios extras que hacer:

1. any es una palabra reservada de la sintaxis de bind que significa "cualquier dirección IP", como era lógico. Su uso es muy común y necesario. Otras palabras reservadas importantes son none, que

significa "ningún host", localhost, que significa el host local desde cualquiera de las interfaces del

sistema, y localnets, que representa a todos los hosts de las redes para las cuales el sistema tiene una interfaz.

2. slaves, en cambio, no es ninguna palabra reservada de bind, sino que corresponde al concepto de lista

de control de acceso (ACL, del inglés, Access Control List). Estas listas de direcciones IP nos ahorran trabajo

pues, de este modo, tan sólo tenemos que especificarlas una vez y, dado que les asginamos un identificador

de grupo, podemos referenciarlas de forma más simple y rápida. Este es el código de la ACL usada en el ejemplo que, por supuesto, debe especificarse en algún lugar del documento antes de ser usada:

acl "slaves" { 213.96.79.79;

};

El lector se habrá dado cuenta en seguida de las grandes ventajas de usar estas listas, aún cuando, como en este caso, no gane materialmente excepto en previsión de un tercer servidor de nombres secundario. Nótese

que en los identificadores de las ACL se diferencian mayúsculas y minúsculas (en inglés, case sensitive).


17


BIND 9.5

[email protected]

9

4.2.3. Configuración del archivo named.conf

El contenido del archivo es:

options {

listen-on port 53 { 192.168.1.2; };

listen-on-v6 port 53 { ::1; };

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;};

};

logging { channel default_debug {

file "data/named.run";

severity dynamic;

}; };

zone "." IN {

type hint; file "named.ca";

};

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

4.2.3.1 Descripción del contenido del archivo named.conf

La clausula options: Agrupa declaraciones que controlan el comportamiento general o global y tiene alcance en todas las zonas, vistas y en otras clausulas. Esta clausula puede tomar una gran cantidad de declaraciones.

Sintaxis: options {

// Declaraciones de opciones

};

Descripción de los parámetros de la cláusula options:

Línea: listen-on port 53 { 192.168.1.2; };

Define el puerto y la dirección IPv4 sobre el que BIND escuchará las peticiones entrantes. El puerto por

defecto para el servidor DNS es el puerto 53. Se pueden hacer múltiples declaraciones de listen-on.

Línea: listen-on-v6 port 53 { ::1; };

Define el puerto y la dirección IPv6 sobre el que BIND escuchará las peticiones entrantes. El puerto por

defecto para el servidor DNS es el puerto 53. Se pueden hacer múltiples declaraciones de listen-on.

Línea: directory "/var/named";

Define una ruta que define el directorio de base usado para zona y Otros archivos que usa BIND.

Línea: dump-file "/var/named/data/cache_dump.db";

Espesifica una ruta total donde BIND vuelca el caché en respuesta a un comando de dumpdb de rndc. Si

no especificado, el incumplimiento es named_dump.db en la ubicación especificado por una declaración de

directorio.


18


BIND 9.5

[email protected]

9

Línea: statistics-file "/var/named/data/named_stats.txt";

El nombre del archivo al que el servidor añade estadística cuando se ordena se usa estadísticas de rndc. Si no es especificado, el archivo por defecto es named.stats.

Línea: memstatistics-file "/var/named/data/named_mem_stats.txt"; El nombre del archivo al que el servidor escribe estadística de uso de memoria. Si no especificado, el archivo

por defecto es named.memstats.

Línea: allow-query { any;};

Un address_match_list definir qué anfitriones ser permitido emitir consultas al servidor. Si no especificado,

todos anfitriones son permitidos hacer las preguntas.

La clausula logging: Define las características comportamiento y formato de BIND’s extensive logging.

La clausula zone: Contiene declaraciones que definen el comportamiento para una zona en específico. El alcance de La Declaración es limitada a esa zona solamente.

La clausula include: La declaración de inclusión es única y puede estar en cualquier lugar del archivo de named.conf, no puede

estar declarada dentro o fuera de una cláusula. Lo que hace esta clausula es leer el contenido del archivo

especificad para procesar lo que este escrito. Su declaración tiene la siguiente forma:

include "Nombre de archivo";

El nombre de archivo es una cadena dada y puede ser una ruta total, por ejemplo, /var/named/file.name,

O respectivo, por ejemplo, file.name, en este caso donde no se declaró un directorio, se da por hecho que es

el directorio donde esta named.conf que es normalmente /etc.

La declaración de inclusión es usada para tres propósitos típicamente:

1. Simplificar o distribuir la administración de named.conf presente el mantenimiento: por ejemplo, Las zonas pueden ser administradas por separado por divisiones de una compañía.

2. Para aislar y dividir los cambios y las actualizaciones: por ejemplo, si las cláusulas de acl cambian

frecuentemente, Puede ser deseable separarlos en archivos que pueden estar incluidos, a saber Minimizar la necesidad de editar el archivo de named.conf principal.

3. Controlar los permisos: puede ser deseable limitar el acceso usando permisos restringidos.

5. Comprobando que funcione la configuración Al terminar de editar todos los ficheros involucrados, solo bastará iniciar el servidor de nombres de dominio.

5.1. Iniciando el servidor: Para iniciar el servidor usaremos el comando service named start. Y si todo está bien tendremos un resultado

como el siguiente.

[root@nitsugario ~]# service named start

Iniciando named: [ OK ]


19


BIND 9.5

[email protected]

9

5.2. Parando el servidor: Para parar el servidor usaremos el comando service named stop. Y si todo está bien, tendremos un resultado

como el siguiente.

[root@nitsugario ~]# service named stop

Deteniendo named: [ OK ]

5.3. Reiniciando el servidor: Para reiniciar el servidor usaremos el comando service named restart. Y si todo está bien tendremos un

resultado como el siguiente.

[root@nitsugario ~]# service named restart Deteniendo named: [ OK ]

Iniciando named: [ OK ]

5.4. Añadir el servidor al arranque del sistema:

Si queremos que el servidor de nombres de dominio quede añadido entre los servicios en el arranque del

sistema, deberemos ejecutar lo siguiente a fin de habilitar named junto con el arranque del sistema:

[root@nitsugario ~]#chkconfig named on

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

[root@nitsugario ~]#tail -80 /var/log/messages |grep named

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

Feb 18 04:13:24 nitsugario named[6898]: starting BIND 9.5.0b2 -u named -t /var/named/chroot

Feb 18 04:13:24 nitsugario named[6898]: found 2 CPUs, using 2 worker threads

Feb 18 04:13:24 nitsugario named[6898]: loading configuration from '/etc/named.conf'

Feb 18 04:13:24 nitsugario named[6898]: the working directory is not writable

Feb 18 04:13:24 nitsugario named[6898]: listening on IPv6 interface lo, ::1#53

Feb 18 04:13:24 nitsugario named[6898]: default max-cache-size (33554432) applies

Feb 18 04:13:24 nitsugario named[6898]: zone nitsugario.com/IN: sending notifies (serial 2009021602)

Feb 18 04:13:24 nitsugario named[6898]: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2009021602)

Feb 18 04:13:24 nitsugario named[6898]: running


20


BIND 9.5

[email protected]

9

5.6. Pruebas con ping:

Primera prueba: se dio ping al subdominio ns1.nitsugario.com.

Segunda prueba se dio ping a la PC de Cesar, cesar.nitsugario.com.

Como se puede ver en las imágenes se el servidor ya está funcionando correctamente. Y ya con esto tenemos un servidor DNS básico para un pequeña LAN.


21


BIND 9.5

[email protected]

9

Bibliografía

Libro en ingles. pro DNS and BIND, Ronald G.F. Aitchison, Apress, ISBN (pbk): 1-59059-494-0.

El Sistema de nombres de dominio: Bind 9.2.1,por Jaume Sabater, modificado el 06/03/2003,

http://bulma.net

Implementación de servidores con GNU/Linux, joel Barrios Dueñas, Edicion Agosto 2008,

http://www.alcancelibre.org/staticpages/index.php

DNS (Sistema de nombre de dominio) http://es.kioskea.net/contents/internet/dns.php3

The DNS Resources Directory, http://www.intac.com/~cdp/cptd-faq/

DNS HowTo, http://www.tldp.org/HOWTO/DNS-HOWTO.html

Securing DNS with Transaction Signatures, http://www.linux.ie/articles/tutorials/dns-tsig.php

All About DNS, http://www.linux.ie/articles/dns.php

DNS Cómo, http://cauchy.bdat.net/dns/bind-9/DNS-HOWTO-9-es/

Los RFC que definen el sistema de DNS están disponibles en http://www.rfc−editor.org

http://bulma.net/

http://www.alcancelibre.org/staticpages/index.php

http://es.kioskea.net/contents/internet/dns.php3

http://cauchy.bdat.net/dns/bind-9/DNS-HOWTO-9-es/

http://www.tldp.org/HOWTO/DNS-HOWTO.html

http://www.linux.ie/articles/tutorials/dns-tsig.php

http://www.linux.ie/articles/dns.php

http://cauchy.bdat.net/dns/bind-9/DNS-HOWTO-9-es/

http://www.rfc/

Servidor DNS en Fedora9 (1)

Documents

Transcript of Servidor DNS en Fedora9 (1)