El servidor de nombres y el BIND 9.1

Hola en este artículo propongo un resumen de mis experiencia en poner a punto el nuevo BIND 9.1 de ISC, el cuál me obligó a leer varios RFC, esto no pretende ser un tutorial, sino creo que con esto trato de poner de público conocimiento información que de otra forma es costosa hallar. Y en si como buen amante de la investigación científica, es todo un desafío.

 
 

Algunas definiciones:

Servidor de Nombres (SN):

Es un programa que almacena información sobre los recursos de nombres y responde a las preguntas provenientes de los programas clientes llamados "resolutores". Es decir, la función básica del SN es proveer información bajo demanda sobre los objetos de la red. Según la política actuál, la red puede dividirse en un arbol jerárquico posicional dirigido, lo que permite abstracciones operacionales. Cada nodo del arbol, llamado dominio, tiene una etiqueta y el nombre de un dominio no es mas que la concatenación de todas las etiquetas partiendo de la raiz hasta el dominio actual. Esto es escrito como una cadena de palabras cuyo separador el punto '.', una etiqueta require ser única dentro de su dominio. El espacio de nombres entero es particionado en "zonas", cada una empieza en un dominio y finaliza al final de la cadena o donde tiene sentido el comienzo de otra zona. Por ejemplo:

cosa.ejemplo.com.ar

"ar" representa una zona y es el dominio de mayor nivel (raiz), "com" representa un subdominio y otra zona, y por último "cosa.ejemplo" puede representar el "hostname.domainname" de la máquina.

Tipos de Zonas:

Una zona en sí, consiste de esas partes anexas del arbol de dominios para lo cuál un SN tiene información completa y sobre la cuál tiene cierta autoridad. Cada zona tine un SN maestro, el cuál carga los contenidos de la zona de algún archivo local y habrá una serie de SN esclavos, los cuales demandarán información al maestro, usando el protocolo TCP ó UDP (puerto 53 en ambos casos).  El conjunto de servidores deben indicarse con máxima prioridad ("top level") en los archivos de la zona, usualmente bajo "@" lo cuál indica la raiz de la zona. Cualquier lista de servidores en el SN debe configurarse como autorizado (authoritative en inglés) para la zona. Es decir un servidor está autorizado para una zona cuando fue configurado a responder preguntas bajo una zona que tiene influencia, esto se consigue activando el bit "Respuesta Autorizada" (Authoritative Answer) o AA en los paquetes de confirmación y un servidor puede estar autorizado para más de una zona. Los datos autorizados para una zona lo componen los Registros de Recursos ó "RR" anexados a todos los nodos, desde el de máxima prioridad hacia abajo. Para finalizar una zona es "tipo maestra" o "esclava" se referirá al tipo de respuesta autorizada por el servidor. Es decir: la zona "ejemplo.com.ar" es maestra de "cosa.ejemplo.com.ar", si fué indicada en los archivos de configuración sobre respuestas autorizados el SN maestro.

Servidores:

Un SN puede ser maestro para algunas zonas y esclavos para otras, puede ser solo maestro, o solo esclavo, o no ser jerarquico y reponder reguntas via su "cache". Ambos servidores, Maestro y Esclavo, etan utorizados para manipular una zona. Todos los servidores guardan sus registros en sus caches, hasta la expiración de la información, esto lo determina el campo "TTL" (time to life) para el cuál permanecen intactos los RR (datos asociados con los nombres en el arbol jerarquico).

Servidor Maestro:

Corresponde a la última fuente de información de un dominio, es un servidor autorizado configurado a ser la fuente de transferencia para uno o más servidores y obtine los datos solo de sus archivos en disco.

Servidor Esclavo:

Es un servidor autorizado (por el maestro) que usa información proveniente de algún maestro para recobrar los datos de zona. Opcionalmente, el SN esclavo obtiene los datos de zona desde algún cache.

Servidores de solo "cache":

La información es guardada en sus cache y es usada hasta que esta expira y es vuelta a recuperar por demanda. Un servidor de solo cache es un servidor que no está autorizado para operar en una zona. Estos servidores preguntan y responden a otros servidores, los cuales tiene autorizaciones, sobre la información requerida.

Servidores remitidos (Forwarded server):

En lugar de interactuar con el NS para la raiz y otros dominios, un servidor remitido siempre remite preguntas que no puede satisfacer de sus datos autorizados o caches a las listas arregladas de otros servidores. Las preguntas remitidas son más conocidas como "recursive queries". El proceso de remito finaliza cuando la respuesta es hallada o la lista de servidores finaliza. Un esenario típico puede ser un número de SN internos y un cortafuegos para internet. Los servidores no pueden pasar los paquetes a travez del cortafuegos, debiendolos remitirlos al servidor autorizado a cruzar el cortafuegos.

Servidor Sigiloso (Sthealth Server):

Es un servidor que responde autorizadamante para una zona, pero no está en la lista de servidores de la zona. Se los usa como mecanismo de distribución de información para la zona, guardando una copia local para rápida respuesta cuando el servidor "offial" haya caido.
 

Un Paradigma

Bueno después de esta informacón básica, daré un ejemplo básico de NS de red interna con cache. En el archivo /etc/name.conf podemos escribir este conjunto de instrucciones

// generated by named-bootconf.pl

