Dns en linux debían squeeze 6

DNS en Linux Debían Squeeze 6.0

Servidor DNS
DNS Maestro Primario para una LAN en Debian 6.0 (I)
Comenzamos la serie de posts sobre ¿Cómo instalar y configurar un DNS Maestro Primario y Caché en Debian Squeeze?, con los cuales
pretendemos dar un Punto de Entrada al fascinante mundo de éste servicio imprescindible para el funcionamiento de la Red de Redes
que es Internet.
Todos los artículos están desarrollados para que puedan utilizarse de forma secuencial. La 1ra y 2da parte contienen el mínimo de
conocimientos teóricos necesarios para que el Nuevo o Newbie pueda entender y desarrollar la instalación de un DNS.
A ellos le recomendamos no se amilanen. Lean y apliquen lo escrito y seguro que obtendrán resultados positivos. Y a los Sospechosos
Habituales de caer en la Desesperación, les recomendamos calma, mucha calma si quieren entender en realidad como configurar éste
imprescindible servicio.
Me perdonan el uso de palabras en inglés y algún que otro anglicismo. Se ha hecho para ganar claridad técnica en lo escrito.
Los aspectos que desarrollaremos en esta Primera Parte son los siguientes:
Introducción
Definiciones útiles
Configuraciones más comunes de un DNS
Zonas y Registros
Tiempos de expiración de Zonas
Tips

Introducción
Dicen en la Aldea WWW que el DNS es una de las áreas más obscuras de los servicios de redes. Afortunadamente no es así -sobre todo
para una LAN- como lo demostraremos a través de los artículos siguientes. Por mucho que uno no lo desee, es casi obligatorio leer una
pequeña parte teórica.
Definición según Wikipedia:

El DNS es una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como
Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más
comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada
dominio.
La asignación de nombres a direcciones IP es ciertamente la función más conocida de los protocolos DNS. Por ejemplo, si la
dirección IP del sitio FTP de prox.mx es 200.64.128.4, la mayoría de la gente llega a este equipo especificando ftp.prox.mx y no la
dirección IP. Además de ser más fácil de recordar, el nombre es más fiable. La dirección numérica podría cambiar por muchas
razones, sin que tenga que cambiar el nombre.
Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. En un
inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS que contenía todos los nombres de dominio conocidos
(técnicamente, este archivo existe, y la mayoría de los sistemas operativos actuales pueden ser configurados para revisar su archivo
hosts). El crecimiento explosivo de la red causó que el sistema de nombres centralizado en el archivo hosts no resultara práctico y
en 1983, Paul Mockapetris publicó los RFCs 882 y 883 definiendo lo que hoy en día ha evolucionado hacia el DNS moderno. (Estos
RFCs han quedado obsoletos por la publicación en 1987 de los RFCs 1034 y 1035).
A las computadoras en las que se ejecuta éste servicio se les denomina “Servidores de Nombres”. Debian trae en sus repositorios varios
programas para tener un DNS funcional y entre ellos se encuentra el más utilizado en Internet: El BIND o “Berkley Internet Naming

Domain”. BIND es el estándar de facto como servidor DNS. Es Software Libre y se distribuye con la mayoría de las plataformas UNIX y

Linux. También se refieren al BIND como “named” (demonio named). Puede encontrar aquí (Wikipedia en ingles) una comparación de
distintos tipos de servidores DNS.

Definiciones útiles
NetBIOS: Network Basic Input/Output System (NetBIOS): Sistema básico de entrada y salida de red (NetBIOS). Interfaz de programación
de aplicaciones (API) que pueden utilizar los programas en una red de área local (LAN). NetBIOS proporciona a los programas un
conjunto uniforme de comandos para solicitar los servicios de bajo nivel necesarios para administrar nombres, dirigir sesiones y enviar
“datagramas” entre los nodos de una red.
Nombre NetBIOS: Nombre de 16 bits de un proceso que utiliza el sistema básico de entrada y salida de red (NetBIOS). Nombre
reconocido por el servicio WINS (Windows Internet Name System) de Microsoft, el cual asocia o “mapea” un nombre de equipo o host a
una determinada dirección IP.
FQDN: “Fully Qualified Domain Name” o Nombre de Dominio Plenamente Calificado. Como el traducir nombres creados en inglés técnico
es a menudo tremendo, recomiendo se aprendan el nombre en inglés y para propósitos prácticos se refieran a él como el FQDN. No es
más que el Nombre de dominio DNS que se ha establecido para indicar su ubicación absoluta en el árbol de espacio de nombres de
dominio.
En oposición a los nombres relativos, un FQDN va precedido por un punto para indicar su posición en la raíz del espacio de nombres.
Ejemplo: freake.amigos.cu. es el FQDN del host cuyo nombre NetBIOS es freake y pertenece al dominio amigos.cu.
amigos.cu.
freake.amigos.cu.
otrofreake.amigos.cu.
mail.amigos.cu.

