Un servidor de nombres cumple dos roles: ayudar a los resolvers locales a resolver nombres y a servir con autoridad como primario y secundario de algunos dominios. En las organizaciones muy grandes, puede ser una buena idea separar estos dos roles, teniendo servidores para resolver y servidores para el dominio local. Tenerlos juntos es también razonable en todo caso, porque la mayoría de las consultas son dentro del dominio local, que típicamente servimos.
Para funcionar bien, debemos entonces tener un servidor de nombres (recomendamos correr siempre la última versión sacada de Internet) y configurarlo de modo que ubique los servidores raíz, que tenga los dominios para los que es primario y conozca para cuales debe actuar como secundario. El archivo que contiene toda la información sobre un dominio se conoce como una zona. Dentro de la zona se especifican valores asociados al dominio propiamente tal (ver sección 4.1.1), los servidores de nombres del dominio (records NS), los nombres de las máquinas que existen bajo él y su dirección IP (records A), los nombres de sus sub-dominios (si existen) y sus servidores de nombres (records NS), servidores de correo (records MX), etc. Un servidor de nombres que tiene autoridad sobre un dominio debe tener localmente una copia de la zona que lo define: si es primario tiene la versión modificable, si es secundario debe tener una copia obtenida desde el primario.
Aparte del servidor propiamente tal (típicamente llamado named), existe otro programa que se encarga de transferir las zonas que corresponden a los dominios de los cuales somos secundarios (y que es invocado desde named cada vez que es necesario) conocido como named-xfer. Al ser otro programa, permite que uno lo ejecute a mano para probar transferencias de zona desde un servidor dado.
La lista de los dominios de los que somos primarios, la de los secundarios
y información inicial de los servidores raíz
se configura en un archivo inicial (en Unix; en
Windows y NT por supuesto que es un menú). El archivo inicial se le
entrega de parámetro al servidor de nombres y es algo como lo que sigue
:
; ; ns.boot : boot file for name server ns.dcc.uchile.cl ; directory /usr/etc/named cache . ns.ca primary cl cl.zone primary dcc.uchile.cl dcc.uchile.cl.zone primary srcei.cl srcei.cl.zone primary 4.83.146.in-addr.arpa 4.83.146.revzone primary 0.0.127.in-addr.arpa ns.local ; ; Secundarios para todos los subdominios de .CL ; secondary utfsm.cl 146.83.198.3 back/utfsm.zone secondary rdc.cl 146.155.30.25 146.155.1.155 back/rdc.zone ...Ahí podemos ver que el servidor tiene sus archivos de configuración en /usr/etc/named, que la lista de servidores raíz está en sunsite.ca y que el servidor es primario de los dominios cl, dcc.uchile.cl, etc. La zona donde se detallan las máquinas del dominio dcc.uchile.cl está en el archivo dcc.uchile.cl.zone.
Luego el servidor es secundario de otros dominios, como utfsm.cl, donde aparece la dirección IP de un servidor de nombres de donde obtener la información y un archivo donde dejarlo. Es buena idea tener un directorio para los secundarios separado de los primarios, puesto que los secundarios podemos borrarlos sin problemas pero los primarios no.
También es primario para algunas zonas inversas (ver sección 4.2) como 4.83.146.in-addr.arpa.
Todos estos archivos configuran completamente al servidor, como se ve en la figura 2.
Figure: Archivos de configuración
Algunas recomendaciones sobre la configuración del servicio de nombres:
Es vital no incluir información sobre los dominios superiores, puesto que en caso de cambio esto divulgará información falsa a la red. Los servidores modernos ignoran esta información, pero viejas versiones aún existen.
La zona de un dominio comienza con un record SOA (Start Of Authority) que define varios parámetros importantes para toda la zona. Luego listamos records que están todos dentro de la zona. Hay que tener cuidado con los nombres de dominio absolutos que se colocan en una zona, puesto que siempre el servidor local los interpreta relativos a la zona. Para evitar errores, se debe agregar un punto al final del nombre absoluto (por ejemplo dcc.uchile.cl.) y solo usar nombres relativos a la zona para el resto de la información.
Los comentarios en la zona van a partir de un punto y coma (;) hasta el fin de línea. Los records tiene típicamente un prefijo IN (de Internet). Un ejemplo de definición del archivo que representa al subdominio dcc.uchile.cl se entrega en anexo.
Cada dominio tiene un descriptor global asociado, que es el record SOA con el cual comienza la zona. Este record tiene 7 campos asociados: el nombre del servidor primario, la dirección electrónica del responsable del dominio (se recomienda usar el nombre de usuario de la persona responsable), y cinco valores numéricos que definen diversos valores y timeouts (en segundos) del dominio. Estos valores pueden generar mayor o menor tráfico y también demorar más o menos los cambios en propagarse por la Internet. Con algunos valores patológicos, también pueden generar errores como expiración del dominio.
Los campos son:
Este número corresponde a la versión del archivo. La idea es que sea monótonamente creciente. Cada vez que se hace un cambio, debe incrementarse este número, lo que indica a los secundarios que es hora de copiar una nueva versión desde el primario. Una buena idea es mantener la fecha codificada en ese número. Para ser tolerante al año 2000, sugerimos una codificación: AAAAMMDDHH (año,mes,día,hora) que además permite ver cuánto se demoran los secundarios en tener una nueva versión y saber cuando se hizo un cambio.
Este número indica cada cuanto tiempo (en segundos) los secundarios deben chequear con el primario si el serial ha cambiado. Esto define a qué velocidad se difunden los cambios del dominio.
Si en un secundario, el chequeo con el primario no se pudo hacer (error de conectividad u otro), este contador indica cada cuanto hay que reintentarlo.
Si un secundario no logra contactarse más con el primario, sigue respondiendo con autoridad por el dominio durante todo este intervalo (en segundos). Es muy importante que este valor sea alto, puesto que una vez que se sobrepasa, el secundario da la zona por expirada y no responde más por ella. Esto puede generar errores del tipo "host not found" que son más graves que errores de conectividad. Por ejemplo, el mail se devuelve con un error, en vez de encolarse en espera que el servidor vuelva.
Este valor indica cuanto tiempo un servidor cualquiera (no primario ni secundario) puede recordar la información de esta zona y responder (sin autoridad) con ella a sus clientes. Es razonable que sea alto, pero no tanto porque retrasa las modificaciones en difundirse en todas partes (pero sólo afecta la modificación y la eliminación de campos, el agregar información se difunde según el valor del refresh).
En la tabla siguiente entregamos nuestra recomendación de valores, que no son obligatorios. Sin embargo, siempre hay que recordar que Expire > TTL > Refresh > Retry.
Por ejemplo:
;
; dcc.uchile.cl.zone : Authoritative data for dcc.uchile.cl
;
@ IN SOA dcc.uchile.cl. hostmaster.dcc.uchile.cl. (
1993050709 ;Serial
43200 ;Refresh (12 horas)
7200 ;Retry (2 horas)
2592000 ;Expire (30 dias)
129600) ;Minimum (2 dias)
Es buena idea comenzar la zona con la lista de los servidores de nombres
del dominio. Los servidores deben ser a los menos dos (por tolerancia a
fallas) y ubicados en redes y lugares distantes. En general es buena idea
tener otra institución con la cual acordar que ellos sean secundarios
de nuestros dominios a cambio de nosotros ser secundarios de ellos.
Estos servidores de nombres deben ir listados por nombre de dominio,
sin dirección IP. No es cosa de colocar el nombre de un servidor de nombres
conocido y esperar que funcione, ese servidor debe estar configurado como
secundario para este dominio, lo que debe ser acordado previamente con él.
Por supuesto, el nombre del servidor primario también debe incluirse.
Por ejemplo:
IN NS ns.dcc.uchile.cl.
IN NS inti.inf.utfsm.cl.
La idea de base de la zona es proveer la lista de nombres en el dominio y sus direcciones IP. Para eso son los records A, donde listo todas mis máquinas. Si tengo máquinas con más de una dirección IP, repito el nombre. Si tengo máquinas con más de un nombre, repito la dirección IP. Es buena idea incluir nombres para nuestros routers, en algunos casos incluso es bueno asignarles nombres distintos a cada interfaz.
Por ejemplo:
anakena IN A 192.80.24.1 ftp IN A 192.80.24.1 tortel IN A 192.80.24.2 tortel IN A 146.83.4.10
Si el dominio tiene sub-dominios, en la zona del dominio se debe definir su existencia y delegarlo a sus servidores de nombres. Eso es todo lo que yo tengo derecho a decir sobre el sub-dominio. Por ejemplo:
alumnos IN NS ns.dcc.uchile.cl.
IN NS inti.inf.utfsm.cl.
Los nombres de los servidores tienen que tener un record A asociado en su dominio. No pueden ser un CNAME (ver más adelante).
Aparte de la lista de los nombres con sus direcciones IP, es importante definir los records MX asociados. Éstos permiten que el correo dirigido a cualquier máquina del dominio le lleguen a una máquina de correo principal, la que después se encarga de distribuirlo internamente. De esta forma no todas las máquinas tienen que correr un mailer bien configurado y basta con mantener los Mail Exchangers solamente.
Por ejemplo:
tortel IN A 146.83.4.11
IN MX 50 mailer.dcc.uchile.cl.
Junto con el nombre de la máquina que recibe el correo, va una prioridad, lo que permite tener varios records MX, con distintas prioridades. Los servidores de correo en Internet, al tener correo para una máquina, antes de pedir una dirección IP para enviarle el correo directamente, pide los records MX que existen para ella.
Este record acepta el nombre * (asterisco) que implementa un Mail Exchanger para toda máquina de este dominio.
Es mejor evitar el uso de estos records. Permite definir aliases para máquinas, pero no todos los resolvers los manejan bien. Es mucho mejor definir varios nombres que dan la misma dirección IP, por ejemplo:
tortel IN A 146.83.4.11 www IN A 146.83.4.11 mail IN A 146.83.4.11 ns IN A 146.83.4.11
Son records que permiten poner información sobre el nombre, tipo de máquina, servicios que provee, etc. Nadie los usa y ocupan espacio en las zonas (que deben transferirse a los secundarios), por lo que recomiendo no utilizarlos.
El DNS también sirve para hacer la traducción inversa, es decir de dirección IP a nombre (esto es usado más que nada por razones de seguridad, para verificar que una máquina es quien dice ser). Estos servidores se configuran como servicio de nombres de un dominio ficticio, compuesto por la dirección IP invertida y terminado por el dominio IN-ADDR.ARPA. Por ejemplo, el servidor inverso de la red clase C 200.0.66.0 es:
66.0.200.in-addr.arpa.
y adentro se pone el número dentro de la red y el nombre de la máquina con un record de tipo PTR. Un ejemplo de configuración se entrega en anexo.
Una vez que localmente puedo invertir los números IP (esto se prueba con la rutina de la biblioteca C gethostbyaddr), debo registrar oficialmente el servidor inverso para que sea utilizado en Internet. Si mi red IP fue otorgada por mi proveedor, típicamente tengo que pedirle a él que me delegue el inverso. Si es una sub-red que no va en borde de un byte es más complicado, puesto la separación sólo se puede hacer en esos segmentos. Por ello, es muy razonable exigir bloques de direcciones que por lo menos sean una clase C (un prefijo de tres bytes).
Si la dirección IP es de las portables asignadas por el Internic, se le debe pedir directamente a ellos que lo activen, y se envía un mail a hostmaster@internic.net con un formulario que se extrae de allí, para pedir registrar zonas inversas.