29.11. DNS

Enviado por Chern Lee.

29.11.1. Resumen

FreeBSD utiliza por defecto una versión de BIND (Berkeley Internet Name Domain) que proporciona la implementación más común del protocolo de DNS. DNS es el protocolo a través del cual los nombres de máquinas se asocian con direcciones IP y viceversa. Por ejemplo una consulta preguntando por www.FreeBSD.org recibe una respuesta con la dirección IP del servidor web del Proyecto FreeBSD, mientras que una pregunta sobre ftp.FreeBSD.org recibe como respuesta la dirección IP correspondiente al servidor de FTP. El proceso inverso sucede de una forma similar. Una pregunta relativa a una determinada dirección IP se resuelve al nombre de la máquina que la posee. No se necesita ejecutar un servidor de DNS para poder realizar consultas y búsquedas de DNS.

El DNS se coordina de forma distribuida a través de Internet utilizando un sistema en cierta forma complejo de servidores de nombres raíz autorizados y mediante otros servidores de nombres de menor escala que se encargan de replicar la información de dominios individuales con el objetivo de mejorar los tiempos de respuesta de búsquedas reiteradas de la misma información.

Este documento hace referencia a la versión estable BIND 8.X. BIND 9.X se puede instalar a través del port net/bind9.

El protocolo de DNS se encuentra definido en la RFC1034 y la RFC1035.

El Internet Software Consortium (www.isc.org) se encarga de de mantener el software de BIND.

29.11.2. Terminología

Para comprender este documento se deben definir los siguientes términos:

TérminoDefinición
DNS directo (Forward DNS)Asociación de nombres de máquinas con direcciones IP
OrigenSe refiere al dominio cubierto por un determinado fichero de zona
named, BIND, servidor de nombres (name server)Nombres típicos que hacen referencia al paquete servidor de nombres de BIND de FreeBSD
ResolverUn proceso del sistema que utilizan las aplicaciones para hacer preguntas al servidor de nombres.
DNS inverso (Reverse DNS)Lo contrario de lo que realiza el DNS directo; asocia direcciones IP con nombres de máquinas
Zona RaízEl comienzo de la jerarquía de zonas de Internet. Todas las zonas surgen a partir de una zona raíz de forma similar a como todos los directorios de un sistema de ficheros se encuentran a partir de un directorio raíz inicial.
ZonaUn dominio individual, subdominio o porción del DNS que se encuentra administrado por la misma autoridad.

Ejemplos de zonas:

  • . es la zona raíz

  • org. es una zona localizada bajo la zona raíz

  • ejemplo.org es una zona localizada bajo la zona org.

  • foo.ejemplo.org. es un subdominio o una zona ubicada bajo la zona ejemplo.org.

  • 1.2.3.in-addr.arpa es una zona que referencia a a todas las direcciones IP que se encuentran dentro del espacio de direcciones de 3.2.1.*.

Como se puede observar la parte más específica de una máquina aparece más a la izquierda. Por ejemplo ejemplo.org es más específico que org. y del mismo modo org. es más específico que la zona raíz. El formato de cada parte del nombre de la máquina es muy similar al formato de un sistema de ficheros: el directorio /dev se encuentra dentro del directorio raíz, y así sucesivamente.

29.11.3. Razones para ejecutar un servidor de nombres

Los servidores de nombres normalmente son de dos tipos: autoritarios y de cache.

Se necesita un servidor de nombres autoritario cuando:

  • uno quiere proporcionar información de DNS al resto del mundo respondiendo con información autoritaria a las consultas recibidas.

  • un dominio, por ejemplo ejemplo.org, está registrado y se necesita añadir nombres de máquinas bajo dicho dominio.

  • un bloque de direcciones IP necesita entradas de DNS inversas (de IP a nombre de máquina).

  • un servidor de nombres de backup, llamado esclavo, debe responder a consultas cuando el servidor primario se encuentre caído o inaccesible.