Configuraciones más comunes de un DNS
Podemos configurar un Servidor de Nombre de Dominio o DNS de distintas formas para que brinden servicios diferentes. Las más
utilizadas son:
Servidor Caché (“Caching Nameserver”): Las solicitudes o peticiones hechas al servidor serán resueltas por los Forwarders que le
declaremos en su configuración. Las respuestas se almacenaran y “recordarán” para cuando el Servidor Caché sea consultado
nuevamente, lo cual aumenta considerablemente la velocidad de respuesta.
Maestro Primario (“Primary Master”): Las solicitudes o peticiones hechas al servidor serán resueltas mediante la lectura de los datos
almacenados en los archivos locales de las Zonas creadas. Como su nombre indica, será un Servidor de Nombres Autoritario para la
Zona consultada.
Maestro Secundario (“Secondary Master”): Las solicitudes o peticiones hechas al servidor serán resueltas mediante la consulta directa a
un servidor Maestro Primario Autoritario para la Zona consultada. Mantiene una copia actualizada de las Zonas del Maestro Primario.
También lo podemos configurar de forma que realicen varias funciones a la vez, como el ser un Maestro Primario y Caché al mismo
tiempo, lo cual es muy común en nuestras redes empresariales.

Zonas y Registros
Las Zonas son archivos de texto plano que nos permiten organizar los Registros DNS. Cada nombre de zona concuerda con el nombre
de un dominio, o con un rango de direcciones IP tal como el de una o varias subnets. Contiene, además de otros datos,
varios Registros de diferentes Clases o Tipos, de los cuales mencionaremos solo los siguientes:
SOA: “Start of Authority”. Comienzo de la Autoridad. Es un registro obligatorio en cada Zona, y debe existir solamente uno sólo en cada
archivo. Es el preámbulo de todos los archivos de zona. Describe la zona en si misma; de cual máquina o host proviene; quien es el
responsable de su contenido; cual es la versión del archivo de zona, y otros aspectos concernientes al propio funcionamiento del servidor
DNS. Es imprescindible que en cada archivo de zona exista un registro tipo A que identifique a la máquina o host donde radica el servidor
DNS.
NS: Mapea un nombre al Servidor de Nombres. Cada dominio debe tener al menos un registro NS. Este registro apunta a un Servidor
DNS que puede responder las consultas concernientes al dominio. Puede apuntar al Maestro Primario o al Maestro Secundario.

A: “Address” – (Dirección). Este registro se usa para traducir nombres de hosts a direcciones IPv4.
AAAA: “Address” – (Dirección). Este registro se usa para traducir nombres de hosts a direcciones IPv6.
CNAME: “Canonical Name” – (Nombre Canónico). Tipo de registro mediante el cual podemos dar varios nombres a un mismo host o
crear Alias de él. Digamos que tenemos el host web.amigos.cu. en el cual tenemos instalado un servidor web y queremos que se refieran
a el como www.amigos.cu. Entonces en la Zona amigos.cu debemos tener entre los demás registros:
web

IN

A

192.168.10.20

www

IN

CNAME

web.amigos.cu.

MX: “Mail Exchange” o Servidor de Correo. Información utilizada por otros servidores de correo para saber adonde enviar un correo dada
una dirección IP. Cada registro MX tiene una prioridad, donde la más alta la tiene el registro con el menor número. Ejemplos:
10 mail1.amigos.cu.
20 mail2.amigos.cu.

PTR: Mapeo de una dirección IP a un nombre. Tipos de registros almacenados en las denominadas “Zonas Inversas”. Por ejemplo, la
Zona 10.168.192.in-addr.arpa es la que contiene el mapeo inverso de todas las direcciones del rango de direcciones IP 192.168.10.0/24
Por supuesto que la lista de tipos de registros continúa…

Tiempos de expiración o caducidad de zonas
Cuando estamos creando los archivos de las Zonas de registros DNS, debemos configurar los Tiempos de Expiración en segundos. Sin
embargo podemos especificarlos de una forma más corta acorde a la siguiente tabla:
Segundos

Unidades

Descripción

60

1M

A un minuto

1800

30M

A 30 minutos

3600

1H

Una Hora

10800

3H

3 horas

21600

6H

6 horas

43200

12H

12 horas

86400

1D

Un día

259200

3D

3 días

604800

1W

Una semana

Tips
Debemos ser muy cuidadosos al escribir en los archivos de zonas. Los FQDN tienen que terminar en un “.” (o sea, punto), y no podemos
dejar espacios en blanco al final de cada línea. Por esa razón recomendamos fuertemente el uso de editores de consola como el vi o
el nano. Nosotros emplearemos el nano, el cual a nuestro criterio es más fácil de usar. Por supuesto que también podemos usar editores
de texto plano con ambiente gráfico o GUI.
Espero no se hayan aburrido pues aun queda un poco para entrar en materia.

DNS Maestro Primario para una LAN en Debian 6.0 (II)
Continuamos con nuestra serie de artículos y en éste trataremos los siguientes aspectos:
Instalación
Directorios y archivos principales

