DNS/BIND

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: 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. 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. 1. 2. 3. 4. 5. 6. 7. 8. 9. Debian GNU/Linux Sarge Bind 9.2.4 DNS Utils Bind Docs Traduccin de nombres a direcciones IP. 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.

Servicios:

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

Traduccin de nombres a direcciones IP.

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

@ ns1 ns2 mx1 mx2 www www2 webmail

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 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-nameserver> 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 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 d1 Latitud (grados) Latitud (minutos)

Unidad

Valores 0..90

Comentario Porcin en grados de la latitud Porcin en minutos de la latitud. Si se omite se toma por defecto 0' Porcin en segundos de la latitud. Si se omite se toma por defecto 0" Hemisferio terrestre norte/sur Porcin en grados de la longitud Porcin en minutos de la longitud. Si se omite se toma por defecto 0' Porcin en segundos de la longitud. Si se omite se toma por defecto 0" Longitud E=este/W=oeste

m1

'

0..59

s1

Latitud (segundos) Latitud (hemisferio) Longitud (grados) Longitud (minutos)

"

0..59,999

N/S d2

N/S 0..180

m2

'

0..59

s2

Longitud (segundos)

"

0..59,999

E/W alt

Longitud Altitud m

E/W

-100000.00 .. Altitud con

42849672,95

precisin de 0.01 m.

siz

Tamao

Dimetro de la esfera que contiene 0..90000000,0 el punto indicado. 0 Si se omite se toma por defecto 1 m. Precisin horizontal 0..90000000,0 en metros. Si se 0 omite se toma por defecto 10.000 m. Precisin vertical en 0..90000000,0 metros. Si se omite 0 se toma por defecto 10 m.

hp

Precisin horizontal

vp

recisin vertical

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: 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: [email protected], 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 balearikusparty.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.inaddr.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 ; $TTL 604800 @ IN SOA linuxsilo.net. hostmaster.linuxsilo.net. ( 2001081501 ; Serial 10800 ; Refresh (3 hours) 7200 ; Retry (2 hours) 1296000 ; Expire (15 days) 172800 ) ; Negative Cache TTL (2 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.in-addr.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.

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; file "sec.balearikus-party.org"; allow-query { any; }; masters { 66.79.182.201; }; }; zone "linuxsilo.net" { type slave; file "sec.linuxsilo.net"; allow-query { any; }; 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.in-addr.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: zone "38.127.217.in-addr.arpa" { type master; file "/etc/bind/db.217.127.38"; allow-transfer { slaves; }; }; zone "79.96.213.in-addr.arpa" { type slave; file "sec.db.213.96.79"; masters { 213.96.79.79; }; }; Y en el named.conf de ns2.linuxsilo.net: zone "79.96.213.in-addr.arpa" { type master; file "/etc/bind/db.213.96.79"; allow-transfer { 66.79.182.201; }; }; zone "38.127.217.in-addr.arpa" { type slave; 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 { "2002052101.linuxsilo.net.tsigkey."; }; }; 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 { "2002052101.linuxsilo.net.tsigkey."; }; }; server 66.79.182.201 { keys { "2002052101.linuxsilo.net.tsigkey."; }; }; 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 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 dnsseckeygen, 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 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. 2. la clave no debe ser transmitida por emails, a menos que estn cifrados. 3. 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. 4. 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. 5. 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 monitorizadas), de modo que una ACL de direcciones IP sera ms efectiva. 6. 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. 7. 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). 8. Las actualizaciones dinmicas no pueden aadir o eliminar dominios, tan slo registros de esos dominios. 9. 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. 10.nsupdate soporta el parmetro "-d" para tareas de depuracin (del ingls, debugging). 11. 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). 12.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, 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. 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 SRV 0 0 21 ftp.linuxsilo.net.

ssh.tcp telnet.tcp smtp.tcp

SRV 0 0 22 SRV 0 0 23 SRV 0 0 25

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 otra 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 443 4443 443 443 995 linuxsilo.net. ns2.linuxsilo.net. linuxsilo.net. ns2.linuxsilo.net. pop3.linuxsilo.net. . .

SRV 0 0 0 SRV 0 0 0

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.