Se necesita un servidor caché cuando:

  • un servidor de DNS local puede responder más rápidamente de lo que se haría si se tuviera que preguntar al servidor de nombres externo.

  • se desea reducir el tráfico global de red (se ha llegado a comprobar que el tráfico de DNS supone un 5% o más del total del tráfico que circula por Internet).

Cuando se pregunta por www.FreeBSD.org el resolver normalmente pregunta al servidor de nombres del ISP de nivel superior y se encarga de recibir la respuesta. Si se utiliza un servidor de DNS caché local la pregunta sólo se dirige una única vez hacia el exterior. Dicha pregunta la realiza el servidor caché. Posteriores consultas sobre el mismo nombres son respondidas directamente por este servidor.

29.11.4. Cómo funciona

En FreeBSD el dæmon de BIND se denomina named por razones obvias.

FicheroDescripción
namedEl dæmon de BIND
ndcEl programa de control del dæmon
/etc/namedbEl directorio donde se almacena la información de las zonas de BIND
/etc/namedb/named.confEl archivo de configuración del dæmon

Los ficheros de zonas se encuentran normalmente bajo el directorio /etc/namedb y contienen la información que proporciona el servidor de nombres al resto de máquinas de Internet.

29.11.5. Ejecución de BIND

Debido a que BIND se instala por defecto la configuración resulta ser bastante sencilla.

Para asegurarnos de que el dæmon se ejecuta al inicio del sistema se deben añadir las siguientes modificaciones en /etc/rc.conf:

named_enable="YES"

Para arrancar el dæmon de forma manual (una vez configurado)

# ndc start

29.11.6. Ficheros de configuración

29.11.6.1. Uso de make-localhost

Asegúrese de hacer los siguiente

# cd /etc/namedb
# sh make-localhost

para que se cree el archivo de zona inversa /etc/namedb/localhost.rev de forma apropiada.

29.11.6.2. /etc/namedb/named.conf

// $FreeBSD$
//
// Consulte la página man de named(8) para más detalles.  tiene
// alguna vez la necesidad de configurar un servidor primario
// asegúree de que entiende a la perfección los detalles peliagudos
// del funcionamiento del DNS.  Si hay errores, incluso triviales,
// puede sufrir pérdidas de conectividad ogenerar cantidades ingentes
// de tráfico inútil hacia o desde Interne

options {
        directory "/etc/namedb";

// Además de con la láusula "forwarders" puedeobligar a su servidor
// de nombres a que nunca lance búsquedas por su cuenta sino que
// se las pida a sus "forwarders". Esto se hace del siguiente modo:
//
//      forward only;

// Si su proveedor de acceso tiene a su alcance un servidor DNS
// escriba aquí su dirección IP y descomente la líneaPodrá usar
// su caché y por lo tanto reducir el tráfico DNS de Internet.
//

/*
        forwarders {
                127.0.0.1;
        };
*/

Tal y como se dice en los comentarios del ejemplo para beneficiarnos de la caché se puede activar forwarders. En circunstancias normales un servidor de nombres busca de forma recursiva a través de Internet tratando de localizar un servidor de nombres que sea capaz de responder una determinada pregunta. Si se activa esta opción por defecto se pasa a preguntar primero al servidor de nombres especificado (servidor o servidores) pudiendo aprovecharse de la información de caché que dicho servidor tuviera disponible. Si el servidor de nivel superior al nuestro se encuentra congestionado puede merecer la pena la activación de esta característica de redirección ya que se puede disminuir la carga de tráfico que dicho servidor tiene que soportar.

Aviso:

La dirección IP 127.0.0.1 no funciona aí. Se debe cambiar esta dirección IP por un servidor de nombres válido.

        /*
	 * Si hay un cortafuegos entre usted y los servidores de
	 * nombres que quiere consultar tendrá que descoentar la
	 * siguiente directiva, "query-source".  Las versiones
	 * anteriores de BIND siempre hacían sus consultas a través
	 * del puerto 53 pero BIND 8.1 utiliza por defecto un puerto no
	 * privilegiado.
         */
        // query-source address * port 53;

        /*
	 * Si lo va a ejecutar en un "cajón de arena" (o "sandbox")
	 * tendrá que declarar una uicación diferente para el
	 * fichero de volcado de named.
         */
        // dump-file "s/named_dump.db";
};

