El Sistema de Nombres de Dominio - Bind 9.2

El sistema de nombres de dominio: Bind 9.2.
1 de 32
http://linuxsilo.net/articles/bind.html
El sistema de nombres de dominio: Bind 9.2.4

Por Jaume Sabater, publicado el 27 de mayo de 2002.
Artculo distribuido bajo licencia Creative Commons by-nc-sa.
ndice
Resumen.
Objetivos.
Introduccin
Qu es el DNS?
Quin necesita el DNS?
Requerimientos y datos tcnicos.
Instalacin.
Traduccin de nombres a direcciones IP.
Traduccin inversa.
Servidores secundarios.
Transferencia segura de zonas
Qu es una TSIG y para qu se necesita.
Creacin de una clave TSIG.
Comentarios sobre la actualizacin dinmica, la seguridad de las TSIG y las ACL.
Riesgos a los que se expone un Bind inseguro.
Entonces, qu medidas es necesario tomar?
Servidores recursivos y no recursivos.
Localizacin de servicios.
Tipos de registro del DNS.
Vistas.
La herramienta RNDC.
Personalizacin de los logs.
Taxonoma de un servidor de nombres.
Tipos de sentencias usadas en el named.conf.
Ejemplo de personalizacin de logs.
Tabla de caracteres especiales utilizados en los registros de recursos.
Tabla de mecanismos de seguridad en el named.conf.
Tabla de categoras de logging en Bind 9.
Chroot.
Crear el usuario.
Estructura de directorios.
Copiar los ficheros necesarios.
Ficheros de sistema.
Logging
Endureciendo los permisos.
Instalacin.
Cambios en la configuracin.
Arrancando BIND.
Recursos en lnea.
Los RFC.
Historial de revisiones.
Resumen.
Millones de hosts se encuentran conectados a Internet. Cmo se consigue mantener la pista de todos ellos cuando
pertenecen a tantos pases, redes y grupos administrativos distintos? Dos piezas bsicas de infraestructura
mantienen todo eso junto: el sistema de nombres de dominio (DNS, del ingls Domain Name System), cuya funcin
es saber quin es cada host, y el sistema de enrutado de Internet, que se encarga de conocer cmo estn
conectados. Este artculo hace referencia a la porcin que supone el DNS en ese sistema.
Objetivos.
Los objetivos de un servidor de nombres de dominio (DNS, del ingls Domain Name Service) son dos:
21/10/2014 2:11
2 de 32
1. Por una parte, traducir una direccin cannica en una direccin IP (del ingls, Internet Protocol). Por
ejemplo, linuxsilo.net es, a fecha de creacin del artculo, 66.79.182.201.
2. Por otra parte, traducir una direccin IP en una o varias direcciones cannicas. Es lo que se conoce como
traduccin inversa.
Haciendo un smil, el primer punto equivaldra a buscar en una agenda el nmero de telfono de una persona, dado
su nombre y apellidos, mientras que el segundo sera el proceso inverso: dado un nmero de telfono averiguar a
qu persona corresponde.
La correlacin entre una direccin IP y un nombre de dominio no tiene porqu ser nica. Esto es debido a lo que se
conocen como dominios virtuales. De hecho, es habitual que una direccin IP equivalga a varios nombres de
dominio. Por ejemplo, la direccin IP 66.79.182.201 es equivalente a linuxsilo.net, www.linuxsilo.net,
ftp.linuxsilo.net, pop3.linuxsilo.net y otros. Sin embargo, esto no significa que la misma mquina (o host)
66.79.182.201 est ofreciendo todos esos servicios. Esto es posible gracias a lo que se conoce como enrutamiento
(del ingls, routing) de paquetes, pero no viene al caso del artculo.
Introduccin.
Qu es el DNS?
DNS es un sistema jerrquico con estructura de rbol. El inicio se escribe "." y se denomina raz, al igual que en las
estructuras de datos en rbol. Bajo la raz se hallan los dominios de ms alto nivel (TLD, del ingls, Top Level
Domain), cuyos ejemplos ms representativos son ORG, COM, EDU y NET, si bien hay muchos ms. Del mismo
modo que un rbol, tiene una raz y ramas que de ella crecen. Si el lector est versado en ciencias de la
computacin, reconocer el DNS como un rbol de bsqueda y ser capaz de encontrar en l los nodos, nodos hoja
y otros conceptos.
Cuando se busca una mquina, la consulta se ejecuta recursivamente en la jerarqua, empezando por la raz. Si se
desea encontrar la direccin IP de ftp.akane.linuxsilo.net., el servidor de nombres (del ingls, nameserver) tiene
que empezar a preguntar en algn sitio. Empieza mirando en su cach. Si conoce la respuesta, pues la haba
buscado anteriormente y guardado en dicha cach, contestar directamente. Si no la sabe, entonces eliminar
partes del nombre, empezando por la izquierda, comprobando si sabe algo de akane.linuxsilo.net., luego de
linuxsilo.net., luego net. y, finalmente, de ".", del cual siempre se tiene informacin ya que se encuentra en uno de
los ficheros de configuracin en el disco duro. A continuacin preguntar al servidor "." acerca de
ftp.akane.linuxsilo.net. Dicho servidor "." no sabr la contestacin, pero ayudar a nuestro servidor en su bsqueda
dndole una referencia de dnde seguir buscando. Estas referencias llevarn a nuestro servidor hasta el servidor de
nombres que conoce la respuesta.
As pues, empezando en "." encontramos los sucesivos servidores de nombres para cada nivel en el nombre de
dominio por referencia. Por supuesto, nuestro servidor de nombres guardar toda la informacin obtenida a lo largo
del proceso, a fin de no tener que preguntar de nuevo durante un buen rato.
En el rbol anlogo, cada "." en el nombre es un salto a otra rama. Y cada parte entre los "." son los nombres de
los nodos particulares en el rbol. Se trepa el rbol tomando el nombre que queremos (ftp.akane.linuxsilo.net)
preguntando a la raz (".") o al servidor que sea padre desde la raz hacia ftp.akane.linuxsilo.net acerca de los
cuales tengamos informacin en la cach. Una vez se alcanzan los lmites de la cach, se resuelve recursivamente
preguntando a los servidores, persiguiendo las referencias (ramas) hacia el nombre.
Otro concepto del cual no se habla tanto, pero que no es menos importante, es el dominio in-addr.arpa, que
tambin se encuentra anidado como los dominios "normales". in-addr.arpa nos permite hacernos con el nombre del
host cuando tenemos su direccin. Merece la pena destacar aqu que las direcciones IP estn escritas en orden
inverso en el dominio in-addr.arpa. Si se tiene la direccin de una mquina tal como 192.168.0.1, el servidor de
nombres proceder del mismo modo que con el ejemplo ftp.akane.linuxsilo.net. Es decir, buscar los servidores
arpa., luego los servidores in-addr.arpa., luego los 192.in-addr.arpa., luego los 168.192.in-addr.arpa. y, por ltimo,
los servidores 0.168.192.in-addr.arpa. En este ltimo encontrar el registro buscado: 1.0.168.192.in-addr.arpa.
Quin necesita el DNS?
El DNS define:
1. Un espacio de nombres jerrquico para los hosts y las direcciones IP.
2. Una tabla de hosts implementada como una base de datos distribuida.
3. Un traductor (del ingls, resolver) o librera de rutinas que permite realizar consultas a esa base de datos.
21/10/2014 2:11
4. Enrutamiento mejorado para el correo electrnico.

5. Un mecanismo para encontrar los servicios en una red.
6. Un protocolo para intercambiar informacin de nombres.
Para ser autnticos ciudadanos de Internet, los sitios necesitan el DNS. Mantener un fichero local /etc/hosts con un
mapeado de todos los hosts que los usuarios puedan querer contactar no es factible.
Cada sitio mantiene una o varias piezas de la base de datos distribuida que posibilita el servicio global del sistema
DNS. Su pieza de la base de datos consiste en dos o ms ficheros de texto que contienen registros para cada uno
de los hosts. Cada registro es una sencilla lnea consistente en un nombre (normalmente el nombre de un host), un
tipo de registro y diversos valores o datos.
El DNS es un sistema cliente/servidor. Los servidores (de nombres) cargan los datos de sus ficheros de DNS en
memoria y los usan para responder las consultas tanto de los clientes de la red interna como de los clientes y otros
servidores en la red Internet. Todos sus hosts deberan ser clientes del DNS, pero relativamente pocos necesitan
ser servidores de DNS.
Si su organizacin es pequea (unos pocos hosts en una nica red), puede ejecutar un servidor en uno de sus
equipos o pedirle a su ISP (del ingls, Internet Services Provider) que le proporcione ese servicio en su nombre.
Un sitio de tamao medio con diversas subredes debera tener mltiples servidores de DNS para reducir la latencia
de las consultas y mejorar la productividad. Un sistema muy grande puede dividir sus dominios de DNS en
subdominios y usar algunos servidores para cada subdominio.
Requerimientos y datos tcnicos.

En este artculo se aprender a instalar y configurar BIND (del ingls, Berkeley Internet Name Domain) sobre un
sistema Linux. Se darn por supuestos ciertos conocimientos mnimos de redes TCP/IP (del ingls, Transmission
Control Protocol / Internet Protocol) y de administracin Linux o, al menos, un conocimeinto bsico del
funcionamiento de un sistema de este tipo. Estos son los puntos que se tratarn y el software y hardware usado.
Software:
1.
2.
3.
4.
Debian GNU/Linux Sarge

Bind 9.2.4
DNS Utils
Bind Docs
Servicios:
1.
2.
3.
4.
5.
6.
7.
8.
9.

Traduccin inversa (de direcciones IP a nombres).
Listas de control de acceso.
Servidores secundarios.
Transferencia segura de zonas entre servidores primarios y secundarios (y puertos).
Localizacin de servicios (registros SRV - RFC2052, del ingls, Request For Comments).
Respuestas parametrizadas en funcin del origen de la peticin (vistas).
Uso de la herramienta rndc.
Logs a medida.
Para este artculo se usar el FQDN (del ingls, Fully Qualified Domain Name) linuxsilo.net y los servidores de
nombres ns1.linuxsilo.net y ns2.linuxsilo.net. Un FQDN est formado por un host y un nombre de dominio, incluyendo
el dominio de ms alto nivel. Por ejemplo, www.linuxsilo.net es un FQDN. www es el host, linuxsilo es el dominio de
segundo nivel y net es el dominio de ms alto nivel. Un FQDN siempre empieza con el nombre del host y continua
subiendo directo al dominio de ms alto nivel, por lo que ftp.akane.linuxsilo.net es tambin un FQDN. akane no es
un FQDN.
Instalacin.
De este tipo de software siempre es ms que recomendable tener la ltima versin, pues podemos hallar en ella
importantes errores y fallos de seguridad corregidos, as como nuevas funcionalidades que faciliten nuestra tarea
como administradores de sistemas. El proceso de instalacin en una distribucin Debian de Linux es tan sencillo
como ejecutar (como root, por supuesto, del mismo modo que en el resto del artculo):
apt-get install bind9 bind9-doc dnsutils
3 de 32
21/10/2014 2:11
4 de 32
Dependiendo de la versin de Debian, el paquete Bind9 no estar disponible (por ejemplo, en Potato se encuentra la
versin 8), por lo que deberemos actualizar a una versin ms actual (Woody o Sid en el momento de escribir este
artculo) y proceder. La instalacin nos deja un Bind con una configuracin bsica (en /etc/bind/) y funcionando, por
lo que tan slo deberemos configurarlo segn nuestras necesidades. Empezaremos por la traduccin de nombres a
direcciones IP.
El paquete Debian bind9 se instala con una configuracin ya funcional para la inmensa mayora de los servidores
terminales sin que sea necesaria la accin del usuario.
El fichero de configuracin named.conf del demonio (del ingls, daemon) named (nombre en el sistema del
demonio del servidor de nombres de dominio Bind) se encuentra en /etc/bind, de modo que todos los ficheros
estticos de configuracin relacionados con Bind estn en el mismo lugar. Se recomienda encarecidamente no
modificar esta configuracin, ms en un sistema GNU/Debian Linux. De todos modos, si es necesario hacerlo,
posiblemente la mejor manera sea usando un enlace simblico a la localizacin que desee usarse.
Los ficheros de datos de las zonas para los servidores raz y las zonas de traduccin de direcciones (del ingls,
forward) y de traduccin inversa (del ingls, reverse) para el host local (del ingls, localhost) se encuentran
tambin en /etc/bind. El directorio de trabajo (del ingls, working directory) de named es /var/cache/bind. Por lo
tanto, cualesquiera ficheros temporales generados por named, como los ficheros de la base de datos de las zonas
que son secundarias para el demonio, sern escritos en el sistema de ficheros de /var, que es a donde pertenecen.
Para conseguir que esto funcione, el named.conf proporcionado con la instalacin usa explcitamente rutas
absolutas (del ingls, fully-qualified o absolute pathnames) para referenciar los ficheros en /etc/bind.
A diferencia de anteriores paquetes Debian de Bind, los ficheros named.conf y todos los db.* de la instalacin se
consideran ficheros de configuracin. Por ello, si tan slo se requiere una configuracin "de cach" para un servidor
que no ha de ser el autorizado (del ingls, authoritative) de ningn dominio, se puede ejecutar la configuracin
proporcionada tal cual. Si es necesario cambiar opciones en el named.conf, o incluso referentes al init.d, puede
hacerse sin compromiso, pues las futuras actualizaciones respetarn dichos cambios, siguiendo la poltica de
paquetes de Debian.
Si bien el lector es libre para idear la estructura que ms le plazca para los servidores de los cuales necesita ser el
autorizado, se sugiere que todos los ficheros db para las zonas de las cuales se es servidor primario (del ingls,
master) estn en /etc/bind (quizs incluso en una estructura de subdirectorios, dependiendo de la complejidad), y
usar rutas absolutas en el fichero named.conf. Cualesquiera zonas de las que se es servidor secundario (del ingls,
secondary) deberan configurarse en el named.conf como nombres de fichero sin ruta, de forma que los ficheros
de datos terminen crendose en /var/cache/bind. A lo largo del artculo se ilustrar este concepto para una mejor
comprensin.