Antes de continuar, les recomendamos no dejar de leer:
DNS Maestro Primario para una LAN en Debian 6.0 (I)

Instalación
En una Consola y como el usuario root instalamos el bind9:
aptitude install bind9

También debemos instalar el paquete dnsutils el cual tiene las herramientas necesarias para hacer consultas DNS y diagnosticar el
funcionamiento:
aptitude install dnsutils

Si desean consultar la documentación que viene en el repositorio:
aptitude install bind9-doc

La documentación se almacenará en el directorio /usr/share/doc/bind9-doc/arm y el archivo índice o de la Tabla de Contenidos es
el Bv9ARM.html. Para abrirlo ejecute:
firefox /usr/share/doc/bind9-doc/arm/Bv9ARM.html

Cuando instalamos el bind9 en Debian, también lo hace el paquete bind9utils el cual nos aporta varias herramientas muy útiles para
mantener una instalación de trabajo de un BIND. Entre ellas encontraremos rndc, named-checkconf y named-checkzone. Por otra parte,
el paquete dnsutils aporta toda una serie de programas clientes del BIND entre los que estarán el dig y el nslookup. Todas estas
herramientas o comandos las usaremos en los artículos siguientes.
Para conocer todos los programas de cada paquete debemos ejecutar como el usuario root:
dpkg -L bind9utils
dpkg -L dnsutils

O ir al Synaptic, buscar el paquete, y ver cuales son los archivos instalados. Sobre todo los que se instalan en las
carpetas /usr/bin o /usr/sbin.
Si queremos conocer más sobre cómo utilizar cada herramienta o programa instalado, debemos ejecutar:
man <nombre del programa>

Directorios y archivos principales
Cuando instalamos Debian se crea el archivo /etc/resolv.conf. Este archivo o “Fichero de configuración del servicio resolver”, contiene
varias opciones que por defecto son el nombre del dominio y la dirección IP del servidor DNS declarado durante la instalación. Como el
contenido de la ayuda del archivo viene en español y es muy claro, recomendamos la lean mediante el comando man resolv.conf.
Después de instalado el bind9 en Squeeze, se crean al menos los directorios siguientes:
/etc/bind
/var/cache/bind
/var/lib/bind

En el directorio /etc/bind nos encontramos, entre otros, con los siguientes archivos de la configuración:
named.conf
named.conf.options
named.conf.default-zones

named.conf.local
rndc.key

En el directorio /var/cache/bind crearemos los archivos de las Zonas Locales las cuales trataremos posteriormente. Por curiosidad
ejecuten en una Consola los siguientes comandos como el usuario root:
ls -l /etc/bind
ls -l /var/cache/bind

Por supuesto que el último directorio no contendrá nada, pues aun no hemos creado ninguna Zona Local.
El dividir la configuración del BIND en varios archivos se hace por comodidad y claridad. Cada archivo tiene una función específica como
veremos a continuación:
named.conf: Archivo principal de configuración. En él se incluyen los archivosnamed.conf.options, named.conf.local y named.conf.defaultzones.
named.conf.options: Opciones generales del servicio DNS. La directiva: directory “/var/cache/bind” le indicará al bind9 donde buscar los
archivos de las Zonas Locales creadas. También declaramos aquí los servidores “Forwarders” o en una traducción aproximada
“Adelantadores” hasta un número máximo de 3, los cuales no son más que servidores DNS externos que podemos consultar desde
nuestra red (a través de un Firewall por supuesto) que responderán a las preguntas o solicitudes que nuestro DNS local no sea capaz de
responder.
Por ejemplo, si estamos configurando un DNS para la LAN192.168.10.0/24, y queremos que uno de nuestros Forwarders sea un Servidor
de Nombres de la UCI, debemos declarar la directiva forwarders { 200.55.140.178; }; dirección IP que corresponde al servidor ns1.uci.cu.
De esta forma podremos consultarle a nuestro servidor DNS local cual es la dirección IP del host yahoo.es (el cual evidentemente no está
en nuestra LAN), ya que nuestro DNS le preguntará al de la UCI si el sabe cual es la dirección IP de yahoo.es, y luego nos dará a
nosotros un resultado sea satisfactorio o no. También y en el propio archivo named.conf.option declararemos otros aspectos importantes
de la configuración como veremos más adelante.
named.conf.default-zones: Como su nombre lo indica son las Zonas por Defecto. Aquí se le configura al BIND el nombre del archivo que
contiene la información de los Servidores Raíces o Root Servers necesarios para iniciar la caché DNS, más concretamente el
archivodb.root. También se le indica al BIND que tenga plena Autoridad (que sea Autoritario) en la resolución de nombres para
el localhost, tanto en consultas Directas como Inversas, y lo mismo para las zonas “Broadcast”.
named.conf.local: Archivo donde declaramos la configuración local de nuestro servidor DNS mediante el nombre de cada una de
las Zonas Locales, y cuales serán los Archivos de Registros DNS que mapearan los nombres de los equipos conectados a nuestra LAN
con su dirección IP y viceversa.
rndc.key: Archivo generado que contiene la Clave para controlar el BIND. Mediante la utilidad de control del servidor BIND rndc, seremos
capaces de recargar la configuración del DNS sin necesidad de reiniciarlo con el comando rndc reload. Muy útil cuando hacemos cambios
en los archivos de las Zonas Locales.
En Debian los archivos de las Zonas Locales se pueden ubicar también en /var/lib/bind; mientras que en otras distribuciones como Red
Hat y CentOS normalmente se ubican en /var/lib/named u otros directorios en dependencia del grado de seguridad implementado.
Nosotros seleccionamos el directorio /var/cache/bind pues es el que sugiere por defecto Debian en el archivo named.conf.options.
Podemos emplear cualquier otro directorio siempre y cuando le indiquemos al bind9 donde buscar los archivos de las zonas, o le demos
el camino absoluto de cada una de ellas en el archivo named.conf.local. Es muy saludable utilizar los directorios recomendados por la
distribución que estemos usando.
Está fuera del alcance de este artículo el tratar sobre la seguridad adicional que implica el crear una Jaula o “Chroot” para el BIND.
También lo está el tema de la seguridad mediante el contexto SELinux. Aquellos que necesiten implementar tales características, deben
acudir a manuales o a literatura especializada. Recuerden que el paquete de documentación bind9-doc se instala en el
directorio /usr/share/doc/bind9-doc.
Bueno Señores, hasta aquí la 2da Parte. No queremos extendernos más en un solo artículo debido a las buenas recomendaciones de
nuestro Jefe. ¡Al fin! entraremos en el meollo de la Configuración y Pruebas del BIND… en el próximo capítulo.