Tipos de registros del DNS Tipo Zona SOA NS Bsicos A AAAA A6 PTR Nombre Start Of Authority Name Server Direccin IPv4 Direccin IPv6 original Direccin IPv6 Puntero Funcin Define una zona representativa del DNS Identifica los servidores de zona, delega subdominios Traduccin de nombre a direccin 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 Zona autenticada/firmada

DNAME Redireccin MX Seguridad KEY NXT SIG Mail eXchanger Clave pblica Next Signature

Opcionales CNAME Canonical Name LOC RP SRV TXT Vistas Localizacin Persona responsable Servicios Texto

Nicks o alias para un dominio Localizacin geogrfica y extensin Especifica la persona de contacto de cada host Proporciona la localizacin de servicios conocidos Comentarios o informacin sin cifrar

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 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; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 // 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 zone "38.127.217.in-addr.arpa" { type master; file "/etc/bind/db.217.127.38"; allow-transfer { slaves; }; }; zone "79.96.213.in-addr.arpa" { type slave; file "sec.db.213.96.79"; masters { 213.96.79.79; }; }; zone "0.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.0"; }; // add entries for other zones below here zone "balearikus-party.org" { type master; file "/etc/bind/db.balearikus-party.org.internal"; }; zone "linuxsilo.net" { 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; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 // 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 zone "38.127.217.in-addr.arpa" { type master; file "/etc/bind/db.217.127.38"; allow-transfer { slaves; }; }; zone "79.96.213.in-addr.arpa" { type slave; file "sec.db.213.96.79";

masters { 213.96.79.79; }; }; // add entries for other zones below here zone "balearikus-party.org" { type master; file "/etc/bind/db.balearikus-party.org"; allow-query { any; }; allow-transfer { slaves; }; }; zone "clan-bin.org" { type master; file "/etc/bind/db.clan-bin.org"; allow-query { any; }; allow-transfer { slaves; }; }; }; 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 @ IN SOA linuxsilo.net. hostmaster.linuxsilo.net. ( 2001081501 ; Serial 10800 ; Refresh (3 hours) 7200 ; Retry (2 hours) 1296000 ; Expire (15 days) 172800 ) ; Negative Cache TTL (2 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 ; Serial yyyy/mm/dd/id 10800 ; Refresh (3 hours) 7200 ; Retry (2 hours) 1296000 ; Expire (15 days) 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 IN A 192.168.0.1

