El servidor de nombres y el nuevo 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, ni una predicación del pastor hcaste como
alguna "rana" me podría adjudicar, 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".
Tipos de Zonas:
Una zona en sí, consiste de esas partes anexas del arbol de
dominios para lo cuál un SN tine información completa y sobre la cuál
tiene sierta 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 unformación al maestro, usando el
protocolo DNS. Este conjunto de servidores (maestro, esclavos), puden ser
listados en los registros del SN en la zona padre y constituirán
una delagación. Este conjunto de servidores deben indicarse en 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) 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
del SN maestro.
Servidores:
Un SN puede ser maestro para algunas zonas y esclavos para otras,
o puede ser solo maestro, o solo esclavo, o no ser jerarquico y reponder
preguntas via su "cache". Ambos servidores Mestro Esclavos etan
autorizados 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 usas 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.
Bueno después de esta informacón básica, daré un ejemplo básico de NS de
solo cache.
En el archivo /etc/name.conf
acl interna {192.168.4.0/24, 192.168.7.0/24; }; //access control list
options{
directory "/var/name"; //directório de laburo
pid-file "/var/run/named.pid"; //para los que usan RH.
allow-query {interna; }; //quienes pueden preguntar.
};
zone "." {
type hint;
file "cahe.local";
}; //idéntico formato al BIND 8.2.2p5, se puede usar el dig
zone 0.0.127.in-addr.arpa{
type master; //Zona maestra el localhost!
file "local";
notify no; //no tiene esclavos a quien actualizar
};
Luego el archivo "local" será (similar al bind 8.2.2p5)
$TTL 300 //Ojo tiempo de vida 5 minutos!!!
@ IN SOA cosa.intranet.ar. root.cosa.intranet.ar. (
7919992 ;serie
36000 ;refresco por 100 horas
7200 ;reintento por 2 horas
3600000 ;expira en 1000 horas
2419200 );minimo 1 mes
IN NS cosa.intranet.ar. //ojo con los puntos!!
1 IN PTR localhost.
Creo que con estos datos para los que tiene conexión a internet basta,
pero como ejemplo de zonas maestras y esclavas es:
options{
directory "/var/name"; //directório de laburo
pid-file "/var/run/named.pid"; //para los que usan RH.
allow-query {any; }; //quienes pueden preguntar.
};
zone "." {
type hint;
file "cahe.local";
}; //idéntico formato al BIND 8.2.2p5, se puede usar el dig
zone 0.0.127.in-addr.arpa{
type master; //Zona maestra el localhost!
file "local";
notify no; //no tiene esclavos a quien actualizar
};
zone ejemplo.com.ar{
type master;
file "maestro";
allow-transfer { 192.168.4.14,
192.168.5.53;}; //Servidores esclavos autorizados.
};
zone cosa.ejemplo.com.ar{
type slave;
file "esclavo";
masters{192.168.1.1;}; //Quien es el maestro autorizado
};
Además de las clásicas herramienta de diagnostico, 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 127.0.0.1 allow {local;} keys {rndc_keys;};
};
key rndc_keys {
algorithm "hmac-md5";
secret
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
y en el archivo /etc/rndc.conf
key rndc_key {
algorithm "hmac-md5";
secret
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
options {
default-server 127.0.0.1;
default-key rndc_key;
};
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 esto todavía no
se como implementarlo, solo conosco IPv4. Buaaa! Pero eso ya vendrá luego.
Dr. Horacio Castellini, Dpto de F'isica, Facultad de Ingenier'ia,
Ciencias Exactas y Agrimensura, Pellegrini 250, 2000 Rosario
Argentina, Usuario Linux Registrado #53602
Correo-e:[EMAIL PROTECTED] ICQ: 52244442