DNS Maestro Primario para una LAN en Debian 6.0 (III)
Es tremendo esfuerzo reducir en 5 pequeños artículos los Conocimientos Previos, la Instalación, la Configuración, y la Creación de las Zonas
y Comprobaciones de un BIND, de forma que pueda ser entendido por la mayor cantidad de lectores el cual es nuestro propósito
fundamental.
Los que hayan tenido la paciencia de leer con cuidado la 1era y 2da parte de este artículo, están preparados para continuar con la
configuración y puesta a punto de un Servidor de Nombre de Dominio para una LAN.
A los Nuevos, y a aquellos que no tengan bien claros los muy resumidos conceptos dados en las partes precedentes, les recomendamos las
lean y estudien antes de proseguir. ¡Sospechosos habituales de la Desesperación! hacia atrás si no leyeron cuidadosamente .
Veremos a continuación:

Datos principales de la LAN
Configuraciones mínimas del host
Modificaciones al archivo /etc/resolv.conf
Modificaciones al archivo /etc/bind/named.conf
Modificaciones al archivo /etc/bind/named.conf.option
Modificaciones al archivo /etc/bind/named.conf.local

Datos principales de la LAN
Nombre del Dominio de la LAN:

amigos.cu

Subnet de la LAN:

192.168.10.0/255.255.255.0

IP del servidor BIND:

192.168.10.10

Nombre NetBIOS del servidor: ns

Aunque sea evidente, recuerden cambiar los datos anteriores por los suyos propios.

Configuraciones mínimas del host
Muy importante es tener correctamente configurados los archivos /etc/network/interfaces y/etc/hosts para obtener un buen funcionamiento del
DNS. Si durante la instalación se declararon todos los datos, no será necesaria ninguna modificación. Los contenidos de cada uno de ellos
deben ser los siguientes:
# contenido del archivo /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.10.10
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
gateway 192.168.10.2
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.10.10
dns-search amigos.cu

# contenido del /etc/hosts
127.0.0.1

localhost

192.168.10.10

ns.amigos.cu

ns

# The following lines are desirable for IPv6 capable hosts
::1

ip6-localhost ip6-loopback

fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Modificaciones al archivo /etc/resolv.conf
Para que nuestras consultas y comprobaciones funcionen correctamente es necesario declarar en la configuración local del host, cual será
nuestro dominio de búsqueda y cual será nuestro DNS local. Sin los parámetros anteriores como mínimo, cualquier consulta DNS será fallida.
Y éste es un error en el cual caen muchos principiantes. Por tanto, editemos el archivo /etc/resolv.conf y lo dejamos con el siguiente
contenido:
# contenido de /etc/resolv.conf
search amigos.cu
nameserver 192.168.10.10

En el equipo donde tenemos instalado el servidor DNS podemos escribir:
search amigos.cu

En el contenido anterior, la declaración nameserver 127.0.0.1, indica que las consultas serán hechas al localhost.
Después que tengamos nuestro BIND correctamente configurado podemos realizar cualquier consulta DNS desde nuestro host, sea el propio
servidor bind9 u otro conectado a la red y que pertenezca a la misma subnet y tenga la misma máscara de red. Para conocer más acerca del
archivo ejecuten man resolv.conf.