pop3 IN A 192.168.0.1 smtp IN A 192.168.0.1 ftp IN A 192.168.0.1 ; ; BIND data file for zone linuxsilo.net, internal view ; $TTL 604800 @ IN SOA linuxsilo.net. hostmaster.linuxsilo.net. ( 2002051001 ; Serial yyyy/mm/dd/id 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 help status trace notrace dumpdb stats reload restart querylog

Funcin Lista los opciones de rndc disponibles Muestra el estado actual del named en ejecucin Incrementa el nivel de depuracin en 1 Desactiva la depuracin Vuelca la base de datos de DNS a named_dump.db Vuelca estadsticas a named.stats Recarga named.conf y los ficheros de zonas Reinicia named, vaciando la cach Activa el seguimiento de las consultas entrantes

reload zona Recarga slo la zona especificada

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 canal categora mdulo lugar importancia

Significado Un lugar a donde los mensajes pueden ir: syslog, un fichero o /dev/null Una clase de mensajes que Bind puede generar; por ejemplo, mensajes sobre actualizaciones dinmicas o mensajes acerca de respuestas a consultas El nombre del mdulo de origen que genera un mensaje El nombre de un lugar syslog. DNS no tiene su pr pio destino, por o lo que tendrn que escogers los estndar. e 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 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 default_syslog default_debug default_stderr null

Lo que hace Manda importancia info al syslog con el destino daemon Guarda en el fichero named.run, importancia puesta a dynamic Manda mensajes a la salida de error estndar de named, importancia info 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

Ingls authoritative master slave stub

Espaol autorizado maestro esclavo N/A Un representante oficial de una zona. El repositorio principal de los datos de una zona; lee los datos de ficheros del disco. Obtiene los datos del maestro. Parecido a un esclavo, pero slo copia los datos del servidor de nombres (no los datos del equipo). Un servidor que slo es visible(a) desde dentro de un dominio (un "servidor oculto"). Responde una consulta a partir de su cach; desconoce si los datos son an vlidos. Guarda los datos de consultas previas; habitualmente no tiene zonas locales. Realiza consultas en nombre de muchos clientes; mantiene una cach grande. Consulta en su nombre hasta que devuelve una respuesta o un error. Le pasa a otro servidor si no es capaz de responder a la consulta.

distribution nonauthoritative(
b)

distribucin

no autorizado reserva redireccionador recursivo no recursivo

caching forwarder recursive nonrecursive

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 include options server key acl zone Descripcin Interpola un fichero (p.e., claves de confianza accesibles slo por named). Establece opciones globales de configuracin del servidor de nombres y valores por defecto. Especifica opciones preservidor. Define informacin de autenticacin. Define listas de control de acceso. Define una zona de registro de recursos. Define canales utilizados para controlar el servidor de nombres con rndc. Especifica categoras de logs y sus destinos.

trusted-keys Usa claves previamente configuradas. controls logging

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 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 allow-query allow-transfer allow-update blackhole bogus Qu especifica

options, zone Quin puede consultar la zona o servidor. options, zone Quin puede solicitar transferencias de zonas. zone options server Quin puede hacer actualizaciones dinmicas. Qu servidores deben ignorarse completamente. Qu servidores no deben ser jams

consultados. acl varios Listas de control de acceso.

Tabla de categoras de logging en Bind 9 Categora default general config queries/client dnssec lame-servers statistics panic update ncache xfer-in xfer-out db/database packet notify cname security os insist maintenance load response-checks resolver network Qu incluye Categors sin una asignacin explcita de canal. Mensajes sin clasificar. Anlisis y procesado de ficheros de configuracin. Un mensaje corto de log por cada consulta que el servidor recibe. Mensajes de DNSSEC. Servidores que se supone que sirven una zona, pero no lo estn(a). Estadsticas agrupadas del servidor de nombres. Errores fatales (duplicados en esta categora). Mensajes sobre actualizaciones dinmicas. Mensajes sobre cach negativa. Transferencias de zonas que el servidor est recibiendo. Transferencias de zonas que el servidor est enviando. Mensajes sobre operaciones con bases de datos. Volcados de paquetes recibidos y enviados(b). Mensajes acerca del protocolo de notificaciones "zona modificada". Mensajes del tipo "...points to a CNAME". Peticiones aprobadas/denegadas. Problemas del sistema operativo. Comprobaciones de fallos de consistencia interna. Sucesos peridicos de mantenimiento. Mensajes de carga de zonas. Comentarios sobre paquetes de respuesta malformados o invlidos. Traduccin de DNS, p.e., bsquedas recursivas para clientes. 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: 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 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 per misos

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

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. 1995 - Incremental Zone Transfers in DNS. 1996 - A Mechanism for Prompt Notification of Zone Changes. 2136 - Dynamic Updates in the Domain Name System. 2181 - Clarifications to the DNS Specification. 2535 - Domain Name System Security Extensions. 2671 - Extension Mechanisms for DNS (EDNS0). 2672 - Non-Terminal DNS Name Redirection (DNAME). 2673 - Binary Labels in the Domain Name System. 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. 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.

Estndares propuestos:

RFC de seguimiento de nuevos estndares:

RFC diversos:

Tipos de registros de recursos:

2230 - Key Exchange Delegation Record for the DNS. 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. 1537 - Common DNS Data File Configuration Errors. 1912 - Common DNS Operational and Configuration Errors. 2182 - Selection and Operation of Secondary DNS Servers. 2219 - Use of DNS Aliases for Network Services. 1464 - Using DNS to Store Arbitrary String Attributes. 1713 - Tools for DNS debugging. 1794 - DNS Support for Load Balancing. 2240 - A Legal Basis for Domain Name Retrieval. 2345 - Domain Names and Company Name Retrieval. 2352 - A Convention for Using Legal Names as Domain Names.

DNS e Internet:

Operaciones de DNS:

Otros RFC relacionados con el DNS: