29.11. DNS
Anterior | Capítulo 29. Networking avanzado | Siguiente

## 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érmino | Definición
--- | ---
DNS directo (Forward DNS) | Asociación de nombres de máquinas con direcciones IP
Origen | Se 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
Resolver | Un 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íz | El 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.
Zona | Un 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.

Fichero | Descripción
--- | ---
named | El dæmon de BIND
`ndc` | El programa de control del dæmon
`/etc/namedb` | El directorio donde se almacena la información de las zonas de BIND
`/etc/namedb/named.conf` | El 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. (`<admin@ejemplo.org>` 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`). `CNAME`s 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/*`

  | 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 etc` `#` `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`

  | 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-xfer`

  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`

  | 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 "/"; named-xfer "/bin/named-xfer"; 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"; 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"; };

| 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”.
| 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`.
| 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.
| 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)

- Página oficial de ISC Bind

- Preguntas más frecuentes sobre BIND

- Libro de O'Reilly "DNS and BIND", cuarta edición

- RFC1034 - Nombre de Dominio - Conceptos y Características

- RFC1035 - Nombres de Domninio - Implementación y Especificación

Anterior | Subir | Siguiente
29.10. DHCP | Inicio | 29.12. NTP

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>.