// Nota: lo siguiente será incluído en futuras versiones.
/*
host { any; } {
        topology {
                127.0.0.0/8;
        };
};
*/

// La configuración de secundarios se explica de modo secillo a
// partir de aquí.
//
// Si activa un servidor de nombres local no olvide incluír
// 127.0.0.1 en su /etc/resolv.conf para que sea ese servidor el
// primero al que se consulte.
// Asegúrese también de activarlo en /etc/rc.con

zone "." {
        type hint;
        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
        type master;
        file "localhost.rev";
};

// Nota: No use las direcciones IP que se muestran aquí, son falsas
// y sólo se usancomo demostración y para una mejor comprensión.
//
// Ejemplo de entradas en la configuración de secundarios.  Puede ser
// conveniente convertirse en secundario al menos del dominio en cuya
// zona está su dominio.  Cnsulte con su administrador de red para
// que le facilite la dirección IP del servidor primario.
//
// No olvide incluír la zona del bucle inverso (IN-ADDR.ARPA).  (Son
// los primeros bytes de la dirección IP correspondiente, en orden
// inverso, con ".IN-ADDR.ARPA" al final.)
//
// Antes de configurar una zona primara asegúresede haber comprendido
// completamente cómo funcionan DNS y BIND.  Hay errores que no son
// visibles fácilmente.  La configuración de un secundario es, por
// el contrario, muchísimo más sencilla.
//
// Nota: No se limite a copiar los ejemplos de más arriba. :-)
// Utilice nombres y direcciones reales.
//
// ADVERTENCIA: FreeBSD ejecuta bind en un sandbok (observe los
// parámeros de named (named_flags) en rc.conf).  El directorio que
// contiene las zonas secundarias debe tener permisos de escritura
// para bind.  Le sugerimos la siguiente secuencia de órdenes:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s

Si quiere más información sobre cómo ejecutar BIND en un sandbox consulte Ejecución de named en un sandbox.

/*
zone "ejemplo.com" {
        type slave;
        file "s/ejemplo.com.bak";
        masters {
                192.168.1.1;
        };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "s/0.168.192.in-addr.arpa.bak";
        masters {
                192.168.1.1;
        };
};
*/

Dentro del fichero named.conf se muestran ejemplos de entradas de esclavo tanto para las zonas directas como para las inversas.

Para cada nueva zona administrada se debe crear una entrada de zona dentro del fichero named.conf

Por ejemplo la entrada de zona más simple para el dominio ejemplo.org puede ser algo como esto:

zone "ejemplo.org" {
	type master;
	file "ejemplo.org";
};

