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.
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.
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.
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.
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
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.
// $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.
AvisoLa 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.
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:
Comienzo de Zona con Autoridad (Start Of zone Authority)
Un servidor de nombres con autoridad para una una determinada zona
Una dirección IP de una máquina
El nombre canónico de una máquina para definir un alias
mail exchanger
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
el nomre de dominio, también el origen para el fichero de zona
el servidor de nombres primario/autoritario para esta zona
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)
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.
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.
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/*
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
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
# 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"; };
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”.
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.
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>.