El primer paso es editar el fichero /etc/bind/named.conf.options, donde cambiaremos algunos de los valores por
defecto y aadiremos todo lo necesario para que nuestro dominio sea accesible desde el exterior.
A menos que seamos un proveedor de servicios de internet, se nos habrn proporcionado una o ms direcciones IP
de servidores de nombres estables, que seguramente querremos usar como redireccionadores (del ingls,
forwarders), si bien no es imprescindible para conseguir los objetivos bsicos de este artculo. Para ello
deberemos descomentar el bloque casi al principio del fichero:
// forwarders {
//
0.0.0.0;
// };
Y dejarlo en algo como esto:
forwarders {
66.79.160.3;
};
Donde las IPs son las correspondientes a nuestro ISP. Esta directiva le indica a nuestro servidor que pase a otro
servidor de nombres todas las peticiones para las cuales no es el autorizado o no tiene la respuesta en cach. En el
caso de no especificarlos, se usarn los servidores raz de DNS. Otras opciones interesantes de Bind (dentro de la
directiva options y finalizadas en punto y coma) son:
1. pid-file "/var/run/named.pid";, que definira la localizacin del fichero que contiene el PID (del
ingls, Process IDentificator) del demonio named,
21/10/2014 2:11
5 de 32
2. stacksize 30M;, que determinara un tamao de pila de treinta megabytes,

3. datasize 20M;, que especificara un tamao mximo de memoria dedicado a almacenar datos de veinte
megabytes,
4. transfer-format many-servers;, que provocara la transferencia en paralelo de varias zonas a los
servidores secundarios, acelerando el proceso,
5. allow-transfer { slaves; };, que acotara globalmente las transferencias de zonas a los servidores
secundarios en la lista slaves (ver ms abajo el uso de listas de control de acceso),
6. y version "DNS server";, que ocultara la versin de Bind que se est ejecutando, en aras a una mayor
seguridad del sistema.
Acto seguido se proceder a dar de alta las zonas para nuestros dominios. Si abrimos con un editor de textos el
/etc/bind/named.conf que viene por defecto con la instalacin encontramos cinco zonas:
La raz (el punto)
localhost
127.in-addr.arpa
0.in-addr.arpa
255.in-addr.arpa
Mediante la primera damos a conocer los servidores raz a nuestro servidor de DNS, mientras que con las otras
cuatro nos hacemos cargo de la traduccin normal e inversa del localhost. A partir de aqu, abrimos el fichero
/etc/bind/named.conf.local y en l creamos la zona de nuestro dominio:
zone "linuxsilo.net" {
type master;
file "/etc/bind/db.linuxsilo.net";
allow-query { any; };
allow-transfer { slaves; };
};
El orden de las zonas es completamente irrelevante, pero se recomienda dejarlas en orden alfabtico para una ms
fcil localizacin en el futuro. Ntese que el nombre de la zona no termina en "." (punto). Este es el cometido de los
parmetros de cada zona:
1. type master; significa que el servidor de dominios es primario o maestro de la zona. Ms adelante, al
configurar servidores secundarios, se usar type slave;.
2. file "/etc/bind/db.linuxsilo.net"; es el fichero donde especificaremos la configuracin de esa
zona. Ntese que se usa una ruta absoluta, siguiendo la poltica de directorios de Debian. El contenido de
este fichero se especificar en breve.
3. allow-query { any; }; significa que se permiten consultas (del ingls, queries) externas a la zona.
Esto es algo til y necesario, a menos que se quiera ser muy paranoico con la seguridad. Simplemente se
ofrece de forma tcnicamente ordenada la informacin que es pblicamente accesible.
4. allow-transfer { slaves; }; posibilita la transferencia automtica de esta configuracin a los
servidores secundarios de las zonas bajo nuestro control que se especifiquen en la lista slaves. Se
profundizar ms en el punto de transferencia de zonas.
Seguramente, el lector se habr percatado ya de que se han usado dos palabras especiales, any y slaves, que
requieren una mencin especial. Efectivamente, adems de hacer notar la sintaxis similar a la del lenguaje de
programacin C, con la que se debe ser extremamente cuidadoso, hay dos comentarios extras que hacer:
1. any es una palabra reservada de la sintaxis de bind que significa "cualquier direccin IP", como era lgico.
Su uso es muy comn y necesario. Otras palabras reservadas importantes son none, que significa "ningn
host", localhost, que significa el host local desde cualquiera de las interfaces del sistema, y localnets,
que representa a todos los hosts de las redes para las cuales el sistema tiene una interfaz.
2. slaves, en cambio, no es ninguna palabra reservada de bind, sino que corresponde al concepto de lista de
control de acceso (ACL, del ingls, Access Control List). Estas listas de direcciones IP nos ahorran trabajo
21/10/2014 2:11
6 de 32
pues, de este modo, tan slo tenemos que especificarlas una vez y, dado que les asginamos un identificador
de grupo, podemos referenciarlas de forma ms simple y rpida. Este es el cdigo de la ACL usada en el
ejemplo que, por supuesto, debe especificarse en algn lugar del documento antes de ser usada:
acl "slaves" {
213.96.79.79;
};
El lector se habr dado cuenta en seguida de las grandes ventajas de usar estas listas, bien sea porque la lista se
use en varias zonas, bien porque tengamos ms de un servidor esclavo. Ntese que en los identificadores de las
ACL se diferencian maysculas y minsculas (en ingls, case sensitive).
A continuacin se detalla el contenido del fichero de datos de la zona linuxsilo.net:
;
; BIND data file for zone linuxsilo.net
;
$TTL 604800
@ IN SOA linuxsilo.net. hostmaster.linuxsilo.net. (
2005052401
; Serial yyyy/mm/dd/id
10800
; Refresh (3 hours)
7200
; Retry (2 hours)
1296000
; Expire (15 days)
172800 ) ; Negative Cache TTL (2 days)
@
@
@
@
@
@
@
IN
IN
IN
IN
IN
IN
IN
NS
NS
MX
MX
TXT
HINFO
LOC
@
ns1
ns2
mx1
mx2
www
www2
webmail
IN
IN
IN
IN
IN
IN
IN
IN
ns1.linuxsilo.net.
ns2.linuxsilo.net.
20 mx1.linuxsilo.net.
30 mx2.linuxsilo.net.
"Linux Silo Dot Net"
"Intel Pentium IV" "Debian Linux"
39 34 58 N 2 38 2 E 100m 10000m 20m 100m
A
A
A
A
A
A
A
A
66.79.182.201
66.79.182.201
213.96.79.79
66.79.182.201
213.96.79.79
66.79.182.201
66.79.182.201
66.79.182.201
ssh.tcp SRV 0 0 22 linuxsilo.net.

smtp.tcp SRV 0 0 25 mx1.linuxsilo.net.
http.tcp SRV 0 3 80 linuxsilo.net.
http.tcp SRV 0 1 80 www2.linuxsilo.net.
https.tcp SRV 1 0 443 linuxsilo.net.
pop3s.tcp SRV 0 0 995 mx1.linuxsilo.net.
*.tcp SRV 0 0 0 .
*.udp SRV 0 0 0 .
Se comentan acto seguido todas y cada una de las directivas y opciones de estos ficheros de configuracin (un
punto y coma, ";", indica que todo lo que hay a su derecha es un comentario):
1. $TTL 604800: directiva obligatoria a partir de la versin 9 de Bind (RFC1035 y RFC2308), indica el tiempo
de vida (TTL, del ingls, Time To Live) de la informacin contenida en el fichero. Es decir, el tiempo mximo
de validez, tras el cual deber refrescarse o actualizarse (para comprobar que no haya cambiado). Es lo que
se conoce como cach positiva/negativa (del ingls, positive/negative caching), como se especifica en el
RFC2308. Por defecto se usan segundos (604800 segundos equivale a siete das exactos), pero pueden
usarse tambin semanas ($TTL 1w), das ($TTL 7d), horas ($TTL 168h) y minutos ($TTL 10080m).
Estas abreviaturas se usan asimismo en el registro SOA, que se explica a continuacin.
Otra directiva interesante, aunque no se use en los ejemplos, es $INCLUDE <zone-file>, que hace que
named incluya otro fichero de zona en el lugar donde la directiva se usa. Esto permite almacenar parmetros
de configuracin comunes a varias subzonas en un lugar separado del fichero de la zona principal.
2. @ IN SOA linuxsilo.net. hostmaster.linuxsilo.net.: el registro SOA (del ingls, Start Of
21/10/2014 2:11
7 de 32
Authority) se encuentra siempre tras las directivas y proclama informacin relevante sobre la autoridad de
un dominio al servidor de nombres. Es siempre el primer recurso en un fichero de zona. El smbolo "@"
(arroba) equivale a la directiva $ORIGIN (o el nombre de la zona si dicha directiva no se ha usado - caso
ms frecuente) como espacio de nombres de dominio definido por este registro. Este sera el esqueleto de
este registro:
@ IN SOA <primary-name-server> <hostmaster-email> (
<serial-number>
<time-to-refresh>
<time-to-retry>
<time-to-expire>
<minimum-TTL> )
El servidor de nombres primario que es el autorizado de este dominio se usa en <primary-name-server>
y el correo electrnico de la persona a contactar acerca de este espacio de nombres (del ingls,
namespace) se sustituye en <hostmaster-email> (ntese que no tiene porqu corresponder con una
direccin del propio dominio).
El campo <serial-number> es un nmero que se incrementa cada vez que se modifica un fichero de una
zona, de forma que Bind se d cuenta de que tiene que recargar esta zona. Se recomienda usar la fecha de
modificacin en formato AAAAMMDD, donde AAAA es el ao en formato de cuatro cifras, MM es el mes en
dos cifras, y DD es el da de mes en dos cifras, seguido de un nmero de dos cifras, empezando por el 01.
De este modo se podrn realizar hasta cien cambios por da. El campo <time-to-refresh> le dice a los
servidores secundarios (esclavos) cunto tiempo deben esperar antes de preguntar a su servidor principal
(maestro) si se ha hecho algn cambio en la zona. El valor del campo <serial-number> es usado por los
esclavos para determinar si se est usando informacin anticuada que deba actualizarse.
El campo <time-to-retry> especifica a los servidores esclavos el intervalo de tiempo a esperar antes de
solicitar una actualizacin en el caso de que el servidor de nombres principal no est respondiendo. Si el
servidor maestro no ha respondido a la peticin de actualizacin antes de que expire el tiempo del campo
<time-to-expire>, el esclavo dejar de actuar como servidor el autorizado de ese espacio de nombres
(zona). El campo <minimum-TTL> solicita a otros servidores de dominio que almacenen en su cach la
informacin de esta zona durante al menos la cantidad de tiempo en l especificada.
Ntese que el campo <primary-name-server> termina en un punto, que es obligatorio poner, y que
representa, segn lo explicado en el apartado introductorio del artculo, el servidor de nombres raz.
Asimismo, este punto aparecer en todas las referencias explcitas al dominio a lo largo del fichero. Cuando
se configura un host o subdominio, por ejemplo ftp, se hace una referencia implcita y Bind aade
automticamente el dominio, que saca de la "@" del registro SOA. En cualquier caso, es posible usar
referencias implcitas o explcitas indistintamente.
3. NS ns1.linuxsilo.net. y NS ns2.linuxsilo.net.: indican los servidores de nombre que tienen
autoridad sobre el dominio. Ntese que la arroba nos ahorra tener que escribir el nombre del dominio
completo. De hecho, el prefijo, IN tambin es prescindible. Esta omisin es posible gracias a que Bind toma
las caractersticas omitidas del registro SOA anterior, es decir, @ IN. Desde luego, ambas formas son
correctas.
4. MX 20 ns1.linuxsilo.net.: se trata de un registro MX (del ingls, Mail eXchanger) e indica dnde
mandar el correo destinado a un espacio de nombres controlado por esta zona. El dgito que sigue a la
palabra MX representa la prioridad respecto a otros registros MX para la zona, que se especificaran en
posteriores lneas (MX 30 ns2.linuxsilo.net.), siguiendo el mismo formato pero variando dicho dgito
(incrementndolo a medida que pierdan prioridad frente a anteriores registros). Es decir, cuanto ms bajo es
el valor de preferencia, mayor prioridad adquiere.
5. TXT "LinuxSilo.net DNS server": este es un registro a descriptivo, en texto plano (del ingls, plain
text), del servidor. Puede usarse libre y arbitrariamente para propsitos diversos. Aparecer como resultado
de una consulta sobre este tipo de registro hecha al servidor de nombres sobre esta zona.
6. HINFO "Intel Pentium IV" "Debian Linux": otro registro, tambin a ttulo informativo y totalmente
opcional (del ingls, Host INFOrmation), cuyo propsito es informar sobre el hardware y el sistema
operativo, en este orden, delimitados por dobles comillas y separados por un espacio o tabulador, de la
mquina sobre la cual el servidor de nombres se ejecuta. Tanto este tipo de registro (HINFO) como el
anterior (TXT) pueden usarse en cada uno de los subdominios (no nicamente en el dominio principal de la
21/10/2014 2:11
zona), como se ver ms abajo.