Esta zona es una zona maestra ( observe la línea de type, y mantiene la información de la zona en /etc/namedb/ejemplo.org tal como se indica en la línea de file.

zone "ejemplo.org" {
	type slave;
	file "ejemplo.org";
};

En el caso del esclavo la información de la zona se transmite desde el servidor de nombres maestro y se almacena en el fichero especificado. Cuando el servidor maestro muere o no puede ser alcanzado el servidor de nombres esclavo puede responder a las peticiones debido a que posee la información de la zona.

29.11.6.3. Ficheros de zona

A continuación se muestra un fichero de una zona maestra para el dominio ejemplo.org, que se encuentra ubicado en /etc/namedb/ejemplo.org:

$TTL 3600

example.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

; DNS Servers
@       IN NS           ns1.ejemplo.org.
@       IN NS           ns2.ejemplo.org.

; Machine Names
localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

; Aliases
www             IN CNAME        @

; MX Record
@               IN MX   10      mail.ejemplo.org.

Tenga muy en cuenta que todo nombre de máquina que termina en . es tratado como si fuera un nombre de máquina completo mientras que cualquier otro nombre sin el . final se trata como una referencia relativa al dominio de origen de la zona. Por ejemplo www se traduce a www + origen. En nuestro fichero de zona ficticio nuestro origen es ejemplo.org de forma que www se convierte en www.ejemplo.org

El formato de un fichero de zona es el siguiente:

nombrederegistro IN tipodeentrada valor

Los registros de DNS que más se utilizan son:

SOA

Comienzo de Zona con Autoridad (Start Of zone Authority)

NS

Un servidor de nombres con autoridad para una una determinada zona

A

Una dirección IP de una máquina

CNAME

El nombre canónico de una máquina para definir un alias

MX

mail exchanger

PTR

Un puntero a un nombre de dominio (utilizados para definir el DNS inverso)

ejemplo.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. (
                        5               ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day
ejemplo.org.

el nomre de dominio, también el origen para el fichero de zona

ns1.ejemplo.org.

el servidor de nombres primario/autoritario para esta zona

admin.ejemplo.org.

la persona responsable de esta zona; observe que la dirección de correo electrónico aparece con la @ sustituida por un punto. ( se escribe admin.ejemplo.org)

5

el número de serie del fichero. Este número se debe incrementar cada vez que se modifique el fichero de zona. Muchos administradores prefieren un formato expresado del siguiente modo aaaammddss. 2001041002 significa (según dicho formato) que el fichero se modificó por última vez el 04/10/2001 y se indica con los dos últimos dígitos (02) que es la segunda vez en el día que se ha modificado el fichero. El número de serie es importante ya que para avisar a los servidores de nombres esclavos de que se ha actualizado la zona.

@       IN NS           ns1.ejemplo.org.

Esta es una entrada de tipo NS. Cada servidor de nombres que contesta de forma autoritaria a las consultas de un determinado dominio debe tener una de estas entradas. El caracter @ se sustituye por ejemplo.org., es decir, se sustituye por el origen.

localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

El registro de tipo A hace referencia a nombres de máquinas . Como puede verse más arriba ns1.ejemplo.org se resuelve a 3.2.1.2. Vemos que se utiliza otra vez el origen @, que significa que ejemplo.org se resuelve a 3.2.1.30.

www             IN CNAME        @

Los registros de nombres canónicos se utilizan normalmente como alias de máquinas. En el ejemplo www es un alias de ejemplo.org (3.2.1.30). CNAMEs se puede utilizar para proporcionar alias de nombres de máquinas, o también para proporcionar un mecanismo de vuelta cíclica (round robin) de un nombre de máquina mapeado a un determinado conjunto de máquinas intercambiables.

@               IN MX   10      mail.ejemplo.org.

El registro MX indica qué servidores de correo se encargan de recibir correos para esta zona. mail.example.org es el nombre del servidor de correo y 10 significa la prioridad de dicho servidor.

Se pueden especificar varios servidores de correo con prioridades de, por ejemplo,3, 2 y 1. Un servidor de correo que intenta entregar correo para el dominio ejemplo.org primero intentará contactar con el servidor especificado en el registro MX de mayor prioridad, después con el siguiente y así sucesivamente hasta que lo logre entregar.

Para los ficheros de zona de in-addr.arpa (DNS inverso) se utiliza el mismo formato excepto que se especifican registros PTR en lugar de registros A o CNAME.

$TTL 3600

1.2.3.in-addr.arpa. IN SOA ns1.ejemplo.org. admin.ejemplo.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        3600 )          ; Minimum

@       IN NS   ns1.ejemplo.org.
@       IN NS   ns2.ejemplo.org.

2       IN PTR  ns1.ejemplo.org.
3       IN PTR  ns2.ejemplo.org.
10      IN PTR  mail.ejemplo.org.
30      IN PTR  ejemplo.org.

Este fichero proporciona las asociaciones de direcciones IP con nombres de máquinas adecuadas para nuestro dominio ficticio.

29.11.7. Servidor de nombres de cache

Un servidor de nombres de tipo caché es un servidor de nombres que no es autoritario para ninguna zona. Simplemente realiza consultas por sí mismo y recuerda las respuestas para futuros usos. Para configura uno de estos servidores se configura el servidor de la forma habitual pero se omite la inclusión de zonas.

29.11.8. Ejecución de named en una Sandbox

Para obtener una mayor seguridad se puede ejecutar named(8) como un usuario sin privilegios y configurarlo mediante chroot(8) dentro del directorio especificado como el directorio del sandbox. Esto hace que cualquier cosa que se encuentre fuera de dicho directorio resulte inaccesible para el dæmon named. En caso de que se comprometiera la seguridad de named esta restricción puede ayudar a limitar el daño sufrido. FreeBSD dispone por defecto de un usuario y un grupo destinado a este uso: bind.

Nota:

Hay quien recomienda que en lugar de configurar named con chroot es mejor configurarlo dentro de jail(8). En esta sección no se va a explicar esa alternativa.

Debido a que named no va a poder acceder a nada que se encuentre fuera del directorio sandbox (y esto incluye cosas tales como bibliotecas compartidas, sockets de log, etc) se debe efectuar una serie de cambios para que named pueda funcionar con normalidad. En la siguiente lista se supone que la ruta del sandbox es /etc/namedb y que no se ha modificado anteriormente dicho directorio. Por favor, ejecute los pasos que se muestran a continuación:

  • Cree todos los directorios que named espera tener a su disposición:

    # cd /etc/namedb
    # mkdir -p bin dev etc var/tmp var/run master slave
    # chown bind:bind slave var/*1

    1

    named sólamente necesita escribir en estos directorios así que eso es todo lo que debemos crear.

  • Reorganizar y crear los archivos de configuración de zona básicos:

    # cp /etc/localtime etc1
    # mv named.conf etc && ln -sf etc/named.conf
    # mv named.root master
    
    # sh make-localhost && mv localhost.rev localhost-v6.rev master
    # cat > master/named.localhost
    $ORIGIN localhost.
    $TTL 6h
    @	IN	SOA	localhost. postmaster.localhost. (
    			1	; serial
    			3600	; refresh
    			1800	; retry
    			604800	; expiration
    			3600 )	; minimum
    	IN	NS	localhost.
    	IN	A		127.0.0.1
    ^D

    1

    Esto permite que named pueda escribir al archivo de log la hora correcta a través del syslogd(8)

  • Si está usando una versión de FreeBSD anterior a 4.9-RELEASE se debe construir una copia estáticamente enlazada de named-xfer y copiarla dentro del directorio del sandbox:

    # cd /usr/src/lib/libisc
    # make cleandir && make cleandir && make depend && make all
    # cd /usr/src/lib/libbind
    # make cleandir && make cleandir && make depend && make all
    # cd /usr/src/libexec/named-xfer
    # make cleandir && make cleandir && make depend && make NOSHARED=yes all
    # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer1

    Despueés de instalar la versión estática de named-xfer se deben realizar algunas tareas de limpieza para evitar dejar copias de bibliotecas o de programas en nuestros ficheros de fuentes:

    # cd /usr/src/lib/libisc
    # make cleandir
    # cd /usr/src/lib/libbind
    # make cleandir
    # cd /usr/src/libexec/named-xfer
    # make cleandir

    1

    En algunas ocasiones este paso puede fallar. Si es su caso ejecute lo siguiente:

    # cd /usr/src && make cleandir && make cleandir

    y borre su directorio /usr/obj:

    # rm -fr /usr/obj && mkdir /usr/obj

    Esto limpia cualquier impureza del árbol de fuentes y si se repiten los pasos anteriores todo debería funcionar.

    Si se está usando FreeBSD version 4.9-RELEASE o posterior el ejecutable de named-xfer del directorio /usr/libexec ya se encuentra enlazado estáticamente y se puede utilizar cp(1) para copiarlo directamente en nuestro sandbox.

  • Cree el fichero dev/null de tal forma que named pueda verlo y pueda escribir sobre él:

    # cd /etc/namedb/dev && mknod null c 2 2
    # chmod 666 null
  • Enlace simbólicamente /var/run/ndc con /etc/namedb/var/run/ndc:

    # ln -sf /etc/namedb/var/run/ndc /var/run/ndc

    Nota:

    Esto simplemente evita el tener que especificar la opción -c de ndc(8) cada vez que se ejecute. Dado que los contenidos de /var/run se borran al inicio del sistema, si se piensa que esto puede resultar útil, se puede añadir esta orden al crontab del usuario root utilizando la opción @reboot. Consulte crontab(5) para saber más información sobre esto.

  • Configure syslogd(8) para que cree un socket de log adicional de tal forma que named pueda escribir sobre él. Añada -l /etc/namedb/dev/log a la variable syslogd_flags dentro del fichero /etc/rc.conf.

  • Reorganice la ejecución de las aplicaciones named y chroot para que se ejecuten dentro del sandbox añadiendo lo siguiente al fichero/etc/rc.conf:

    named_enable="YES"
    named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"

    Nota:

    Recuerde que el fichero de configuración /etc/named.conf tiene una ruta completa que comienza en el directorio del sandbox; por ejemplo, en la línea superior el fichero que aparece es en realidad /etc/namedb/etc/named.conf.

El siguiente paso consiste en editar el fichero /etc/namedb/etc/named.conf de tal forma que named pueda conocer qué zonas cargar y donde encontrarlas en disco. A continuación se muestra un ejemplo comentado (cualquier cosa que no se comenta en el ejemplo es porque resulta igual que la configuración del servidor de DNS del caso normal):

options {
        directory "/";1
        named-xfer "/bin/named-xfer";2
        version "";		// No muestra la versiÃn de BIND
        query-source address * port 53;
};
// ndc control socket
controls {
        unix "/var/run/ndc" perm 0600 owner 0 group 0;
};
// A partir de aquívan las zonas:
zone "localhost" IN {
        type master;
        file "master/named.localhost";3
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "master/localhost.rev";
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
	type master;
	file "master/localhost-v6.rev";
	allow-transfer { localhost; };
	notify no;
};
zone "." IN {
        type hint;
        file "master/named.root";
};
zone "private.example.net" in {
        type master;
        file "master/private.example.net.db";
	allow-transfer { 192.168.10.0/24; };
};
zone "10.168.192.in-addr.arpa" in {
        type slave;
        masters { 192.168.10.2; };
        file "slave/192.168.10.db";4
};

1

La línea que contiene directory se especifica como /, ya que todos los ficheros que named necesita se encuentran dentro de este directorio (recuerde que esto es equivalente al fichero /etc/namedb de un usuario normal.

2

Especifica la ruta completa para el binario named-xfer binary (desde el marco de referencia de named). Esto resulta necesario ya que por defecto named se compila de tal forma que trata de localizar named-xfer dentro de /usr/libexec.

3

Especifica el nombre del fichero (relativo a la línea (relativo a la línea ) directory anterior) donde named puede encontrar el fichero de zona para esta zona.

4

Especifica el nombre del fichero (relativo a la líena directory anterior) donde named debería escribir una copia del archivo de zona para esta zona después de recuperarla exitosamente desde el servidor maestro. Este es el motivo por el que en las etapas de configuración anteriores necesitábamos cambiar la propiedad del directorio slave al grupo bind.

Después de completar los pasos anteriores reinicie el servidor o reinicie syslogd(8) y ejecute named(8) asegurándose de que se utilicen las nuevas opciones especificadas en syslogd_flags y named_flags. En estos momentos deberíamos estar ejecutando una copia de named dentro de un sandbox.

29.11.9. Seguridad

Aunque BIND es la implementación de DNS más utilizada existe siempre el asunto relacionado con la seguridad. De vez en cuando se encuentran agujeros de seguridad y vulnerabilidades.

Es una buena idea suscribirse a CERT y a freebsd-security-notifications para estar al día de los problemas de seguridad relacionados con named.

Sugerencia:

Si surge un problema nunca está de más actualizar los fuentes y recompilar los ejecutables desde dichas fuentes.

29.11.10. Lecturas recomendadas

Las páginas del manual de BIND/named: ndc(8) named(8) named.conf(5)

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.

Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.