Modificaciones al archivo /etc/bind/named.conf
Para limitar las consultas a nuestro BIND de forma que respondan solamente a nuestra subnet y evitar un ataque Spoofing, declaramos en el
archivo named.conf la Lista de Control de Acceso o ACL (Access Control List) y la denominamos mired. El archivonamed.conf debe quedar de
la forma siguiente:
// /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
//
// Los comentarios en español son nuestros
// Los originales los dejamos en inglés
// OJO con el copiar y pegar
// NO DEJEN ESPACIOS EN BLANCO AL FINAL DE CADA LINEA
//
// Lista de Control de Acceso:
// Permitirá consultas desde el dominio local y de nuestra subnet
// En el archivo incluido named.conf.options haremos referencia a ella.

acl mired {
127.0.0.0/8;

192.168.10.0/24;
};
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
// fin del archivo /etc/bind/named.conf

Comprobemos la configuración del BIND hasta ahora y reiniciemos el servicio:
named-checkconf -z
service bind9 restart

Modificaciones al archivo /etc/bind/named.conf.options
En la primera sección “options“, sólo declararemos los Forwarders, y quienes serán los que podrán consultar nuestro BIND. Luego declaramos
la Clave o key mediante la cual podemos controlar al bind9, y por último desde que host podemos controlarlo. Para conocer cual es la clave o
key, debemos hacer cat /etc/bind/rndc.key. Copiamos la salida y la pegamos en el archivo named.conf.options. Al final, nuestro archivo debe
quedar así:
// /etc/bind/named.conf.options

options {

// OJO CON EL COPIAR Y PEGAR, POR FAVOR...
// Directorio por defecto para ubicar nuestros archivos de Zonas

directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.

See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
//

0.0.0.0;

//

0.0.0.0;

// }
// Los Forwarders. No tengo mejor traducción
// Las direcciones son de servidores de ceniai.net.cu
// Si NO Tiene salida a la Internet NO es necesario
// declararlos, a menos que tenga una LAN más compleja
// con servidores DNS que actuen como Forwarders fuera
// del rango de direcciones IP de su subnet. En ese caso
// debe declarar las IP(s) de esos servidores.
// Las consultas a Forwarders son en Cascada.

forwarders {
169.158.128.136;
169.158.128.88;
};

// En una LAN bien configurada, TODAS las consultas DNS
// se deben hacer al servidor local DNS de esa LAN,
// NO a servidores externos a la LAN.

// Máxime cuando se tiene acceso a Internet,
// sea Nacional o Internacional. Para eso
// declaramos los Forwarders

auth-nxdomain no;

# conform to RFC1035

listen-on-v6 { any; };

// Proteger contra el spoofing
allow-query { mired; };
};

// Contenido del archivo /etc/bind/rndc-key
// obtenido mediante cat /etc/bind/rndc-key
// Recuerden cambiarlo si regeneramos la clave

key "rndc-key" {
algorithm hmac-md5;
secret "dlOFESXTp2wYLa86vQNU6w==";
};

// Desde cual host controlaremos y mediante cual clave
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
// fin archivo /etc/bind/named.conf.options

Comprobemos la configuración del BIND hasta ahora y reiniciemos el servicio:
named-checkconf -z

Hemos decidido incluir como // Comentarios los aspectos fundamentales que pueden servir de referencia para futuras consultas.
El hecho de declarar los Forwarders, convierte a nuestro servidor BIND Local en servidor Caché manteniendo su funcionalidad de Maestro
Primario. Cuando le preguntemos por un host o por un dominio externo, la respuesta -de ser positiva- la almacenará en su caché, de forma
que cuando le preguntemos nuevamente por el mismo host o por el mismo dominio externo, obtengamos una rápida respuesta al no consultar
nuevamente a DNSs externos.

Modificaciones al archivo /etc/bind/named.conf.local
En éste archivo declaramos las zonas locales de nuestro dominio. Debemos incluir las Zonas Directa e Inversa como mínimo. Recuerden que
en el archivo de configuración/etc/bind/named.conf.options declaramos en cual directorio alojaremos los archivos de las Zonas mediante la
directiva directory. Al final, el archivo debe quedar de la siguiente forma:
// /etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
// Los nombres de los archivos de cada zona, son a
// gusto del consumidor. Escogimos amigos.cu.hosts
// y 192.168.10.rev por que nos dan claridad de sus
// contenidos. No hay más misterio
//
// Los Nombres de las Zonas NO SON ARBITRARIOS

// y corresponderán al nombre de nuestro dominio
// y a la subnet de la LAN
// Zona Principal Maestra: tipo "Directa"
zone "amigos.cu" {
type master;
file "amigos.cu.hosts";
};
// Zona Principal Maestra: tipo "Inversa"
zone "10.168.192.in-addr.arpa" {
type master;
file "192.168.10.rev";
};
// Fin del archivo named.conf.local

Para comprobar la configuración del BIND hasta ahora:
named-checkconf -z