7. LOC 39 34 58 N 2 38 2 E 100m 10000m 20m 100m: registro de localizacin geogrfica del servidor,
de nuevo opcional, que es usado por las herramientas de representacin grfica de localizaciones de
servidores, por ejemplo las de la asociacin CAIDA (del ingls, Cooperative Association for Internet Data
Analysis) y otras. Puede encontrarse informacin sobre este tipo de registro en el RFC1876. Las
coordenadas (latitud, longitud y dimetro del objeto) se encuentran en formato WGS-84 (del ingls, World
Geodetic System, del ao 1984). La localizacin usada en el artculo corresponde a Palma, Mallorca, Islas
Baleares, Espaa.
El formato a seguir es el siguiente: <owner><TTL><class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2
[m2 [s2]] {"E"|"W"} alt["m"] [siz["m"] [hp["m"] [vp["m"]]]] ). Donde:
Parmetro Significado
Unidad
Valores
Comentario
d1
Latitud (grados)
0..90
Porcin en grados de la latitud
m1
Latitud
(minutos)
'
0..59
Porcin en minutos de la latitud. Si se

omite se toma por defecto 0'
s1
Latitud
(segundos)
"
0..59,999
N/S
Latitud
(hemisferio)
d2
Longitud
(grados)
0..180
Porcin en grados de la longitud
m2
Longitud
(minutos)
'
0..59
Porcin en minutos de la longitud. Si se

omite se toma por defecto 0'
s2
Longitud
(segundos)
"
0..59,999
Porcin en segundos de la longitud. Si

se omite se toma por defecto 0"
E/W
N/S
Longitud
E/W
Porcin en segundos de la latitud. Si se

omite se toma por defecto 0"
Hemisferio terrestre norte/sur
Longitud E=este/W=oeste
alt
Altitud
-100000.00 ..
42849672,95
siz
Tamao
0..90000000,00
Dimetro de la esfera que contiene el

punto indicado. Si se omite se toma por
defecto 1 m.
hp
Precisin
horizontal
0..90000000,00
Precisin horizontal en metros. Si se

omite se toma por defecto 10.000 m.
vp
recisin vertical
0..90000000,00
Precisin vertical en metros. Si se omite

se toma por defecto 10 m.
Altitud con precisin de 0.01 m.
8. localhost A 127.0.0.1: registro que relaciona el host local con su IP de loopback.

9. linuxsilo.net. A 66.79.182.201: registro que relaciona el nombre de dominio de segundo nivel (el
"principal" de la zona) con la IP donde est hospedado. Este es el registro ms usado, pues cualquier
peticin a linuxsilo.net ser resuelta mediante este registro, se use el protocolo de comunicaciones que se
use (por ejemplo, http://linuxsilo.net).
10. ns1 A 66.79.182.201: a partir de aqu empieza la traduccin de subdominios del dominio para el cual
somos el autorizado: los dominios de tercer nivel y sucesivos. Fjese el lector en que debe crearse un registro
para cada uno, sin posibilidad de "agrupar" de ningn modo. Asimismo, ntese que, al ser subdominios de la
zona, se ha omitido el sufijo linuxsilo.net., que se encuentra implcito debido a que no termina en "." (punto).
Es simplemente una cuestin de claridad y ahorro de espacio, pues las representaciones en ambas zonas
son - repetimos de nuevo - igualmente correctas. Otros registros similares se citan, agrupados, a
continuacin:
8 de 32
21/10/2014 2:11
9 de 32
ns2
A
TXT
HINFO
www A
pop3 A
smtp A
ftp A
ts
A
TXT
HINFO
213.96.79.79
"LinuxSilo.net
"Intel Pentium
66.79.182.201
66.79.182.201
66.79.182.201
66.79.182.201
213.96.79.79
"LinuxSilo.net
"Intel Pentium
secondary nameserver"
MMX" "Debian Linux"
Team Speak server"

MMX" "Debian Linux"
Dese cuenta el lector de que se han usado dos direcciones IP distintas, lo que indicara a priori que, en
realidad, todos estos hosts (dominios de tercer nivel) se encuentran tan slo en dos mquinas distintas. Pero
esto no tiene porqu ser cierto, pues podra tenerse una misma IP pblica pero varias mquinas sirviendo los
distintos puertos usados en estos servicios, gracias a la accin de un router.
A propsito del concepto de alias (www, pop3, smtp y ftp son de hecho el mismo host) existe una
controvertida discusin sobre si es mejor usar el tipo de registro CNAME (del ingls, Canonical NAME) o IN
A. Muchos gurs de Bind recomiendan no usar registros CNAME en absoluto, si bien esa discusin se
escapa de los objetivos de este artculo. En cualquier caso, es muy recomendable seguir la regla de que los
registros MX, CNAME y SOA nunca deben referenciar un registro CNAME, sino exclusivamente algo con un
registro tipo "A". Por lo tanto, no es aconsejable usar:
web CNAME www
Pero s sera correcto:
web CNAME ns
Tambin es seguro asumir que un CNAME no es un host adecuado para una direccin de correo electrnico:
webmaster@www.linuxsilo.net, sera incorrecta dada la configuracin de arriba. La manera de evitar esto es
usar registros "A" (y quizs algunos otros tambin, como el registro MX) en su lugar. El autor de este artculo
se decanta por el uso de IN A y recomienda dicha prctica.
Traduccin inversa.
En estos momentos, los programas son ya capaces de convertir los nombres en linuxsilo.net y balearikus-party.org
a direcciones a las cuales pueden conectarse. Pero tambin se requiere una zona inversa, capaz de permitir al DNS
convertir una direccin en un nombre. Este nombre es usado por muchos servidores de diferentes clases (FTP, IRC,
WWW y otros) para decidir si quieren "hablar" con el cliente o no y, si es el caso, quizs incluso cunta prioridad se
le debe asignar. Para poder tener acceso completo a todos estos servicios en Internet es necesario una zona
inversa.
En el fichero /etc/bind/named.conf hallamos varias zonas inversas que vienen por defecto con la instalacin, justo
debajo de dos lneas de comentario como estas:
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
Ah podemos encontrar la traduccin de zonas inversas para localhost, 127.in-addr.arpa,
0.in-addr.arpa y 255.in-addr.arpa, que no es necesario modificar para nada excepto en el primer caso.
Tras ellas deberemos aadir nuestra zona: 38.127.217.in-addr.arpa (recurdese que se escriben en orden
inverso, como se explica en el apartado introductorio de este artculo):
zone "38.127.217.in-addr.arpa" {
type master;
file "/etc/bind/db.217.127.38";
};
La sintaxis es idntica a la utilizada en las zonas de traduccin de nombres explicadas en el punto anterior, y los
comentarios anteriores mantienen su validez aqu. Pasemos a ver el contenido del fichero /etc/bind/db.217.127.38:
;
; BIND reverse data file for zone 217.127.38
;
21/10/2014 2:11
10 de 32
$TTL 604800
2001081501
; Serial
10800
; Refresh (3 hours)
7200
; Retry (2 hours)
1296000
; Expire (15 days)
@
IN NS ns1.linuxsilo.net.
NS ns2.linuxsilo.net.
156 IN PTR ns1.linuxsilo.net.
Este sera el aspecto de la zona inversa localhost, que deberemos modificar ligeramente a partir del original:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. hostmaster.linuxsilo.net. (
2001061501
; Serial
604800
; Refresh
86400
; Retry
2419200
; Expire
604800 ) ; Negative Cache TTL
IN NS ns1.linuxsilo.net.
1 IN PTR localhost.ns1.linuxsilo.net.
El mapeado inverso de la direccin del host local (127.0.0.1) nunca cambia, por lo que los tiempos entre cambios
son largos. Ntese el nmero de serie, que codifica la fecha: el fichero fue cambiado por ltima vez durante el
verano del 2001, fecha en que el servidor fue creado. Ntese asimismo que slo el servidor maestro se lista en el
dominio localhost. El valor de "@" aqu es 0.0.127.in-addr.arpa.
De nuevo, los conceptos son los mismos (la "@" - arroba - indica el dominio de la zona linuxsilo.net., el "." - punto del final hace referencia al servidor de nombres raz y el registro "SOA" tiene exactamente la misma estructura y
funcionalidad), excepto las dos ltimas lneas:
1. @ IN NS ns1.linuxsilo.net. y NS ns2.linuxsilo.net.: indican a qu servidores de nombres
debe preguntarse por la traduccin inversa de una direccin IP de esta zona.
2. 156 IN PTR ns1.linuxsilo.net.: este es el registro que se usar para devolver el nombre que
queremos que corresponda con la direccin IP que nos pertenece (cuidado al crear estos registros, pues
debe hacerse referencia exclusivamente a direcciones IP que sean de nuestra propiedad o provocaramos un
conflicto). En este caso se indica que la direccin 156 (implcitamente se le aade el sufijo .38.127.217.inaddr.arpa, lo que indica que se trata de "nuestra" direccin IP 66.79.182.201) equivale al host
ns1.linuxsilo.net.
Es obvio que aqu "falta informacin", pues la direccin IP 66.79.182.201 equivale, en realidad, a ms hosts,
tal y como hemos especificado en el fichero /etc/bind/db.linuxsilo.net. Esto es cierto, pero el autor es de la
opinin de que es redundante aadir lneas del estilo:
156 IN
156 IN
156 IN
156 IN
[..]
PTR
PTR
PTR
PTR
ftp.linuxsilo.net.
pop3.linuxsilo.net.
smtp.linuxsilo.net.
www.linuxsilo.net.
Es decir, se estima ms adecuado especificar un nico FQDN por IP. Por supuesto, si se poseyera un rango
de direcciones IP, por ejemplo de 66.79.182.201 a 217.127.38.160, ambos inclusive, apareceran registros
similares a los siguientes (variaran en funcin del caso concreto):
156
157
158
159
160
IN
IN
IN
IN
IN
PTR
PTR
PTR
PTR
PTR
ns1.linuxsilo.net.
ftp.linuxsilo.net.
smtp.linuxsilo.net.
ssh.linuxsilo.net.
www.linuxsilo.net.
21/10/2014 2:11
11 de 32
Para este ejemplo, se deduce que la zona linuxsilo.net. est dividida en cinco mquinas distintas, una para
cada uno de los servicios mencionados (NS, FTP, SMTP, SSH y WWW, respectivamente).
Por qu la traduccin inversa no funciona? Hay una serie de "atenciones especiales" que prestar en este punto
que a menudo se pasan por alto al configurar un servidor de nombres de este tipo. Se discuten a continuacin dos
errores comunes en las traducciones inversas:
1. La zona inversa no ha sido delegada. Cuando se solicita un rango de direcciones IP y un nombre de
dominio a un proveedor de servicios, el nombre de dominio es generalmente delegado por norma. Una
delegacin es el servidor de nombres especfico que permite ir saltando de un servidor de nombres a otro tal
y como se explica en la seccin introductoria de este artculo.
La zona inversa tambin debe ser delegada. Si se obtiene la red 217.127.38 con el dominio linuxsilo.net a
travs de un proveedor, es preciso que dicho proveedor aada un registro NS para nuestra zona inversa as
como para nuestra zona directa. Si se sigue la cadena desde in-addr.arpa hacia arriba hasta llegar a nuestra
red, probablemente se encontrar una fractura en la cadena, muy probablemente a la altura de nuestro
proveedor de servicios. Habiendo encontrado el eslabn roto, contacte con su proveedor de servicios y
pdales que corrijan el error.
2. Su subred no pertenece a una clase definida. Este es un concepto ms avanzado, pero las subredes sin
clase (del ingls, classless subnet) son muy comunes en la actualidad y probablemente tenga una si la suya
es una empresa pequea.
Una subred sin clase es lo que consigue que Internet siga funcionando hoy en da. Hace algunos aos se
discuta mucho sobre la falta de direcciones IP. Los cerebros del IETF (del ingls, Internet Engineering
Task Force), que mantienen Internet funcionando, se exprimieron la cabeza y hallaron la solucin al
problema, aunque a cierto coste. El precio es que se obtiene menos que una subred de tipo "C" y algunas
cosas pueden dejar de funcionar.
La primera parte del problema es que su ISP debe entender la tcnica utilizada. No todos los pequeos
proveedores de servicios tienen un conocimiento prctico de su funcionamiento, por lo que quizs deba usted
explicrselo y ser algo insistente (aunque asegrese primero que lo entiende). Entonces, ellos debern
preparar una zona inversa en su servidor cuya correctitud puede ser examinada mediante la utilidad dig del
paquete dnsutils.
La segunda y ltima parte del problema es que usted debe entender la problemtica y su solucin. Si no est
seguro, haga aqu una pausa y busque ms informacin sobre ello. Slo entonces, debera usted configurar
su zona inversa para su red sin clase.
Pero hay an otra trampa oculta en este concepto. Los servidores de nombres de dominio antiguos no sern
capaces de seguir el registro CNAME en la cadena de traducciones y errarn en la traduccin inversa de su
mquina. Esto puede terminar en la asignacin de una clase de acceso incorrecta por parte de un servicio,
una denegacin de servicio o algo a medio camino entre ambos. Si se encuentra en este caso, la nica
solucin es que su ISP inserte directamente su registro PTR directamente en su zona de red sin clase en
lugar de usar registros CNAME.
Algunos ISP ofrecen diversas alternativas para tratar este problema, como formularios web que le permitirn
introducir su mapa de registros de traduccin inversa, etc.
Servidores secundarios
Una vez se han configurado correctamente las zonas en el servidor principal (maestro), es necesario preparar al
menos un servidor secundario (esclavo), que proporcionar robustez y fiabilidad. Si el servidor maestro cae los
usuarios an sern capaces de obtener informacin del esclavo acerca de las zonas que se representan. El servidor
esclavo debera estar lo ms lejos posible del maestro, debiendo ambos compartir la menor cantidad posible de las
siguientes caractersticas: suministro elctrico, red de rea local (LAN, del ingls, Local Area Network), ISP, ciudad
y pas. Si todas ellas son distintas entre el maestro y el esclavo, entonces se tiene un servidor secundario realmente
bueno.
Un servidor esclavo es simplemente un servidor de nombres que replica los ficheros de las zonas de un maestro. Se
configuran tal que as:
zone "balearikus-party.org" {
type slave;
21/10/2014 2:11
12 de 32
file "sec.balearikus-party.org";
masters { 66.79.182.201; };
};
type slave;
file "sec.linuxsilo.net";
masters { 66.79.182.201; };
};
Ntese que la estructura es la misma que para el servidor primario, cambiando nicamente algunos parmetros:
1. type slave;: indica que el servidor es esclavo para esta zona.
2. file "sec.balearikus-party.org"; y file "sec.linuxsilo.net";: como se ha explicado en la
introduccin del artculo, para seguir la poltica de directorios de Debian, los archivos temporales de las
zonas generados automticamente por el servidor secundario deben guardarse en el directorio por defecto
/var/cache/bind, por lo que tan slo se especifican ficheros (sin ruta, o con ruta relativa implcita, que es lo
mismo). Vase el punto siguiente para ms informacin sobre el contenido de estos ficheros.
3. allow-query { any; };: mismo concepto que en el servidor primario.
4. masters { 66.79.182.201; };: define qu servidor es maestro para esta zona (de la cual,
recordemos, se es esclavo). Podra haberse usado una ACL aqu, de la misma manera que se hace en el
/etc/bind/named.conf del maestro, pero no se ha estimado oportuno pues existe un nico maestro para
ambas zonas. De todos modos, si el lector debe administrar una red de servidores de nombres, donde el
papel de maestro y esclavo es desempeado a la vez por el mismo host en funcin de la zona, sera
entonces muy conveniente crear varias ACL, de forma que se facilite el mantenimiento y el control en la
asignacin de maestro y esclavos para cada zona.
Las dems opciones de configuracin se usaran de modo idntico al del servidor maestro, siempre y cuando las
condiciones sean las mismas. Es decir, se aplican las mismas directivas (por ejemplo, options, en la cual
incluiramos la opcin forwarders) y posibilidades.
Por ltimo, se desea destacar este apartado un aspecto que no debe pasarse por alto: las zonas inversas, aunque
especiales, tambin son zonas y deben transferirse del servidor primario a los secundarios. En este momento, el
que hasta ahora era servidor primario pasa a ser adems servidor secundario, pues ns2.linuxsilo.net es maestro de
su zona inversa (79.96.213.in-addr.arpa), que transferir a ns1.linuxsilo.net, convirtindolo en esclavo nicamente
para esa zona. Del mismo modo, ns1.linuxsilo.net actuar como maestro de su zona inversa (38.127.217.inaddr.arpa), que transferir a ns2.linuxsilo.net al igual que vena ocurriendo con las zonas balearikus-party.org y
linuxsilo.net. A continuacin se presentan los cambios en los ficheros de configuracin. En el named.conf de
ns1.linuxsilo.net:
type master;
};
type slave;
file "sec.db.213.96.79";
masters { 213.96.79.79; };
};
Y en el named.conf de ns2.linuxsilo.net:
type master;
allow-transfer { 66.79.182.201; };
};
type slave;
21/10/2014 2:11
13 de 32
file "sec.db.217.127.38";
masters { 66.79.182.201; };
};
El contenido de las zonas se mantendra exactamente igual. Tras estos cambios, en el directorio /var/cache/bind de
ns1.linuxsilo.net aparecera el fichero sec.db.213.96.79 y en el mismo directorio de ns2.linuxsilo.net aparecera el
fichero sec.db.217.127.38, todo gracias a la transferencia automtica de zonas que pasa a verse a continuacin.
Transferencia segura de zonas.

