4. Verificando la instalación

Casi cualquier problema relacionado con named que tenga su origen en la información proporcionada a través de los archivos de configuración puede ser diagnosticado a través de las utilerías de BIND y del registro que hace el mismo named en el system logger. A continuación veremos cómo lidiar con diversos problemas de configuración utilizando estas opciones.

4.1 Los mensajes de named

Todas las versiones de Unix cuentan con un registro de eventos o system logger que permite a las diversas aplicaciones que corren en el sistema registrar cualquier información que consideren pertinente en archivos especiales destinados a su revisión por parte del administrador del sistema. En SCO, Estos archivos se encuentran localizados en el directorio /usr/adm/, en Linux en /var/log y tienen nombres como messages o syslog. El demonio named registra su arranque, por ejemplo, mediante una línea similar a la siguiente:

Dec  7 10:53:25 master named[29338]: starting.  named 4.9.3-P1

Las lecturas a las bases de datos indicadadas en el archivo de arranque (named.boot) mediante una línea primary son registradas de la siguiente manera:

Dec  7 10:53:25 master named[29338]: primary zone "cfemex.com" loaded
(serial 97010201)

Las consultas a otros servidores de nombres para cargar zonas secundarias quedan registradas así:

Dec  7 10:53:25 master named[29338]: secondary zone "cfe.gob.mx" loaded 
(serial 96120300)

Finalmente, named marca el final de su arranque y su disposición a responder peticiones con una línea como la que sigue:

Dec  7 10:53:26 master named[29339]: Ready to answer queries.

Muchas anomalías pueden ser identificadas con sólo mirar los registros de named, entre ellas:

• Errores en la información contenida en los archivos de datos indicados en líneas primary. Generalmente se deben a una sintaxis incorrecta en una línea de asignación de IP. Es muy común también el error de asignar un alias (mediante CNAME) a una máquina cuyo IP no ha sido definido. Otro error común es olvidar que, a diferencia de otros tipos de registro, el registro MX utiliza un campo adicional, númerico, para indicar le preferencia de la máquina administradora de correo.
• Errores en la transferencia de información de un servidor primario a un servidor secundario. Estos errores pueden deberse a que el servidor primario no contestó la petición del servidor secundario porque estaba caído o porque simplemente no estaba corriendo el software BIND, o sea named. También es posible que la información recibida del servidor primario contuviera errores.
• Un archivo de caché incorrecto o faltante. Este error es generalmente fácil de resolver. Basta poner en el directorio referenciado en la línea directory del archivo named.boot un archivo de caché correcto.

Es posible recibir más información acerca de la operación del demonio named enviandole señales a través del comando kill de Unix, que se utiliza de la siguiente manera:

kill -s señal pid

donde pid es el número de proceso del demonio named actualmente corriendo, mismo que puede ser consultado mediante un comando como ps -ax. Las señales que se le pueden enviar a named, varias muy útiles en el diagnóstico de errores, son las siguientes:

SIGHUP

Causa que el servidor relea el archivo named.boot y recargue las bases de datos.

SIGINT

Provoca un vaciado de los datos cargados por named en el archivo /var/tmp/named_dump.db.

SIGIOT

Provoca el vaciado de estadísticas en el archivo /var/tmp/named.stats.

SIGSYS

Provoca el vaciado de información destinada al análisis del desempeño de named} en raw{/var/tmp (llamadas al sistema como fork, chdir o exit).

SIGTERM

Provoca el vaciado de las bases de datos primarias y secundarios, esto con el find de guardar la información modificada cuando el demonio termina su operación.

SIGUSR1

Activa el modo de depuración. Cada envío de esta señal incrementa el nivel de depuración de named.

SIGUSR2

Desactiva completamente el modo de depuración.

SIGWINCH

Activa o desactiva el registro en el system logger de todas las consultas a named.

Información más detallada acerca del uso de señales para controlar a named puede encontrarse en la hoja de manual del programa (man named).

El paquete de instalación de BIND para Linux RedHat contiene un utilería interesante porque envuelve el uso de estas señales y proporciona al usuario una interfaz más sencilla. Esta utilería se llama ndc, por named control, y se utiliza de la siguiente manera:

ndc (status|dumpdb|reload|stats|trace|notrace|querylog|start|stop|restart)

Como puede observarse, las opciones que se le pueden indicar a ndc corresponden a las señales descritas con anterioridad. en Linux RedHat, ndc cuenta con una página de manual propia, al igual que named.

4.2 Usando nslookup

Otra utilería sumamente útil que se utiliza comunmente para verificar la instalación de un servidor de nombres es nslookup. Esta herramienta puede utilizarse interactivamente o como un comando cualquiera. Esto último se hace de la siguiente manera:

nslookup maquina

nslookup cuestionará al servidor de nombres especificado en el archivo /etc/resolv.conf acerca de la máquina especificada y devolvera su dirección IP.

En modo interactivo, nslookup puede hacer mucho más que sólo encontrar direcciones IP: puede preguntarle al servidor de nombres por cualquier clase de registros (no sólo A) e incluso puede mostrar la información referente a una zona entera.

Para entrar en el modo interactivo sólo es necesario teclear nslookup. El programa contestará con un signo de menor que ``>'' indicando que está listo para ejecutar comandos. Es posible entonces indicarle cualquier nombre de dominio y nslookup buscará por registros de tipo A. Para cambiar el tipo de registro que queremos encontrar es posible indicar set type=tipo, donde tipo puede ser cualquiera de los que ya mencionamos en secciones anteriores o incluso any, que indica cualquier tipo de registro.

La siguiente sesión, que se incluye como ejemplo, muestra cómo es posible encontrar información no sólo acerca de máquinas (direcciones IP), sino acerca de dominios (cuáles son sus servidores de nombres o de correo).

$ nslookup 
Default Server:  master.cfemex.com
Address:  159.16.10.8

> sunsite.unc.edu
Server:  master.cfemex.com
Address:  159.16.10.8

Non-authoritative answer:
Name:    sunsite.unc.edu
Address:  152.2.254.81

> unc.edu
Server:  master.cfemex.com
Address:  159.16.10.8

*** No address (A) records available for unc.edu
> set type=SOA
> unc.edu
Server:  master.cfemex.com
Address:  159.16.10.8

unc.edu
        origin = ns.unc.edu
        mail addr = host-reg.ns.unc.edu
        serial = 970107010
        refresh = 14400 (4 hours)
        retry   = 3600 (1 hour)
        expire  = 1209600 (14 days)
        minimum ttl = 86400 (1 day)
unc.edu nameserver = ns.unc.edu
unc.edu nameserver = ns2.unc.edu
unc.edu nameserver = ncnoc.ncren.net
ns.unc.edu      internet address = 152.2.21.1
ns2.unc.edu     internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1      
> exit
$