El comando anterior nos devolverá un error hasta tanto no existan los archivos de las zonas. Lo fundamental es que nos avisa de que las
Zonas declaradas en named.conf.local no serán cargadas, pues los archivos de registros DNS simplemente no existen, lo cual es cierto por
ahora. Podemos seguir adelante.
Reiniciemos el servicio para que se tenga en cuenta los cambios:

Como no queremos hacer muy largo cada post, abordaremos el tema de la creación de los archivos de las Zonas Locales en la próxima 4ta
parte. ¡Hasta entonces amigos!

DNS Maestro Primario para una LAN en Debian 6.0 (IV)
Los que hayan estudiado la 1era, 2da y 3era parte de esta serie se habrán dado cuenta de que hemos tratado de seguir un orden lógico y
hacia adelante de forma que no nos perdamos a la hora de instalar y configurar un BIND. Ahora abordaremos la creación de los archivos
de las Zonas Locales que son los que en definitiva contienen los registros de datos de nuestro dominio.

Creación del archivo de la Zona Principal Maestra del tipo “Directa” amigos.cu
En named.conf.options declaramos que los archivos de las Zonas estarán en el directorio/var/cache/bind. Tomaremos como plantilla para
la creación de nuestra zona el archivo/etc/bind/db.local. A nuestro gusto denominaremos el archivo amigos.cu.hosts:
cp /etc/bind/db.local /var/cache/bind/amigos.cu.hosts

Posteriormente editamos el archivo /var/cache/bind/amigos.cu.hosts el cual deberá quedar de la forma siguiente:
;/var/cache/bind/amigos.cu.hosts
;
; Archivo de datos del BIND para la Zona Maestra (Directa) amigos.cu
; OJO con el punto al final de cada FQDN
; OJO con dejar espacios en blanco al final de cada línea
; OJO con el Copia y Pega
; Este archivo es una base de datos
; Los comentarios Aquí se hacen después de un punto y coma (;)
; Los nombres de host pueden incluir caracteres del alfabeto inglés
; a-z, números 0-9 y el guión o "dash" "-"
; no se distinguen mayúsculas de minúsculas, aunque recomendamos
; el uso de minúsculas todo el tiempo
;
$TTL

1W

@

IN

SOA

amigos.cu. root.amigos.cu. (
2

; Serial

1W

; Refresh

1D

; Retry

4W

; Expire

1W )

; Negative Cache TTL

;
@

IN

NS

ns.amigos.cu.

@

IN

MX

10 mail.amigos.cu.

@

IN

TXT

"Amigos Cubanos. Su Red de Referencia"

ns

IN

A

192.168.10.10

gandalf

IN

A

192.168.10.1

fedex

IN

A

192.168.10.100

mail

IN

A

192.168.10.9

web

IN

A

192.168.10.20

www

IN

CNAME

web.amigos.cu.

Una explicación detallada de cada registro la puede encontrar en la documentación del paquete bind9-doc o en la Wiki del Grupo
Usuarios Tecnologías Libres. Nosotros explicaremos los registros siguientes:
$TTL 1W: Time To Live o tiempo de vida de la información. 1 semana.
@ IN SOA: Start of Authority o comienzo de la autoridad del dominio amigos.cu. y el administrador del dominio root.amigos.cu.
2 ; Serial: número de serie de la zona el cual se debe incrementar cada vez que la modifiquemos. Si hacemos varios cambios en una
misma ocasión, podemos incrementarlo una sola vez antes de reiniciar el BIND o recargar la zona mediante el comando rndc reload.

@ IN NS: nuestro BIND está en el host ns.amigos.cu. y es OBLIGATORIO que este host tenga un registro tipo A que lo identifique de
forma unívoca.
@ IN MX: el correo del dominio lo maneja el host mail.amigos.cu. con la prioridad más alta la cual corresponde al número más bajo
@ IN TXT: Comentario aclaratorio
www IN CNAME: alias www.amigos.cu. al host web.amigos.cu.
ns IN A 192.168.10.10: al host ns.amigos.cu. le corresponde la dirección IP 192.168.10.10.
Respetamos los valores por defecto de los tiempos de:

o
o
o
o
o

vida de la información
refrescar la información
re-intentar la conexión
expiración (caducidad) de la validez de la información
cache negativa o tiempo de almacenamiento de los DNS externos en la caché.

Antes de reiniciar el bind9, comprobemos la sintaxis de la zona creada:
named-checkzone amigos.cu /var/cache/bind/amigos.cu.hosts

La respuesta al comando deberá ser:
zone amigos.cu/IN: loaded serial 2
OK

Reiniciemos el servicio:

Comprobemos:
dig amigos.cu ns
dig maigos.cu mx
dig amigos.cu axfr
dig amigos.cu txt

Las respuestas en cada caso deben ser las correctas.
# dig amigos.cu ns
---;; ANSWER SECTION:
amigos.cu.

604800

IN

NS

ns.amigos.cu.

604800

IN

MX

10 mail.amigos.cu.

mail.amigos.cu.

604800

IN

A

192.168.10.9