El lector se habr dado cuenta de que no se ha comentado nada de los ficheros sec.balearikus-party.org y
sec.linuxsilo.net especificados en las directivas zone del servidor secundario. Esto es debido a que usaremos un
procedimiento que permitir que esos ficheros se creen de forma automatizada a partir de los que creemos en el
servidor primario, de forma que las tareas de mantenimiento se facilitan enormemente.
Para ello, se debern haber utilizado, como se ha hecho en el ejemplo, las opciones allow-transfer {
slaves; }; y masters { 66.79.182.201; }; en las zonas definidas en los ficheros /etc/bind/named.conf de
los servidores primario y secundario, respectivamente. Esto permitir que, realizados los cambios deseados en el
fichero /etc/bind/db.balearikus-party.org o /etc/bind/db.linuxsilo.net, incluyendo el incremento del nmero de serie
identificativo del registro SOA, y habindole ordenado al servidor de nombres que recargue una, varias o todas las
zonas, estos cambios se reflejen en el secundario de forma que se generen los correspondientes ficheros
/var/cache/bind/sec.balearikus-party.org y /var/cache/bind/sec.linuxsilo.net.
Para que esta transferencia de zonas se haga de forma segura y controlada, impondremos ciertas restricciones en
el /etc/bind/named.conf y generaremos claves que nos asegurarn la privacidad en la comunicacin. Estas son las
lneas que aadiremos en el /etc/bind/named.conf del servidor primario (66.79.182.201 en el ejemplo):
controls {
inet 127.0.0.1 allow {
127.0.0.1;
}
keys {
"2002052101.linuxsilo.net.tsigkey.";
};
};
server 213.96.79.79 {
keys {
};
};
Y estas las que aadiremos en el /etc/bind/named.conf del secundario:
controls {
inet 127.0.0.1 allow {
127.0.0.1;
}
keys {
};
};
server 66.79.182.201 {
keys {
};
};
Acto seguido se explica el significado de ambas directivas:
1. controls { inet 127.0.0.1 allow { 127.0.0.1; } keys {
"2002052101.linuxsilo.net.tsigkey."; } }; es la directiva que cie el control sobre el servidor a
travs de la clave 2002052101.linuxsilo.net.tsigkey. nicamente al host local. Es decir,
deberemos habernos conectado (habitualmente de forma remota mediante SSH) al servidor y, desde all,
ejecutar los comandos que controlan las acciones de Bind (normalmente mediante la utilidad rndc, que se
explicar ms adelante). De aqu se deduce que, tanto la transferencia remota de zonas como el control
21/10/2014 2:11
14 de 32
sobre el servidor (recarga de zonas, parada, arranque, etc.) se realiza a travs de esta clave cifrada.
Adems, se deduce tambin que mediante esta restriccin no ser posible controlar Bind remotamente,
como ya se ha dicho. Esta es la opcin por defecto y la que el autor de este artculo recomienda.
2. server 213.96.79.79 { keys { "2002052101.linuxsilo.net.tsigkey."; }; }; es una
directiva que indica al servidor cundo debe usarse la clave. Al usar esta clusula se obliga al servidor a usar
cierta clave cuando se comunique con una determinada direccin IP. Para cada servidor es conveniente
especificar una directiva server, especificando la direccin IP de la otra mquina y el nombre de la clave a
utilizar. En el ejemplo se usa la misma clave para la comunicacin entre servidores y para el control del
servidor desde el host local - habiendo accedido por SSH - mediante la utilidad rndc
Ntese que, si se cambia la clave, la herramienta rndc puede dejar de funcionar correctamente. Al realizar este
proceso se recomienda para el servidor (rndc stop o /etc/init.d/bind9 stop), sustituir las claves y arrancarlo de nuevo
(/etc/init.d/bind9 start). Antes de explicar cmo crear una clave de este tipo, veamos el verdadero porqu de su
necesidad y los problemas que un fallo de seguridad podra causar.
Acerca de los puertos, Bind usa el 53 TCP para las transferencias y el 53 UDP para las consultas.
Qu es una TSIG y para qu se necesita

El DNS trabaja sobre un modelo pregunta-respuesta. Si un cliente necesita informacin del DNS, manda una peticin
al servidor de DNS y ste le devuelve una respuesta. Hasta hace poco slo era posible basarse en la direccin IP
de origen para discernir si deba o no contestarse una consulta. Pero esto no es precisamente "ideal". La
autenticacin basada nicamente en la direccin IP de origen se considera insegura. Las transacciones firmadas
(TSIG, del ingls, Transaction SIGnatures) aaden las firmas criptogrficas como mtodo de autenticacin en una
conversacin del DNS. Se usa una clave secreta compartida para establecer la confianza entre las partes
involucradas.
Las TSIG se usan para asegurar que la informacin del DNS que pretende provenir de cierto servidor es realmente
de ese servidor. Se usan principalmente para la autenticacin en la transferencia de zonas entre el servidor de
nombres primario y los secundarios. Se quiere asegurar que los servidores secundarios no sern nunca engaados
para que acepten una copia de una zona para la cual es el autorizado de un impostor que escucha en la direccin IP
del servidor primario.
Las transacciones firmadas se definen en el RFC2845.
En el ejemplo anterior se ha usado la clave tsigkey.linuxsilo.net.20010922 para autenticar el trfico del DNS entre
los dos servidores, el primario (66.79.182.201) y el secundario (213.96.79.79).
Creacin de una clave TSIG

En la instalacin por defecto del paquete Debian se facilita una clave TSIG previamente generada y totalmente
funcional. Pero es, desde luego, la misma para todo aquel que se instala ese paquete. Por lo tanto, es ms que
recomendable cambiarla. A continuacin se muestra cmo generar una clave particular y cmo usarla para que la
transferencia de zonas se haga de forma segura.
TSIG usa una clave secreta compartida que es incorporada a una dispersion (del ingls, hash) MD5 de la
informacin a ser firmada. Bind viene con una herramienta para crear este tipo de claves, llamada dnssec-keygen,
cuyos parmetros son numerosos (ejecute dnssec-keygen --help para ver la lista completa y man dnssec-keygen
para la pgina del man a propsito de esta utilidad). Estos son los pasos a seguir para crear rpidamente una
clave:
1. Mediante la ejecucin del comando dnssec-keygen -a HMAC-MD5 -b 512 -n HOST
2002052101.linuxsilo.net.tsigkey. se crea una clave llamada 2002052101.linuxsilo.net.tsigkey.
usando el algoritmo HMAC-MD5, de 512 bits (del ingls, BInary digiT) y tipo HOST (que es precisamente el
uso para el cual va destinada).
2. De los dos ficheros generados, K2002052101.linuxsilo.net.tsigkey.+157+30191.key y
K2002052101.linuxsilo.net.tsigkey.+157+30191.private, se usar slo el segundo. Se
aprovecha para mencionar que el formato de salida de los nombres de los ficheros generados es
Knnnn.+aaa+iiiii, donde nnnn es el nombre de la clave, aaa es la representacin numrica del algoritmo e iiiii
es la marca/huella del identificador de la clave (del ingls, footprint). Por supuesto, los nombres de cada
clave generada deben ser nicos, es decir, dos claves no deberan compartir jams el mismo nombre, de
aqu el nombre tan inusual que se le ha dado. La clave, propiamente dicha, es el conjunto de caracteres que
21/10/2014 2:11
15 de 32
se encuentra tras la palabra Key: en la ltima lnea del fichero con sufijo .private.
3. El siguiente paso es editar el fichero /etc/bind/rndc.key y sustituir la clave que viene por defecto por la que
acaba de ser generada. Para ello, es suficiente con cambiar el nombre de la clave por defecto de "rndc.key"
al que le hemos dado al crearla, en este caso 2002052101.linuxsilo.net.tsigkey.. Por ltimo, hay que cambiar
el valor del campo secret por el valor de la clave generada que, como se acaba de decir ms arriba, se
encuentra tras la palabra Key: en la ltima lnea del fichero terminado en .private. En el caso de ejemplo
usado para el artculo, se ha generado la clave wlnQbRQM/76rol0xGkEdm [..] MMlUFR7HpenQ==, pero el
lector no debe tomar sta como una referencia, pues variar en cada nueva generacin. Este es el contenido
del fichero K2002052101.linuxsilo.net.tsigkey.+157+30191.private:
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: wlnQbRQM/76rol0xGkEdm [..] MMlUFR7HpenQ==
Este es el contenido del fichero /etc/bind/rndc.key que viene por defecto con la instalacin del paquete
Debian:
key "rndc-key" {
algorithm hmac-md5;
secret "bsty5LYDsO8infm+n2JNsw==";
};
Y este es, finalmente, el fichero /etc/bind/rndc.key resultante del uso de la nueva clave:
key "2002052101.linuxsilo.net.tsigkey." {
algorithm hmac-md5;
secret "wlnQbRQM/76rol0xGkEdm [..] MMlUFR7HpenQ==";
};
Los dos ficheros creados al generar la clave, terminados en .key y .private, pueden ser eliminados sin problemas. El
lector, durante sus pruebas, se dar cuenta de que, si se omite el "." al final del nombre de la clave, dnssec-keygen
lo aadir automticamente, pudindose crear confusin acerca de si el nombre que corresponde a la clave
generada es con punto o sin punto al final. Llegados a este punto, el autor recomienda usar el nombre tal y como se
gener, aunque con una simple prueba de ensayo-error (comprobar que se transfieren las zonas) se puede llegar
fcilmente a la solucin correcta.
Por ltimo, resaltar que una clave secreta es eso: secreta. Por lo tanto, es preciso que sea copiada e instalada en
ambos servidores de modo seguro. Adems, se recomienda encarecidamente cambiar los permisos de los ficheros
/etc/bind/named.conf y /etc/bind/rndc.key, tanto del servidor primario como del secundario, a 600 (chmod 600
/etc/bind/named.conf y chmod 600 /etc/bind/rndc.key), de manera que sean nicamente accesibles por el usuario
root.
La verificacin de una TSIG requiere la posibilidad de escribir un fichero temporalmente. Asegrese de que named
tiene permisos de escritura en su directorio por defecto (clusula directory de la directiva options, que en Debian es,
por defecto, /var/cache/bind/). La implementacin de Microsoft de las TSIG no usa el algoritmo del RFC2845
(HMAC-MD5). El GSS-TSIG de Microsoft no cumple el estndar y, consecuentemente, no interoperar
adecuadamente con Bind.
Ms informacin en los documentos RFC2535, RFC2845 y RFC2539
Comentarios sobre la actualizacin dinmica, la seguridad de las TSIG y las ACL