logging{
    channel named_log {
    file "/var/log/named.log";
    print-time yes;
    print-category yes;
    print-severity yes;
    severity info;
};
category default {named_log; default_debug; };
};
acl interno{192.168.1.0/24;};
acl local{127.0.0.1;};
controls {
inet 192.168.1.4 allow {interno;} keys {rndc;};
};
// Permite el uso del comando rndc para cotrolar el demonio por el puerto 953.
key rndc {
    algorithm hmac-md5;
    secret "7Gv4xKlVHIgNbQcomn6jYQ==";
};
options {
    directory "/var/named";
    pid-file "/var/run/named.pid";
    auth-nxdomain yes;
    allow-query { any; };
    recursion yes;
};

// Definimos el CACHE
zone "." {
    type hint;
    file "cache";
};

// Resolución inversa del área local
zone "0.0.127.IN-ADDR.ARPA" {
    type master;
    file "named.local";
    notify no;
};

// Zona maestra de nuestra red local tipo C
zone "intranet.ar" {
    type master;
    file "named.hosts";
    allow-transfer{interno; };
};

//Resolución inversa de nuestra red local
zone "1.168.192.IN-ADDR.ARPA" {
    type master;
    file "named.rev";
    allow-transfer{interno; };
};

Los archivos named.ca, named.local, named.host y named.rev tendrán la  mismas reglas para su configuración que en bind 8.2.2p5. Como ejemplos mustro los siguientes listados:

named.ca

;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
 

named.hosts

;/var/named/named.hosts
;Maquinas locales de red
;El origen es intranet.ar
$TTL 604800
@       IN      SOA     clara.intranet.ar. root.clara.intranet.ar. (
                        2003031002      ;serie
                        28800   ;refresco por dia
                        7200    ;reintento por 2 horas
                        604800  ;expira en 42 dias
                        86400   ) ;minimo ttl negaticoa
;Servidores que tiene autoridad sobre el dominio
@       IN      NS      clara.intranet.ar.
;Correo controlado por zona, donde pedir info dns
@       IN      MX      1       clara.intranet.ar.
;direccion loopback
localhost       IN      A       127.0.0.1
;Nuestra red
oscura          IN      A       192.168.1.11
clara           IN      A       192.168.1.4
roja            IN      A       192.168.1.20
smtp            IN      A       192.168.1.4
news            IN      CNAME   clara
www             IN      CNAME   clara
;
@       TXT     "clara.intranet.ar Servidor de Nombres"
@       HINFO   "Linux" "Celeron 686"

named.local

;/var/named/named.local
;traduccio'n inversa para 127.0.0
;El origen es 0.0.127.in-addr.arpa.
$TTL 604800
@       IN      SOA     clara.intranet.ar. root.clara.intranet.ar. (
                        2003031001 ;serie
                        36000   ;refresco por 100 horas
                        7200    ;reintento por 2 horas
                        3600000 ;expira en 1000 horas
                        2419200 );minimo 1 mes
;Servidor autoritario de zona
@       IN      NS      clara.intranet.ar.
1       IN      PTR     localhost.

named.rev

;/var/named/named.rev
;Traduccio'n inversa de n'umeros IP
;El origen es 1.168.192.in-addr.arpa.
$TTL 604800
@       IN      SOA     clara.intranet.ar. root.clara.intanet.ar. (
                        2003031001      ;serie
                        10800   ;refresco por 3 horas
                        3600    ;reintento por 1 hora
                        604800  ;expira en 1 semana
                        86400   );minimo un dia
; Servidor autoritario de zona
@       IN      NS      clara.intranet.ar.
;nuestra red
4       IN      PTR     clara.intranet.ar.
11      IN      PTR     oscura.intranet.ar.
20      IN      PTR     roja.intranet.ar.
 
 

Además de las clásicas herramienta , dig, host, nslookup, named-checkconf y named-checkzone. El BIND 9.1 consta con un reemplazo del "ndc" el "rndc" que permite comandar al demonio "named" de forma remota por el puerto TCP 953, pero este tipo de comando se hace previa autenticación. Primero hay que decirle al named que atienda en dicho puerto para ello hay que colocar antes de "options" (top-level)

acl local{127.0.0.1;};

controls {
    inet 192.168.1.4 allow {interno;} keys {rndc;};
};
key rndc {
    algorithm hmac-md5;
    secret "7Gv4xKlVHIgNbQcomn6jYQ==";
};

y en el archivo /etc/rndc.conf (depende de cada distro la localización del archivo)

key rndc {

    algorithm "hmac-md5";
    secret "7Gv4xKlVHIgNbQcomn6jYQ==";
};
options {
    default-server clara.intranet.ar;
    default-key rndc;
};

Advertencia: Observe la congruencia entre las calves

La firma encriptada segun el algoritmo MD5 es generado por el programa "dnssec-keygen", pero también se puede usar firmas DSA. Esto no solo permite un control remoto del named sino que además es posible trasferir los RR via encriptada con los esclavos evitando los "espionajes". Basta con hacer dnssec-signzone -o maestro esclavo.
Otra caracteristica del BIND 9.1 es el uso de hiladas "threads" ya que el programa se parte en una hilada de procesos maestros-esclavos donde cada esclavo atiende solo una zona, cosa que no lo hace el Bind 8.2.2p5. Pero el detalle más interesante es que soporta IPv6, pero para ello habrá que esperar a que complete el resumen correspondiente a IPv6.

Horacio 1