ns.amigos.cu.

604800

IN

A

192.168.10.10

---# dig amigos.cu mx
amigos.cu.
------;; ADDITIONAL SECTION:

---# dig amigos.cu axfr
; <<>> DiG 9.7.2-P3 <<>> amigos.cu axfr
;; global options: +cmd
amigos.cu.

604800

IN

SOA

amigos.cu. root.amigos.cu. 2 604800 86400 2419200 604800

amigos.cu.

604800

IN

NS

ns.amigos.cu.

amigos.cu.

604800

IN

MX

10 mail.amigos.cu.

amigos.cu.

604800

IN

TXT


fedex.amigos.cu.

604800

IN

A

192.168.1.100

gandalf.amigos.cu.

604800

IN

A

192.168.10.1

mail.amigos.cu.

604800

IN

A

192.168.10.9

ns.amigos.cu.

604800

IN

A

192.168.10.10

web.amigos.cu.

604800

IN

A

192.168.10.20

www.amigos.cu.

604800

IN

CNAME

web.amigos.cu.

IN

SOA

amigos.cu. root.amigos.cu. 2 604800 86400 2419200 604800

TXT


amigos.cu.

604800

;; Query time: 0 msec
;; SERVER: 192.168.10.10#53(192.168.10.10)
;; WHEN: Fri Jan

4 16:46:01 2013

;; XFR size: 11 records (messages 1, bytes 307)
# dig amigos.cu txt
amigos.cu.

604800

IN

----

Observen en las salidas anteriores como responde a nuestra consulta en la sección “ANSWER SECTION:”. Además, nos dice que la
Autoridad, como se indica en el registro SOA (AUTHORITY SECCTION:) y que responde a la consulta hecha al dominio amigos.cu., la
tiene el host ns.amigos.cu., tal y como lo declaramos en el archivo de la zona amigos.cu.hosts
Cuando hagamos cambios en las Zona Directa y/o en la Inversa, no será necesario reiniciar el servidor. Sólo necesitaremos aumentar el
número de serie “Serial” en uno, y recargar las zonas mediante el comando rndc reload.
Ahhh, ¿Cómo se crea y mantiene una Zona Inversa? Lo veremos en el 5to y último capítulo. Hasta entonces, amigos!

DNS Maestro Primario para una LAN en Debian 6.0 (V) y final
Los que siguieron la 1era, 2da, 3era y 4ta parte de éste artículo y las consultas hechas a su BIND devolvieron resultados
satisfactorios, ya son expertos en el tema.:-) Y sin más dilación entremos en la última parte:
Creación del archivo de la Zona Principal Maestra del tipo “Inversa” 10.168.192.in-addr.arpa
Solución de problemas
Resumen

Creación del archivo de la Zona Principal Maestra del tipo “Inversa”
10.168.192.in-addr.arpa
El nombre de la zona se las trae, ¿no?. Y es que las Zonas Inversas son obligatorias para tener una resolución de
nombres correcta acorde a las normas de Internet. No nos queda más remedio que crear la correspondiente a nuestro
dominio. Para ello usamos como plantilla el archivo /etc/bind/db.127:
cp /etc/bind/db.127 /var/cache/bind/192.168.10.rev

Editamos el archivo /var/cache/bind/192.168.10.rev y lo dejamos así:
; /var/cache/bind/192.168.10.rev
;
; BIND reverse data file for master zone 10.168.192.in-addr.arpa
; Archivos de datos del BIND para la Zona Maestra (Inversa) 10.168.192.in-addr.arpa
;
$TTL

604800

@

IN

SOA

ns.amigos.cu. root.amigos.cu. (
2

; Serial

604800

; Refresh

86400

; Retry

2419200
604800 )

; Expire
; Negative Cache TTL

;
@

IN

NS

ns.

10

IN

PTR

ns.amigos.cu.

1

IN

PTR

gandalf.amigos.cu.

9

IN

PTR

mail.amigos.cu.

20

IN

PTR

web.amigos.cu.

100

IN

PTR

fedex.amigos.cu.

; podemos escribir también la dirección IP completa. Ej:
; 192.168.10.1

IN

PTR

gandalf.amigos.cu.

Observen como en éste caso hemos dejado los tiempos en segundos tal y como se crea por defecto cuando se
instala el bind9. Funciona igual. Son los mismos tiempos que los indicados en el archivo amigos.cu.host. Ante la
duda, compruebe.
Observen además que sólo declaramos los registros inversos de los hosts que tienen una IP asignada o “real” en
nuestra LAN, y que la identifica de forma unívoca.
Recuerden actualizar el archivo de la Zona Inversa con TODAS las direcciones IP correctas declaradas en la Zona
Directa.

Recuerden incrementar el Número de Serie de la Zona cada vez que modifiquen el archivo y antes de reiniciar el
BIND.

Comprobemos la zona recién creada:
named-checkzone 10.168.192.in-addr.arpa /var/cache/bind/192.168.10.rev