1. Es crtico que la clave sea guardada en secreto, lo que significa, por ejemplo, que:
a. named.conf y rndc.key no deben tener permisos de lectura para nadie que no sea named o el usuario
que ejecute rndc o nsupdate.
b. la clave no debe ser transmitida por emails, a menos que estn cifrados.
c. cualquiera a quien le d esta clave es de confianza: por ello, dsela exclusivamente a quienes la
necesiten, y nunca a personas de las que desconfe.
d. debe considerar cambiar de clave cada cierto tiempo, despus de cambios en el personal, o si se
tienen sospechas de que se pueda haber comprometido el secreto.
2. Si ambos hosts estn en la misma subred, es ms difcil monitorizar (del ingls, spoofing) la direccin IP que
hacerse con una copia de la clave (por ejemplo si los routers en contacto con el exterior filtran IPs
21/10/2014 2:11
monitorizadas), de modo que una ACL de direcciones IP sera ms efectiva.

3. Es igualmente vlido especificar una ACL o una clave TSIG. Por ejemplo allow-update {key updater;
updaters; };, que significara que tanto la TSIG como la ACL de direcciones IP son vlidas para las
actualizaciones.
4. No es posible requerir a la vez una TSIG y control de acceso por IP. Los desarrolladores de Bind no creen
que esto sea til, pues ellos se concentran en el control a nivel de usuario ms que a nivel de host de cara a
las actualizaciones dinmicas (de aqu el nfasis puesto en la nueva poltica de actualizaciones que permite a
los usuarios con direcciones IP dinmicas actualizar sus registros en el DNS).
5. Las actualizaciones dinmicas no pueden aadir o eliminar dominios, tan slo registros de esos dominios.
6. Un host cliente que quiera actualizar un servidor Bind nicamente necesita el binario nsupdate y la clave
apropiada. No se requieren otros binarios o libreras (del ingls, libraries) adicionales.
7. nsupdate soporta el parmetro "-d" para tareas de depuracin (del ingls, debugging).
8. nsupdate tambin puede usar TCP (del ingls, Transmission Control Protocol) en lugar de UDP (del ingls,
User Datagram Protocol) para las actualizaciones (parmetro "-v"), lo que proporciona un mejor rendimiento
si son muchas las actualizaciones a realizar y mayor seguridad ya que TCP es un protocolo orientado a
conexin. Adems, una conexin TCP tiene la posibilidad de ser dirigida (del ingls, piped) a travs de un
canal (del ingls, tunnel) SSH (del ingls, Secure SHell)para ms seguridad (encriptacin y control de
acceso).
9. La poltica de actualizaciones es una nueva caracterstica de Bind 9 que permite que las actualizaciones se
restrinjan a ciertos nombres especficos. Por ejemplo, para permitir que un usuario de ADSL (del ingls,
Asymmetric Digital Subscriber Line) o DHCP (del ingls, Dynamic Host Configuration Protocol) pueda
actualizar el nombre de su propio host (es decir, aquellos a que cambian de direccin IP). Con esta poltica
de actualizaciones, puede configurarse una lista de claves por host y permitir a cada clave que actualice
nicamente el host o zona asociada.
Riesgos a los que expone un Bind inseguro

Es realmente necesario preocuparse tambin por el DNS? Bien, un DNS comprometido puede exponerse a
algunos riesgos interesantes:
1. Un atacante puede obtener informacin muy interesante si se permiten transferencias de zonas: la lista
completa de hosts y encaminadores (del ingls, routers) con sus direcciones IP, nombres y, posiblemente,
comentarios indicando su situacin, etc.
2. Denegacin de servicio (del ingls, Denial of service): si todos sus servidores de DNS caen,
Su sitio web (del ingls, website) ya no es visible (los otros websites no pueden traducir su direccin
IP).
Los correos electrnicos ya no pueden ser enviados (algunos sitios en Internet con los cuales se
intercambia informacin a menudo habrn guardado en su cach los registros de DNS, pero eso no
durar ms que unos pocos das).
Un atacante podra inciar un falso servidor de DNS que finge ser el suyo y enva informacin de DNS
falsa a Internet acerca de su dominio. Es decir, prdida de integridad - vese la siguiente seccin.
3. Prdida de integridad: si un atacante puede cambiar los datos del DNS o facilitar (mediante spoofing) a otros
sitios falsa informacin (esto se conoce como envenenamiento de DNS (del ingls, DNS poisoning), la
situacin se vuelve muy peliaguda:
Falsificar (del ingls, fake) su website, de manera que parezca el suyo, y capturar las entradas de los
usuarios que iban destinadas a su sitio, por lo que se estara hablando de robar cualquier cosa, desde
nombres de usuario (del ingls, logins) y contraseas (en ingls, passwords) hasta nmeros de
tarjetas de crdito.
Todo el correo podra ser redirigido a un servidor repetidor (del ingls, relay) que podra copiar,
16 de 32
21/10/2014 2:11
cambiar o borrar correo antes de pasarlo a su sitio.

Si su cortafuegos (del ingls, firewall) o cualquier host accesible desde Internet usa nombres de host
de DNS (del ingls, DNS hostnames) para autenticarse o para relaciones de confianza, stas pueden
ser completamente comprometidas, especialmente si un dbil filtro de paquetes es quien protege los
servidores de Internet y la Intranet. Imagine un proxy web configurado para permitir peticiones proxy
slo desde *.midominio.com. El atacante aade su host al dominio, por lo que el proxy web pasa a
permitir peticiones que provengan de l, permitiendo al atacante acceso por HTTP a la Intranet.
Imagine un administrador de sistemas que usa SSH (gran invento criptogrfico), pero los hosts
cortafuegos tienen un .shosts confiando en admin.midominio.com, donde admin es la estacin de
trabajo del administrador. Si el atacante puede sustituir la entrada para admin.midominio.com en el
DNS, pasa a tener un acceso libre y sin necesidad de contrasea a los hosts del cortafuegos.
El DNS se ha convertido en el objetivo favorito de los hackers, como prueban las herramientas para realizar ataques
automticos y los gusanos que usan los fallos del DNS que aparecieron durante el invierno de 2001.
Entonces, qu medidas es necesario tomar?

Los riesgos de Bind pueden ser reducidos considerablemente con algunas medidas de prevencin:
1. Aislamiento de los recursos: use un servidor dedicado y asegurado para el DNS de Internet, no lo comparta
con otros servicios y, especialmente, no permita el acceso remoto de usuario. Minimizar los servicios y
usuarios significa reducir la cantidad de software ejecutndose y, por lo tanto, la probabilidad de exponerse a
ataques de red. La separacin previene contra la posibilidad de que otros servicios o usuarios localicen
debilidades en el sistema y las usen para atacar a Bind.
2. Redundancia: instale un secundario en una conexin a Internet diferente (rama alejada de su empresa, otro
ISP, etc.). Si su sitio cae, al menos el resto de sitios no pensarn que usted ha "dejado de existir", sino que
tan slo creern que "no est disponible", por lo que, por ejemplo, sus emails no se perdern sino que
entrarn en una cola de espera (tpicamente de hasta cuatro das).
3. Use la ltima versin.
4. Control del acceso: restrinja la transferencia de zonas para minimizar la cantidad de informacin que est
disponible en su red para los atacantes. Considere el uso de transacciones firmadas. Considere restringir o
no permitir las consultas recursivas.
5. Ejecute Bind con los mnimos privilegios: como usuario no root, con una umask muy restrictiva (por ejemplo,
177).
6. Mayor aislacin de recursos: ejecute Bind en un entorno (del ingls, jail) chroot, de modo que sea mucho
ms difcil que un demonio Bind comprometido dae el sistema operativo o comprometa otros servicios.
7. Configure Bind para que no informe de su versin. Algunas personas no creen en esta medida, pues es
"seguridad por ocultacin", pero entienda que, al menos, ayudar contra jovencillos con scripts que rastrean
la red buscando objetivos obvios. Defenderse de los profesionales es otro asunto.
8. Deteccin: monitorice los logs buscando actividad inusual y cambios no autorizados en el sistema mediante
un analizador de integridad.
9. Mantngase continuamente al da de las novedades y asegrese que se le notifica la salida de nuevos
problemas de Bind en un tiempo razonable.
Servidores recursivos y no recursivos.

Los servidores de nombres pueden actuar recursivamente o no permitirla. Si un servidor no recursivo tiene la
respuesta a una peticin cacheada de una transaccin previa o es el autorizado del dominio al cual la consulta
pertenece, entonces proporciona la respuesta apropiada. De otro modo, en lugar de devolver una contestacin real,
devuelve una referencia al servidor autorizado de otro dominio que sea ms capaz de saber la respuesta. Un cliente
de un servidor no recursivo debe estar preparado para aceptar referencias y actuar en consecuencia.
Aunque los servidores no recursivos puedan parecer perezosos, tienen habitualmente un buen motivo para
deshacerse del trabajo extra. Los servidores raz y los servidores de ms alto nivel son todos no recursivos, pero es
que 10.000 consultas por segundo bien son una excusa para serlo.
17 de 32
21/10/2014 2:11
18 de 32
Un servidor recursivo devuelve nicamente respuestas reales o mensajes de error. Se encarga de seguir las
referencias por si mismo, descargando al cliente de esa tarea. El procedimiento bsico para traducir una consulta
es, esencialmente, el mismo; la nica diferencia es que el servidor de nombres se preocupa de de hacerse cargo de
las referencias en lugar de devolverlas al cliente.
Localizacin de servicios
Un registro SRV especifica la localizacin de los servicios ofrecidos por un dominio. Por ejemplo, el registro SRV
permite consultar un dominio remoto directamente y preguntarle por el nombre de su servidor FTP. Hasta ahora, en
la mayora de ocasiones, haba que probar suerte. Para contactar el servidor FTP de un dominio remoto, uno
esperaba que el administrador de sistemas de ese dominio hubiese seguido el estndar (el gusto mejor dicho)
actual y tuviese un CNAME para ftp en su servidor de DNS.
Los registros SRV adquieren mucha importancia en este tipo de consultas y son realmente una mejor manera para
los administradores de sistemas de trasladar servicios y controlar su uso. Sin embargo, deben ser solicitados y
analizados explcitamente por los clientes, por lo que sus efectos se irn viendo gradualmente a medida que pase el
tiempo.
Los registros SRV se parecen a registros MX generalizados con campos que permiten al administrador local guiar y
balancear la carga de las conexiones provenientes del mundo exterior. El formato es
servicio.proto.nombre [ttl] IN SRV pri wt puerto destino
donde servicio es uno de los servicios definidos en la base de datos de nmeros asignada por la IANA, proto puede
ser tcp o udp, nombre es el dominio al cual el servicio hace referencia, pri es una prioridad al estilo de los registros
MX, wt es el peso usado para balancear la carga entre diferentes servidores, puerto es el puerto en el cual el
servicio escucha, y destino es el nombre de host del servidor en el cual se provee ese servicio. El registro A del
destino habitualmente es devuelto de forma automtica junto a la respuesta envada a una consulta SRV. Un valor
"0" para el parmetro wt significa que no se realiza ningn tipo especial de balanceo de carga. Un valor de "." para
el destino significa que el servicio no se ejecuta en ese sitio.
En la zona linuxsilo.net del ejemplo, adaptado del RFC2052 (donde se define SRV), se tiene lo siguiente:
ftp.tcp
ssh.tcp
telnet.tcp
smtp.tcp
SRV
SRV
SRV
SRV
0
0
0
0
0
0
0
0
21
22
23
25
ftp.linuxsilo.net.
linuxsilo.net.
linuxsilo.net.
smtp.linuxsilo.net.
; 3/4 de las conexiones al principal, 1/4 al secundario

http.tcp
SRV 0 3 80
linuxsilo.net.
http.tcp
SRV 0 1 80
ns2.linuxsilo.net.
; para que funcionen tanto http://www.linuxsilo.net como http://linuxsilo.net
http.tcp.www
SRV 0 3 80
linuxsilo.net.
http.tcp.www
SRV 0 1 80
ns2.linuxsilo.net.
; servidor principal en
mquina y otro puerto
https.tcp
SRV 1 0
https.tcp
SRV 2 0
https.tcp.www
SRV 1 0
https.tcp.www
SRV 2 0
pop3s.tcp
SRV 0 0
*.tcp
*.udp
el puerto 443, secundario - en caso de fallo - en otra

443
4443
443
443
995
SRV 0 0 0
SRV 0 0 0
linuxsilo.net.
ns2.linuxsilo.net.
linuxsilo.net.
ns2.linuxsilo.net.
pop3.linuxsilo.net.
.
.
Este ejemplo ilustra el uso tanto el parmetro wt (del ingls, weigth) para HTTP como el parmetro de prioridad
para HTTPS. Ambos servidores HTTP sern usados, dividindose el trabajo entre ellos. El servidor secundario
ns2.linuxsilo.net slo ser usado para HTTPS cuando el principal no est disponible. Todos los servicios no
especificados estn excluidos. El hecho de que el demonio de, por ejemplo, finger no aparezca en el DNS no signifia
que no se est ejecutando, sino tan slo que no se podr localizar ese servicio a travs de DNS.
Microsoft usa los registros SRV estndar en Windows 2000, pero los inserta en el sistema de DNS de una manera
incompatible e indocumentada.
21/10/2014 2:11
19 de 32
Tipos de registros del DNS
Zona
Bsicos
Seguridad
Tipo
Nombre
Funcin
SOA
Start Of Authority
Define una zona representativa del DNS
NS
Name Server
Identifica los servidores de zona, delega subdominios
Direccin IPv4
Traduccin de nombre a direccin
AAAA
Direccin IPv6 original Actualmente obsoleto
A6
Direccin IPv6
Traduccin de nombre a direccin IPv6
PTR
Puntero
Traduccin de direccin a nombre
DNAME Redireccin
Redireccin para las traducciones inversas IPv6
MX
Mail eXchanger
Controla el enrutado del correo
KEY
Clave pblica
Clave pblica para un nombre de DNS
NXT
Next
Se usa junto a DNSSEC para las respuestas negativas
SIG
Signature
Zona autenticada/firmada
Opcionales CNAME Canonical Name
Nicks o alias para un dominio
LOC
Localizacin
Localizacin geogrfica y extensin
RP
Persona responsable
Especifica la persona de contacto de cada host
SRV
Servicios
Proporciona la localizacin de servicios conocidos
TXT
Texto
Comentarios o informacin sin cifrar
Vistas
Las vistas (del ingls, views) son una nueva caracterstica de Bind 9 que permite mostrar a las mquinas internas
una visin distinta de la jerarqua de nombres de DNS de la que se ve desde el exterior (se entiende "interior" y
"exterior" respecto del router que da salida a la empresa a Internet). Por ejemplo, le permite revelar todos los hosts
a los usuarios internos pero restringir la vista externa a unos pocos servidores de confianza. O podra ofrecer los
mismos hosts en ambas vistas pero proporcionar registros adicionales (o diferentes) a los usuarios internos.
Este tipo de configuracin (llamada en ocasiones "DNS partido", del ingls "split DNS") se est haciendo muy
popular. En el pasado, se implementaba configurando servidores separados para las versiones interna y externa de
la realidad. Los clientes locales apuntaban a los servidores de distribucin que contenan la versin interna de la
zona, mientras que los registros NS de la zona padre apuntaban a servidores que corran la versin externa. La
sentencia view de Bind 9 simplifica la configuracin permitiendo tener juntos ambos conjuntos de datos en la misma
copia de named. named busca correspondencias en listas de direcciones para adivinar qu clientes deben recibir
qu datos.
La sentencia view empaqueta un lista de acceso que controla quin ve la vista, algunas opciones que se aplican a
todas las zonas en la vista y, finalmente, las propias zonas. La sintaxis es:
view "nombre-de-la-vista" {
match-clients { address_match_list; };
opcion-de-vista; ...
sentencia-de-zona; ...
};
La clusula match-clients controla quin puede ver la vista. Las vistas son procesadas en orden secuencial, por
lo que las ms restrictivas deben ir primero. Las zonas en distintas vistas pueden tener el mismo nombre. Las vistas
son una proposicin de todo o nada; si las usa, todas las sentencias zone en su fichero named.conf deben
aparecer dentro del contexto de una vista.
Este es el ejemplo para los dominios linuxsilo.net y balearikus-party.org, creado a partir de la documentacin de
21/10/2014 2:11
Bind 9 que sigue el esquema de DNS partido descrito ms arriba. Las dos vistas definen ambas zonas, pero con
diferentes registros.
acl "lan" {
192.168.0.0/24;
};
// View for all computers on local area network
view "internal" {
match-clients { lan; };
recursion yes;
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// Resto de zonas inversas por defecto omitidas para abreviar
type master;
};
type slave;
file "sec.db.213.96.79";
masters { 213.96.79.79; };
};
type master;
};
// add entries for other zones below here
type master;
file "/etc/bind/db.balearikus-party.org.internal";
};
type master;
file "/etc/bind/db.linuxsilo.net.internal";
};
};
// View for all computers outside the local area network
view "external" {
match-clients { any; };
recursion no;
// prime the server with knowledge of the root servers
zone "." {
type hint;
20 de 32
21/10/2014 2:11
21 de 32
file "/etc/bind/db.root";
};
// Resto de zonas inversas por defecto omitidas para abreviar
type master;
};
type slave;
file "sec.db.213.96.79";
masters { 213.96.79.79; };
};
// add entries for other zones below here
type master;
file "/etc/bind/db.balearikus-party.org";
};
zone "clan-bin.org" {
type master;
file "/etc/bind/db.clan-bin.org";
};
};
La red local interna es 192.168.0.0, de aqu que se use una lista de acceso que engloba a cualquier host que sea
de esa red (red 192.168.0.0, mscara 255.255.255.0, especificada como suma de unos binarios, es decir, 24).
Esta nueva situacin nos lleva a precisar una nueva definicin de zona inversa, la correspondiente a la red local
0.168.192.in-addr.arpa, que se muestra a continuacin:
;
; BIND reverse data file for zone 192.168.0
;
$TTL 604800
2001081501
; Serial
10800
; Refresh (3 hours)
7200
; Retry (2 hours)
1296000
; Expire (15 days)
@ IN NS ns1.linuxsilo.net.
1 IN PTR ns1.linuxsilo.net.
Ntese que, ahora, las zonas inversas, tanto las que se proporcionan con la instalacin por defecto para el
funcionamiento bsico como las definidas por el administrador, se reparten adecuadamente entre ambas vistas. En
cambio, las zonas directas son duplicadas, una ocurrencia para cada vista. Por supuesto, los ficheros de zona
apuntados contienen registros distintos, en consonancia con la vista. Acto seguido se facilitan los registros de los
ficheros de zonas directas internas (las externas se mantienen igual, por lo que son vlidas las expuestas
anteriormente en este artculo).
;
; BIND data file for zone balearikus-party.org, internal view
;
$TTL 604800
@ IN SOA balearikus-party.org. hostmaster.linuxsilo.net. (
2002051001
10800
; Refresh (3 hours)
7200
; Retry (2 hours)
1296000
; Expire (15 days)
21/10/2014 2:11
22 de 32
172800 ) ; Negative Cache TTL(2 days)

balearikus-party.org. IN NS ns1.linuxsilo.net.
balearikus-party.org. IN MX 5 ns1.linuxsilo.net.
localhost
IN A 127.0.0.1
balearikus-party.org. IN A 192.168.0.1
www
pop3
smtp
ftp
IN
IN
IN
IN
A
A
A
A
192.168.0.1
192.168.0.1
192.168.0.1
192.168.0.1
;
; BIND data file for zone linuxsilo.net, internal view
;
$TTL 604800
2002051001
10800
; Refresh (3 hours)
7200
; Retry (2 hours)
1296000
; Expire (15 days)
172800 ) ; Negative Cache TTL(2 days)
NS ns1.linuxsilo.net.
MX 5 ns1.linuxsilo.net.
localhost
A 127.0.0.1
linuxsilo.net. A 192.168.0.1
ns1
ns2
www
pop3
smtp
ftp
ts
akane
ranma
genma
kasumi
nabiki
primetime
A
A
A
A
A
A
A
A
A
A
A
A
A
192.168.0.1
213.96.79.79
192.168.0.1
192.168.0.1
192.168.0.1
192.168.0.1
213.96.79.79
192.168.0.1
192.168.0.6
192.168.0.5
192.168.0.4
213.96.79.79
192.168.0.3
La herramienta RNDC
El comando rndc es una til herramienta para manipular named. La siguiente tabla muestra algunas de las opciones
que acepta. Los parmetros que provocan la creacin de ficheros lo harn en el directorio especificado como home
de named en el /etc/bind/named.conf (clusula directory, cuyo valor por defecto es /var/cache/bind en Debian).
Comando Funcin
help
Lista los opciones de rndc disponibles
status
Muestra el estado actual del named en ejecucin
trace
Incrementa el nivel de depuracin en 1
notrace
Desactiva la depuracin
dumpdb
Vuelca la base de datos de DNS a named_dump.db
stats
Vuelca estadsticas a named.stats
reload
Recarga named.conf y los ficheros de zonas
reload zona
Recarga slo la zona especificada
21/10/2014 2:11
23 de 32
restart
Reinicia named, vaciando la cach
querylog
Activa el seguimiento de las consultas entrantes
Rndc usa el puerto 953 UDP para el control remoto. Si se siguen las pautas mostradas en este artculo, no es
necesario que ese puerto sea accesible desde el exterior - configurarlo en el router - pues el control se har
siempre desde el host local y las transferencias de zonas se realizan por el puerto 53 TCP
Personalizacin de los logs

Los logs en Bind se configuran con la sentencia logging en el named.conf. Primero se definen canales, que son
los posibles destinos de los mensajes. Luego se les dice a varias categors de mensajes que vayan a un canal
particular.
Trmino
Significado
canal
Un lugar a donde los mensajes pueden ir: syslog, un fichero o /dev/null
categora
Una clase de mensajes que Bind puede generar; por ejemplo, mensajes sobre actualizaciones
dinmicas o mensajes acerca de respuestas a consultas
mdulo
El nombre del mdulo de origen que genera un mensaje
lugar
El nombre de un lugar syslog. DNS no tiene su propio destino, por lo que tendrn que escogerse los
estndar.
importancia Lo "malo" que es un mensaje de error; a lo que syslog se refiere como prioridad
Cuando se genera un mensaje, se le asigna una categora, un mdulo y una importancia en su punto de origen.
Despus es distribuido a todos los canales asociados con esa categora y mdulo. Cada canal tiene un filtro de
importancia que define qu nivel de importancia debe tener un mensaje para pasar. Los canales que llevan al syslog
tambin son filtrados de acuerdo a las reglas del /etc/syslog.conf.
Este es el esqueleto de una sentencia logging:
logging {
definicin_de_canal;
definicin_de_canal;
...
category nombre_categora {
nombre_canal;
nombre_canal;
...
};
};
Una definicin_de_canal es ligeramente diferente dependiendo de si el canal es un fichero o un canal syslog. Se
debe elegir file o syslog para cada canal; un canal no puede ser ambas cosas a la vez.
channel "nombre_del_canal" {
file ruta [versions nmvers | unlimited] [size sizespec];
syslog facility;
severity importancia;
print-category yes | no;
print-severity yes | no;
print-time yes | no;
};
En un fichero, nmvers especifica cuntas versiones de copia de un fichero guardar, y sizespec dice lo grandes
que pueden llegar a ser esos ficheros (por ejemplo, 2048, 100k, 20m, 15g, unlimited, default).
En el caso de syslog, facility especifica que nombre de lugar usar al guardar el mensaje. Puede ser cualquiera de
los estndar. En la prctica, slo daemon y de local0 a local7 son elecciones razonables.
El resto de sentencias en una definicin de canal son opcionales. importancia puede tomar los valores (en orden
descendente) critical, error, warning, notice, info o debug (con un nivel numrico opcional, por ejemplo
21/10/2014 2:11
24 de 32
severity debug 3). El valor dynamic tambin es vlido y representa el nivel de depuracin actual del servidor.
Las diversas opciones print aaden o suprimen prefijos del mensaje. El syslog incluye la fecha y hora y el host de
origen en cada mensaje guardado, pero no la importancia o la categora. En Bind 9, el fichero de origen (mdulo)
que gener el mensaje tambin est disponible como opcin print. Adquiere sentido entonces activar
print-time slo para canales fichero, pues los registros del syslog ponen la fecha y hora ellos solos.
A continuacin se listan los cuatro canales predefinidos por defecto, que debern ser suficiente para la mayora de
casos:
Nombre del canal Lo que hace