Comprobamos la configuración:
named-checkconf -z
named-checkconf -p

Si todo salió OK, reiniciamos el servicio:

En lo adelante, cada vez que modifiquemos los archivos de las zonas, sólo debemos ejecutar:
rndc reload

Para eso declaramos la clave en /etc/bind/named.conf.options, ¿no?

Solución de problemas
Muy importante es el correcto contenido del archivo /etc/resolv.conf como ya vimos en capítulo anterior. Recuerden
indicar en él al menos lo siguiente:
search amigos.cu

Comando dig del paquete dnsutils. En una consola, teclee los comandos precedidos por #:
# dig -x 127.0.0.1
.....
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa.

604800

IN

PTR

localhost.

....
# dig -x 192.168.10.9
....
;; ANSWER SECTION:
9.10.168.192.in-addr.arpa. 604800 IN

PTR

mail.amigos.cu.

....
# host gandalf
gandalf.amigos.cu has address 192.168.10.1
# host gandalf.amigos.cu
gandalf.amigos.cu has address 192.168.10.1
# dig gandalf
; <<>> DiG 9.7.2-P3 <<>> gandalf
;; global options: +cmd
;; connection timed out; no servers could be reached
# dig gandalf.amigos.cu
....
;; ANSWER SECTION:
gandalf.amigos.cu.
....

604800

IN

A

192.168.10.1

Sí tienen salida a la Internet Cubana o Global, y los Forwarders están correctamente declarados prueben:
# dig debian.org
....
;; QUESTION SECTION:
;debian.org.

IN

A

;; ANSWER SECTION:
debian.org.

3600

IN

A

86.59.118.148

debian.org.

3600

IN

A

128.31.0.51

....
# host bohemia.cu
bohemia.cu has address 190.6.81.130
# host yahoo.es
yahoo.es has address 77.238.178.122
yahoo.es has address 87.248.120.148
yahoo.es mail is handled by 10 mx-eu.mail.am0.yahoodns.net.
# dig -x 77.238.178.122
;; ANSWER SECTION:
122.178.238.77.in-addr.arpa. 429 IN

PTR

w2.rc.vip.ird.yahoo.com.

…y en general con otros dominios externos a nuestra LAN. Consulte y entérese de cosas interesantes de Internet.
Una de las mejores formas de comprobar el funcionamiento de un servidor bind9, y en general de cualquier otro servicio
instalado, es leyendo la salida de los Mensajes del Registro del Sistema mediante el comando tail -f
/var/log/syslog ejecutado como el usuarioroot.
Es muy interesante ver la salida de ese comando cuando le hacemos una pregunta a nuestro BIND local sobre un
dominio o host externo. En ese caso se nos puede presentar varios escenarios:
Sino tenemos acceso a Internet nuestra consulta será fallida.
Si tenemos acceso a Internet y NO tenemos declarados Forwarders, lo más probable es que no obtengamos una
respuesta.
Si tenemos acceso a Internet y tenemos declarados los Forwarders, obtendremos una respuesta ya que ellos se
encargarán de consultar al o a los servidores DNS que sean necesarios.

Si estamos trabajando en una LAN Cerrada en la cual es imposible de cualquier forma salir al exterior y no tenemos
Forwarders de ningún tipo, podemos eliminar los mensajes de búsqueda de los Servidores Raíces “vaciando” el
archivo /etc/bind/db.root. Para ello primero guardamos el archivo con otro nombre y luego borramos todo su contenido.
Luego comprobamos la configuración y reiniciamos el servicio:
cp /etc/bind/db.root /etc/bind/db.root.original
cp /dev/null /etc/bind/db.root
named-checkconf -z
named-checkconf -p

Resumen
Hasta aquí, colegas, una pequeña introducción al servicio DNS. Lo que hemos hecho hasta ahora nos puede servir
perfectamente para nuestra pequeña empresa. También para la casa si creamos máquinas virtuales con diferentes
sistemas operativos y diferentes direcciones IP, y no queremos referirnos a ellas por la IP sino por su nombre. Siempre
instalo un BIND en el host de mi casa para instalar, configurar y probar servicios que dependen fuertemente del servicio

DNS. Hago uso extensivo de Desktops y Servidores virtuales, y no me gusta mantener un archivo /etc/hosts en cada
una de las máquinas. Me equivoco demasiado.
Si nunca han instalado y configurado un BIND, por favor, no de desanime si al primer intento le sale algo mal y tenga
que empezar desde cero nuevamente. Recomendamos siempre en éstos casos partir de una instalación limpia. ¡Vale la
pena intentarlo!
Para aquellos que necesiten de una alta disponibilidad en el servicio de resolución de nombres, la cual se puede lograr
mediante la configuración de un servidor Maestro Secundario, recomendamos continúen con nosotros en la próxima
aventura: DNS Maestro Secundario para una LAN.

Dns en linux debían squeeze 6

Más contenido relacionado

La actualidad más candente

Similar a Dns en linux debían squeeze 6

Último

Dns en linux debían squeeze 6