default_syslog
Manda importancia info al syslog con el destino daemon
default_debug
Guarda en el fichero named.run, importancia puesta a dynamic
default_stderr
Manda mensajes a la salida de error estndar de named, importancia info
null
Se descartan todos los mensajes
La configuracin de logging por defecto de Bind 9 es:

logging {
category default {
default_syslog;
default_debug;
};
};
Debera echar un vistazo a los ficheros log cuando haga grandes cambios en Bind, y quizs incrementar el nivel de
depuracin. Entonces, reconfigrelo para preservar nicamente mensajes importantes una vez named est estable.
Algunos de los mensajes de log ms comunes se listan a continuacin:
Lame server. Si recibe este mensaje acerca de una de sus zonas es que ha configurado mal alguna cosa. El
mensaje es relativamente poco importante si es sobre alguna zona en Internet, pues significa que es
problema de algn otro.
Bad referral. Este mensaje indica una descoordinacn en la comunicacin entre los servidores de nombres de
una zona.
Not authoritative for. Un servidor esclavo no es capaz de obtener informacin representativa de una zona.
Quizs est apuntando al maestro equivocado o quizs el maestro ha tenido algn problema cargando esa
zona.
Rejected zone. named rechaz esa zona porque contena errores.
No NS RRs found. El fichero de una zona no tiene registros NS tras el registro SOA. Podra ser que no estn
o que no empiezan con un tabulador o un espacio en blanco. En este ltimo caso, los registros no se
interpretan correctamente.
No default TTL set.. La mejor manera de establecer el TTL por defecto es con una clusula $TTL al principio
del fichero de la zona. Este mensaje de error indica que el $TTL no est presente.
No root name server for class. Su servidor est teniendo problemas para encontrar los servidores raz.
Compruebe su fichero /etc/bind/db.root y la conexin a Internet de su servidor.
Address already in use. El puerto en el que named quiere ejecutarse ya est siendo usado por otro proceso,
probablemente otra copia de named. Si no ve otra copia de named en memoria, podra haberse colgado,
dejando el socket de control de rndc abierto.
Taxonoma de un servidor de nombres
Tipo de servidor
Descripcin
21/10/2014 2:11
Ingls
Espaol
authoritative
autorizado
Un representante oficial de una zona.
master
maestro
El repositorio principal de los datos de una zona; lee los datos de ficheros
del disco.
slave
esclavo
Obtiene los datos del maestro.
stub
N/A
Parecido a un esclavo, pero slo copia los datos del servidor de nombres
(no los datos del equipo).
distribution
distribucin
Un servidor que slo es visible

oculto").
(a)
desde dentro de un dominio (un "servidor
nonauthoritative(b) no autorizado
Responde una consulta a partir de su cach; desconoce si los datos son

an vlidos.
caching
reserva
Guarda los datos de consultas previas; habitualmente no tiene zonas

locales.
forwarder
redireccionador
Realiza consultas en nombre de muchos clientes; mantiene una cach

grande.
recursive
recursivo
Consulta en su nombre hasta que devuelve una respuesta o un error.
nonrecursive
no recursivo
Le pasa a otro servidor si no es capaz de responder a la consulta.
a. Un servidor de distribucin puede ser visible por cualquiera que conozca su direccin IP.
b. Hablando estrictamente, "no autorizado" es un atributo de la respuesta a una consulta DNS, no de un servidor.
Tipos de sentencias usadas en el named.conf
Sentencia Descripcin
include
Interpola un fichero (p.e., claves de confianza accesibles slo por named).
options
Establece opciones globales de configuracin del servidor de nombres y valores por defecto.
server
Especifica opciones preservidor.
key
Define informacin de autenticacin.
acl
Define listas de control de acceso.
zone
Define una zona de registro de recursos.
trusted-keys Usa claves previamente configuradas.

controls
Define canales utilizados para controlar el servidor de nombres con rndc.
logging
Especifica categoras de logs y sus destinos.
view
Define una vista de un espacio de nombres.
Ejemplo de personalizacin de logs

// Definimos tres canales de logs (mensajes importantes del
// syslog, depuracin media y mensajes de carga de zonas)
// y luego les asignamos categoras a cada uno.
logging {
channel syslog_errors {
syslog local1;
severity error;
};
channel moderate_debug {
severity debug 3;
// nivel 3 de depuracin
25 de 32
21/10/2014 2:11
26 de 32
file "debug.log";
// al fichero debug.log
print-time yes;
// fecha actual a las entradas del log
print-category yes; // imprimir el nombre de la categora
print-severity yes; // imprimir el nivel de gravedad
};
channel no_info_messages {
syslog local2;
severity notice;
};
category parser {
syslog_errors;
default_syslog;
};
category lame-servers { null; }; // No guardar este tipo en los logs
category load { no_info_messages; };
category default {
default_syslog;
moderate_debug;
};
};
Tabla de caracteres especiales utilizados en los registros de recursos
Caracter Significado
;
Introduce un comentario
El nombre de dominio actual
()
Permite partir una sentencia en ms de una lnea
Comodn (slo en el nombre del campo).
Tabla de mecanismos de seguridad en el named.conf
Caracterstica Sentencias Qu especifica

allow-query
options, zone
Quin puede consultar la zona o servidor.
allow-transfer
options, zone
Quin puede solicitar transferencias de zonas.
allow-update
zone
Quin puede hacer actualizaciones dinmicas.
blackhole
options
Qu servidores deben ignorarse completamente.
bogus
server
Qu servidores no deben ser jams consultados.
acl
varios
Listas de control de acceso.
Tabla de categoras de logging en Bind 9
Categora
Qu incluye
default
Categors sin una asignacin explcita de canal.
general
Mensajes sin clasificar.
config
Anlisis y procesado de ficheros de configuracin.
queries/client
Un mensaje corto de log por cada consulta que el servidor recibe.
dnssec
Mensajes de DNSSEC.
lame-servers
Servidores que se supone que sirven una zona, pero no lo estn .
(a)
21/10/2014 2:11
27 de 32
statistics
Estadsticas agrupadas del servidor de nombres.
panic
Errores fatales (duplicados en esta categora).
update
Mensajes sobre actualizaciones dinmicas.
ncache
Mensajes sobre cach negativa.
xfer-in
Transferencias de zonas que el servidor est recibiendo.
xfer-out
Transferencias de zonas que el servidor est enviando.
db/database
Mensajes sobre operaciones con bases de datos.
packet
Volcados de paquetes recibidos y enviados(b).
notify
Mensajes acerca del protocolo de notificaciones "zona modificada".
cname
Mensajes del tipo "...points to a CNAME".
security
Peticiones aprobadas/denegadas.
os
Problemas del sistema operativo.
insist
Comprobaciones de fallos de consistencia interna.
maintenance
Sucesos peridicos de mantenimiento.
load
Mensajes de carga de zonas.
response-checks Comentarios sobre paquetes de respuesta malformados o invlidos.

resolver
Traduccin de DNS, p.e., bsquedas recursivas para clientes.
network
Operaciones de red.
a. Bien la zona padre o bien la zona hija podran ser la culpable; es imposible determinarlo sin investigarlo.
b. Obligatoriamente debe ser un canal simple.
Chroot
Este apartado describe algunas precauciones extras relacionadas con la seguridad que puede usted tomar al
instalar BIND. Se explica cmo configurar BIND de manera que resida en una jaula chroot, lo que significa que no
pueda ver o acceder a ficheros fuera de su propio reducido rbol de directorios. Tambin se explica cmo
configurarlo para que se ejecute como un usuario diferente a root.
La idea que hay detrs de un chroot es bastante sencilla: acotar el acceso que un individuo malicioso pueda obtener
explotando vulnerabilidades de BIND. Por esa misma razn es bueno ejecutarlo como un usuario no root (en
GNU/Debian Linux a partir de la versin 9.2.4-5). Cuando se ejecuta BIND (o cualquier otro proceso) en una jaula
chroot, el proceso simplemente es incapaz de ver cualquier otra parte del sistema de ficheros que se encuentre
fuera de la jaula. Por ejemplo, en este apartado configuraremos BIND en modo chroot en el directorio /var/lib
/named. Entonces, para BIND, el contenido de este directorio ser la raz /. Nada fuera de este directorio le ser
accesible. Muy probablemente ya se ha encontrado usted ante una jaula chroot con anterioridad, por ejemplo al
acceder mediante FTP a un sistema pblico.
Este proceso debera considerarse un complemento de las precauciones de seguridad habituales (ejecutar la ltima
versin, usar listas de control de acceso, etc.), y nunca como una manera de reemplazarlas.
Crear el usuario
Tal y como se menciona en la introduccin, no es una buena idea ejecutar BIND como root. Por ello, antes de
empezar, se crear un usuario separado para BIND. Ntese que nunca debera usarse un usuario genrico existente
del tipo nobody para este propsito. Este proceso es realizado automticamente por el script de instalacin del
paquete Debian, pero a continuacin se resume el procedimiento manual para conseguirlo.
Es necesario aadir una lnea parecida a esta en el fichero /etc/passwd:
21/10/2014 2:11
28 de 32
bind:x:103:103::/var/cache/bind:/bin/false
Y una similar a la siguiente en el fichero /etc/group:
bind:x:103:
En este ejemplo no slo vamos a ejecutar BIND como un usuario no root, sino que tambin lo haremos en un
entorno chroot (la instalacin por defecto en Debian nicamente cubre el primer aspecto en la actualidad).
Estas lneas crean un usuario y un grupo llamados bind para BIND. El lector debe asegurarse de que tanto el UID
(del ingls, User Identifier) como el GID (del ingls, Group Identifier) son nicos en su sistema (ambos 103 en
este ejemplo). La consola se ha dejado en /bin/false porque este usuario jams tendr necesidad de hacer un login.
Estructura de directorios
Acto seguido es necesario crear una estructura de directorios para la jaula chroot en la cual se ejecutar BIND.
Puede hacerse en cualquier lugar del sistema de ficheros; aquellos ms paranoicos incluso querrn ponerlo en un
volumen separado. Se usar /var/lib/named. Empiece por crear la siguiente estructura de directorios:
/var/lib/
+--- named
+--- dev
+--- etc
+--- var
+--- run
+--- cache
+--- bind
+--- usr
+--- sbin
Mediante el comando mkdir podra crearse la mencionada estructura de directorios. Estos son los comandos a
ejecutar y sus parmetros:
# mkdir -p /var/lib/named
# cd /var/lib/named
# mkdir -p dev etc/bind var/run var/cache/bind usr/sbin
Copiar los ficheros necesarios
Asumiendo que usted ya ha realizado una instalacin estndar de BIND 9 y que lo est usando, tendr, por lo tanto,
un fichero named.conf y diversos ficheros de zonas. Esos ficheros deben ser movidos (o copiados, para mayor
seguridad) dentro de la jaula chroot, de modo que BIND sea capaz de encontrarlos. named.conf y los ficheros de
zonas van dentro de /var/lib/named/etc/bind. Por ejemplo:
# cp -p /etc/bind/* /var/lib/named/etc/bind/
# cp -a /var/cache/bind/* /var/lib/named/var/cache/bind/
# cp /usr/sbin/named /var/lib/named/usr/sbin/
Adems, ser preciso copiar tambin las librers que el ejecutable /usr/sbin/named necesita, que pueden obtenerse
ejecutando el comando ldd /usr/sbin/named. Con los siguientes comandos crearemos los subdirectorios necesarios
y copiaremos las librers:
#
#
#
#
#
#
#
#
#
#
#
#
#
cd /var/lib/named
mkdir -p usr/lib lib
cp /usr/lib/liblwres.so.1 usr/lib/
cp /usr/lib/libdns.so.5 usr/lib/
cp /usr/lib/libcrypto.so.0.9.6 usr/lib/
cp /usr/lib/libisccfg.so.0 usr/lib/
cp /usr/lib/libisccc.so.0 usr/lib/
cp /usr/lib/libisc.so.4 usr/lib/
cp /lib/libnsl.so.1 lib/
cp /lib/libpthread.so.0 lib/
cp /lib/libc.so.6 lib/
cp /lib/libdl.so.2 lib/
cp /lib/ld-linux.so.2 lib/
BIND va a necesitar escribir dentro de los subdirectorios /var/lib/named/var/cache/bind y /var/lib/named/var/run, en
21/10/2014 2:11
29 de 32
el primero para guardar las zonas de las cuales est actuando como servidor esclavo y en el segundo para guardar
informacin estadstica de su ejecucin. Por lo tanto, es pertinente ejecutar las dos instrucciones siguientes:
# chown -R bind:bind /var/lib/named/var/cache/bind
# chown -R bind:bind /var/lib/named/var/run
Ficheros de sistema
Una vez que BIND est ejecutndose en la jaula chroot, no ser capaz de acceder a ficheros que se encuentren
fuera de la jaula de ningn modo. Sin embargo, necesita acceder a algunos ficheros esenciales. Uno de los ficheros
que necesita dentro de su jaula es /dev/null. Otros son /dev/zero y /dev/random. Pueden usarse los siguientes
comandos:
#
#
#
#
mknod
mknod
mknod
chmod
/var/lib/named/dev/null c 1 3
/var/lib/named/dev/random c 1 8
/var/lib/named/dev/zero c 1 5
666 /var/lib/named/dev/{null,random,zero}
Tambin ser necesario otro fichero en el directorio /etc dentro de la jaula. Es preciso copiar /etc/localtime ah
dentro de modo que BIND guarde los logs con fechas correctas. El siguiente comando se resolvera el problema:
# cp /etc/localtime /var/lib/named/etc/
Logging
Normalmente, BIND guarda los logs a travs de syslogd, el demonio del sistema encargado de guardar los logs. Sin
embargo, este tipo de logging se lleva a cabo enviando las entradas del log a un socket especial, /dev/log. Debido a
que se encuentra fuera de la jaula, BIND no va a poder usarlo. Afortunadamente, hay una solucin para este
problema.
Todo lo que hay que hacer es aadir el parmetro -a /var/lib/named/dev/log a la lnea de comandos que lanza el
syslogd. En Debian, este script se encuentra en /etc/init.d/sysklogd. Debe buscar las lneas siguientes:
# Options for start/restart the daemons
# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD=""
Y cambiar la ltima de las lneas por esta:
SYSLOGD="-a /var/lib/named/dev/log"
Una vez reiniciado el demonio, debera ver un fichero en /var/lib/named/dev llamado log, tal que as:
srw-rw-rw- 1 root root 0 Nov 28 14:22 log
Finalmente, remarcar que, en el caso de una actualizacin del paquete sysklogd, podran perderse los cambios
realizados en dicho script por una potencial sobreescritura del fichero existente. Por lo tanto, se recomienda tener
cuidado al actualizar.
Endureciendo los permisos
Antes de nada, sintase libre de restringir acceso en todo el directorio /var/lib/named nicamente al usuario bind.
# chown bind:bind /var/lib/named
# chmod 700 /var/lib/named
Si desea aumentar an ms las restricciones, en los sistemas Linux puede conseguirse la inmutabilidad de algunos
de los ficheros usando la herramienta chattr en los sistemas de ficheros ext2 y ext3.
# cd /var/lib/named
# chattr +i etc etc/localtime var
Consulte la pgina del man para ms informacin: man chattr. Sera interesante poder hacer esto mismo sobre el
directorio dev pero, desgraciadamente, eso imposibilitara que el syslogd crease el socket dev/log. Tambin puede
elegir activar el bit de inmutabilidad en otros ficheros dentro de la jaula, como los de las zonas primarias, en el caso
21/10/2014 2:11
30 de 32
de que no vayan a cambiar.

Instalacin
Si se desea realizar una instalacin a partir de los fuentes, se recomienda usar el paquete Debian de fuentes bind9,
disponible mediante el comando apt-get source bind9. Luego tan slo sera necesario ejecutar un ./configure y un
make o, ms fcil an, dpkg-buildpackage, que nos har los dos pasos anteriores y nos dejar listos una serie de
paquetes Debian que nos evitarn tener que hacer un make install a mano.
Suponiendo que usted ya dispone de una instalacin de BIND 9 en su sistema, tan slo deber modificar
ligeramente el script de arranque del demonio para que use estos parmetros:
-u bind, que le indica a BIND el usuario con el que debe ejecutarse.
-t /var/lib/named, que le dice a BIND que haga un chroot sobre s mismo dentro de la jaula que se le ha
preparado.
-c /etc/named.conf, que le dice a BIND dnde encontrar su fichero de configuracin dentro de la jaula.
En Debian, es muy fcil cambiar el script de inicio de BIND, que encontrar en /etc/init.d/bind9, para que acepte
estas nuevas opciones. Tan slo debe buscar estas lneas:
# for a chrooted server: "-u nobody -t /var/lib/named"
OPTS=""
Y cambiar la ltima lnea por la siguiente:
OPTS="-u bind -t /var/lib/named -c etc/named.conf"
Cambie, por ltimo, el ejecutable que se llama desde ese script de /usr/sbin/named a /var/lib/named/usr/sbin
/named, de manera que sea el ejecutable de dentro de la jaula el que el script llame y no el original.
Si su versin del paquete Debian de BIND9 es la 9.2.4-5 o superior, BIND se estar ejecutando con el usuario bind y
el UID/GID 103, por lo que puede saltarse los pasos referidos a la creacin del usuario y el grupo y pasar
directamente al enjaulamiento. Si la versin de su paquete es inferior (en GNU/Debian Woody es la 9.2.4-4),
entonces deber seguir todos los pasos.
Cambios en la configuracin
Deber usted tambin cambiar o aadir unas pocas opciones a su named.conf a fin de mantener ciertos directorios
en orden. En particular, debera aadir (o cambiar, si ya las tiene) las siguientes directivas en la seccin de
opciones:
directory "/etc/bind";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
Ya que este fichero va a ser ledo por el demonio named, todas las rutas van a ser, evidentemente, relativas a la
jaula chroot. En el momento de escribir esta parte del documento, BIND 9 no soporta muchas de las estadsticas y
ficheros de volcado que las versiones previas soportaban. Presumiblemente, versiones posteriores s lo harn; si
est ejecutando una de esas versiones, quizs deba aadir algunas entradas adicionales para que BIND las escriba
en el directorio /var/run tambin.
Arrancando BIND
Ahora ya tan slo queda por hacer el paso ms elemental: arrancar de nuevo el demonio BIND. Para ello, es
preciso ejecutar el siguiente comando en una distribucin GNU/Debian Linux:
# /etc/init.d/bind start
Recursos en lnea
The DNS Resources Directory
DNS HowTo
Securing DNS with Transaction Signatures
All About DNS
DNS Cmo
21/10/2014 2:11
31 de 32
Los RFC
Los RFC que definen el sistema de DNS estn disponibles en www.rfc-editor.org. Las ideas iniciales y en desarrollo
aparecen primero como borradores y son ms tarde formalizadas como RFC. A continuacin se listan un conjunto
relacionado con Bind, incluidos los que han supuesto que Bind 9 se haya reescrito desde cero (estos documentos
estn todos en ingls):
Los originales y definitivos estndares:
1034 - Domain Names: Concepts and Facilities.
1035 - Domain Names: Implementation and Specification.
Estndares propuestos:
1995 1996 2136 2181 -
Incremental Zone Transfers in DNS.

A Mechanism for Prompt Notification of Zone Changes.
Dynamic Updates in the Domain Name System.
Clarifications to the DNS Specification.
RFC de seguimiento de nuevos estndares:

2535 2671 2672 2673 -
Domain Name System Security Extensions.

Extension Mechanisms for DNS (EDNS0).
Non-Terminal DNS Name Redirection (DNAME).
Binary Labels in the Domain Name System.
RFC diversos:
1535 - A Security Problem... with Widely Deployed DNS Software.
1536 - Common DNS Implementation Errors and Suggested Fixes.
1982 - Serial Number Arithmetic.
2536-2541 - Varios RFC sobre DNSSEC.
Tipos de registros de recursos:
1183 - New DNS RR Definitions: AFSDB, RP, X25, ISDN, RT.
1706 - DNS NSAP Resource Records.
1876 - A Means for Expressing Location Information in DNS.
2052 - A DNS RR for Specifying the Location of Services (SRV).
2168 - Resolution of Uniform Resource Identifiers using DNS.
2230 - Key Exchange Delegation Record for the DNS.
DNS e Internet:
1101 - DNS Encoding of Network Names and Other Types.
1123 - Requirements for Internet Hosts: Application and Support.
1591 - Domain Name System Structure and Delegation.
2317 - Classless in-addr.arpa Delegation.
Operaciones de DNS:
1537 1912 2182 2219 -
Common DNS Data File Configuration Errors.

Common DNS Operational and Configuration Errors.
Selection and Operation of Secondary DNS Servers.
Use of DNS Aliases for Network Services.
Otros RFC relacionados con el DNS:

1464 1713 1794 2240 2345 2352 -
Using DNS to Store Arbitrary String Attributes.

Tools for DNS debugging.
DNS Support for Load Balancing.
A Legal Basis for Domain Name Retrieval.
Domain Names and Company Name Retrieval.
A Convention for Using Legal Names as Domain Names.
Historial de revisiones
21/10/2014 2:11
Fecha
32 de 32
Versin Cambios
2002-05-27 1.0
Documento inicial
2002-05-28 1.0.1
Aadido nuevo enlace a recurso en lnea
2002-05-29 1.0.2
Correcin del protocolo usado para las transferencias de zonas.
2002-05-30 1.0.3
Diversos cambios en las zonas inversas, tanto en los ejemplos como en la explicacin
de su funcionamiento.
2002-06-01 1.0.4
Bind 9.2.4 ha sido aadido a Debian Sid. Actualizacin del artculo tras comprobar el
changelog.
2002-06-03 1.0.5
Corregidos algunos errores gramaticales y aadidos varios enlaces a referencias

usadas en el artculo.
2003-03-03 1.1
Aadidas varias secciones nuevas al artculo, principalmente tablas de resumen y el

chroot, y un ndice de contenidos.
2003-03-05 1.1.1
Corregidos algunos errores tipogrficos en la seccin de chroot.
2003-03-06 1.1.2
Corregida an ms la seccin de chroot, aadiendo las libreras a la jaula y cambiando

la ruta del ejecutable a llamar.
2005-02-22 2.0
Reescrito el artculo. Ahora se adeca a la nueva disposicin de los ficheros de

configuracin del paquete Debian de Bind 9.2.4. Se han simplificado los ejemplos para
hacerlos ms claros e ilustrativos, y se incluye un nico dominio de ejemplo, pero con
un servidor maestro y otro esclavo igualmente. Aadida ms informacin en varios
aspectos, como el de los registros DNS-LOC.
21/10/2014 2:11

El Sistema de Nombres de Dominio - Bind 9.2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

El Sistema de Nombres de Dominio - Bind 9.2

Caricato da

Copyright:

Formati disponibili

El sistema de nombres de dominio: Bind 9.2.

El sistema de nombres de dominio: Bind 9.2.4

El sistema de nombres de dominio: Bind 9.2.4

El sistema de nombres de dominio: Bind 9.2.4

4. Enrutamiento mejorado para el correo electrnico.

Requerimientos y datos tcnicos.

Debian GNU/Linux Sarge

Traduccin de nombres a direcciones IP.

El sistema de nombres de dominio: Bind 9.2.4

Traduccin de nombres a direcciones IP.

El sistema de nombres de dominio: Bind 9.2.4

2. stacksize 30M;, que determinara un tamao de pila de treinta megabytes,

El sistema de nombres de dominio: Bind 9.2.4

ssh.tcp SRV 0 0 22 linuxsilo.net.

El sistema de nombres de dominio: Bind 9.2.4

El sistema de nombres de dominio: Bind 9.2.4

zona), como se ver ms abajo.

Porcin en grados de la latitud

Porcin en minutos de la latitud. Si se

Porcin en grados de la longitud

Porcin en minutos de la longitud. Si se

Porcin en segundos de la longitud. Si

Porcin en segundos de la latitud. Si se

Dimetro de la esfera que contiene el

Precisin horizontal en metros. Si se

Precisin vertical en metros. Si se omite

Altitud con precisin de 0.01 m.

8. localhost A 127.0.0.1: registro que relaciona el host local con su IP de loopback.

El sistema de nombres de dominio: Bind 9.2.4

Team Speak server"

El sistema de nombres de dominio: Bind 9.2.4

El sistema de nombres de dominio: Bind 9.2.4

El sistema de nombres de dominio: Bind 9.2.4

El sistema de nombres de dominio: Bind 9.2.4

Transferencia segura de zonas.

El sistema de nombres de dominio: Bind 9.2.4

Qu es una TSIG y para qu se necesita

Creacin de una clave TSIG

El sistema de nombres de dominio: Bind 9.2.4

Comentarios sobre la actualizacin dinmica, la seguridad de las TSIG y las ACL

El sistema de nombres de dominio: Bind 9.2.4

monitorizadas), de modo que una ACL de direcciones IP sera ms efectiva.

Riesgos a los que expone un Bind inseguro

El sistema de nombres de dominio: Bind 9.2.4

cambiar o borrar correo antes de pasarlo a su sitio.

Entonces, qu medidas es necesario tomar?

Servidores recursivos y no recursivos.

El sistema de nombres de dominio: Bind 9.2.4

; 3/4 de las conexiones al principal, 1/4 al secundario

el puerto 443, secundario - en caso de fallo - en otra

El sistema de nombres de dominio: Bind 9.2.4

Tipos de registros del DNS

Define una zona representativa del DNS

Identifica los servidores de zona, delega subdominios

Traduccin de nombre a direccin

Direccin IPv6 original Actualmente obsoleto

Traduccin de nombre a direccin IPv6

Traduccin de direccin a nombre

Redireccin para las traducciones inversas IPv6

Controla el enrutado del correo

Clave pblica para un nombre de DNS

Se usa junto a DNSSEC para las respuestas negativas

Opcionales CNAME Canonical Name