Contents

El DNS es una de las aplicaciones fundamentales de Internet, con una funci’on primordial: la de traducir los nombres de los hosts a direcciones IP. El servicio de nombres de dominio es una gigantesca base de datos distribuida a nivel mundial que funciona sin pausa, est’a constantemente actualiz’andose y resuelve las consultas en tiempo real (qu’e m’as se puede pedir?).

El DNS se basa en la arquitectura cliente-servidor. En su consulta m’as frecuente, los clientes piden resoluciones de nombres de dominio y los servidores las contestan indicando sus direcciones IP. La comunicaci’on entre ambos se realiza a trav’es del UDP.

En esta sesi’on pr’actica vamos a aprender a instalar un servidor DNS y a hacer uso del mismo. Esto genera varias ventajas. La primera y la m’as interesante es que las consultas son resueltas utilizando un nodo local (en nuestra sub-red), con lo que el tiempo de acceso se minimiza cuando este nodo almacena en su cach’e una resoluci’on previa. La segunda es que descargamos de trabajo al resto de servidores de la jerarqu’ia, cosa que algunos administradores nos agradecer’an. Tambi’en aprenderemos a realizar consultas de diversa ’indole con el objetivo de aprender qu’e posibilidades ofrece el sistema DNS.

1 Los nombres de dominio

Un dominio es, b’asicamente hablando, una organizaci’on cualquiera dentro de Internet que desea ser referenciada mediante un nombre de dominio. Por ejemplo, la Universidad de Almer’ia es una organizaci’on que posee una serie de computadoras llamadas de la forma “*.ual.es”. “ual.es” es el nombre del dominio de la Universidad de Almer’ia. En la pr’actica para mucha gente es demasiado largo decir “nombre de dominio” y generalmente se dice simplemente “dominio”.

2 Dominios y subdominios

Es frecuente que un nombre de dominio conste de varios subdominios, normalmente separados por un punto. Por ejemplo, el dominio “ual.es” es en realidad un subdominio del dominio “es”.

Este hecho genera una jerarqu’ia de dominios en la que cualquier nodo p’ublico de Internet puede ser localizado. Por ejemplo, el nodo filabres.ual.es es un host de la Universidad de Almer’ia, que se trata de una universidad española.

3 La jerarqu’ia de dominios

En cada dominio normalmente se instala un servidor de nombres de dominio, tambi’en llamado servidor DNS. Dicho servidor se encarga de mantener la base de datos de registros DNS para ese dominio. Por ejemplo, en la Universidad de Almer’ia hay un servidor DNS que conoce todas las resoluciones de las direcciones IP para todos los hosts con nombres de la Universidad. En concreto, filabres.ual.es (150.214.156.2) es un servidor DNS del dominio ual.es. Otra forma de decir esto consiste en llamar a filabres.ual.es el servidor de nombres autorizado para el dominio ual.es.

4 El proceso de resoluci’on

Normalmente, cuando un servidor DNS no conoce una resoluci’on utiliza otro servidor DNS situado en un nivel superior en la jerarqu’ia de dominios para intentar resolverla (o al menos, as’i deber’ia ser). Esta pol’itica de consultas recursivas finalmente encuentra un servidor DNS que s’i conoce la resoluci’on. Entonces el registro DNS solicitado viaja desde dicho servidor DNS deshaciendo el camino hasta el servidor DNS al que inicialmente realizamos la consulta. En este proceso, cada servidor DNS actualiza su cach’e con esta informaci’on por un determinado periodo de tiempo.

Por ejemplo, cuando queremos acceder a www.nasa.gov desde un host de la Universidad de Almer’ia, dicho host deber’ia preguntar a filabres.ual.es¹ . Si filabres no almacena en su cach’e la resoluci’on² , podr’ia³ preguntar al siguiente servidor DNS en la jerarqu’ia que podr’ia ser un nodo del CICA (Centro Inform’atico Cient’ifico de Andaluc’ia). Si ’este fallara, preguntar’ia a un servidor de RedIRIS (la red acad’emica y de investigaci’on nacional), y as’i sucesivamente hasta llegar a un servidor DNS ra’iz⁴ . Si ’este falla, entonces la consulta comienza a descender por la jerarqu’ia de servidores DNS hasta llegar al responsable del dominio nasa.gov que necesariamente debe conocer la resoluci’on.

Existe una versi’on diferente de este algoritmo recursivo que se realiza una consulta iterativa. La diferencia radica en que cuando un servidor DNS falla en lugar de hacer ’el la consulta le indica al cliente a qu’e otro servidor DNS puede preguntar. Este proceso, sin embargo, no actualiza las cach’es de los servidores.

5 Instalaci’on de un servidor DNS

Para convertir un host con Linux en un servidor DNS basta con instalar el programa BIND (Berkeley Internet Name Domain) (http://www.isc.org/products/BIND):

Debian’s distros:

 

root# apt-get install bind9 bind9-doc dnsutils

Red Hat’s distros:

 

root# yum install bind bind-utils caching-nameserver system-config-bind

Gentoo’s distros:

 

root# emerge bind bind-utils

6 Configuraci’on del servidor DNS

El servidor puede configurarse para ofrecer servicio de tres formas diferentes:

1. Como servidor de nombres autorizado del dominio X: Si almacena los registros de resoluci’on para los hosts del dominio X.
2. Como servidor de nombres r’eplica: Si mantiene una copia de los registros de otro servidor DNS.
3. Como servidor s’olo cach’e: Cuando no almacena ning’un registro, excepto los adquiridos en las consultas.

La primera configuraci’on es la que utilizar’ia el administrador de una nueva red que desea que sus hosts tengan nombres de dominio asignados. En dicha configuraci’on se generar’ian los registros de resoluci’on para cada uno de estos hosts y se almacenar’ian en el servidor de nombres autorizado. Adem’as, el servidor DNS del ISP deber’ia tener en cuenta el servidor DNS instalado⁵ . Por desgracia, esto ’ultimo es imposible llevarlo a la pr’actica si no se adquiere legalmente un dominio y negociamos la delegaci’on del dominio con el correspondiente ISP.

Aunque parezca que esta forma de configurar el DNS es demasiado burocr’acica, en realidad hay razones de peso para hacerse as. Si este tema no estuviera suficientemente controlado, un usuario malicioso puede inventarse un dominio con el objetivo de introducir “ruido” en el DNS con la idea de desviar conexiones hacia un conjunto determinados de servidores (probablemente controlados por dicho usuario malicioso). Por estos motivos, en esta ocasi’on no vamos a instalar un servidor DNS autorizado. Sin embargo, bastar’ia con modificar el fichero de configuraci’on correspondiente y construir los registros DNS utilizando alguna herramienta como system-config-bind de Red Hat Linux. La parte de la delegaci’on del dominio es otro tema que ya no depende s’olo de nosotros.

La segunda configuraci’on sirve para aumentar la fiabilidad del DNS ya que permite replicar los registros de resoluci’on. As’i, si uno de los servidores de nombres autorizado fallase, el otro pasar’ia a resolver las consultas. Por ejemplo, en la Universidad de Almer’ia hay un servidor DNS autorizado para el dominio ual.es (filabres.ual.es, 150.214.156.2) y otro r’eplica (alboran.ual.es, 150.214.156.32). Instalar un servidor DNS r’eplica plantea los mismos problemas de seguridad que instalar uno autorizado y adem’as, una replicaci’on sin control constituye un buen ataque por denegaci’on de servicio. Por estos motivos, desistiremos tambi’en de realizar dicha opci’on.

Finalmente, la tercera y ’ultima configuraci’on, en la que instalamos un servidor DNS que funciona en realidad como un proxy DNS, s’i que es posible en cualquier situaci’on y tiene sentido si queremos reducir el tr’afico a trav’es del gateway de la red, descargar de trabajo a otros servidores DNS y minimizar el tiempo de resoluci’on para las m’aquinas a las que servimos. Por suerte, esta configuraci’on es la que por defecto se instala con BIND.

6.1 Configuraci’on como servidor cach’e

Como hemos indicado anteriormente, en principio no es necesario hacer ninguna modificaci’on en el fichero named.conf para conseguir que el servidor DNS funcione como un proxy DNS. Sin embargo, s’i que vamos a hacer un pequeño cambio para que BIND utilice los servidores DNS m’as pr’oximos cuando la cach’e falle.⁶ Para hacer esto hay que modificar el fichero named.conf insertando el c’odigo:

en su secci’on options. Veamos exactamente qu’e hacer en cada distribuci’on:

Debian’s:

La instalaci’on de bind crea el fichero /etc/bind/named.conf y otros dos ficheros asociados /etc/bind/named.conf.local y /etc/bind/named.conf.options. El c’odigo anterior debe insertarse en este ’ultimo fichero.

Red Hat’s:

El fichero que configura el servidor es /etc/named.conf. Para configurarlo como un servidor DNS cache ejecutar:

root# system-config-bind # Salir sin hacer ninguna modificaci’on

A continuaci’on insertar el c’odigo anterior en el fichero.

Gentoo’s:

La instalaci’on de BIND crea el fichero /etc/bind/named.conf para que funcione como un DNS cach’e. Simplemente insertaremos el c’odigo anterior en este fichero.

Finalmente hay que modificar el fichero /etc/resolv.conf indicando que ahora es localhost el servidor DNS. Si tuvi’eramos m’as hosts en nuestra red local, dicha modificaci’on deber’ia realizarse en todos ellos.

6.2 Configuraci’on como servidor del dominio X

Aunque realmente no tendra sentido crear un determinado dominio si no se le indica al resto de servidores DNS que el servidor que vamos a configurar es el responsable de ese dominio, en esta secci’on vamos a ver qu’e pasos habr’ia que realizar para llevarla a cabo.

Como ya sabemos, el fichero named.conf es le’ido por Bind cada vez que ’este arranca. Dicho fichero, por defecto, deber’ia incluir la carga del fichero named.conf.local. En este fichero se definen las zonas (dominios) locales creadas y mantenidas por el servidor de nombres que estamos configurando. En nuestro caso, supongamos que estamos declarando el dominio dominio.X. As’i, named.conf.local deber’ia tener el siguiente contenido:

donde /etc/bind/db.dominio.X contiene, a modo de ejemplo:

Este ’ultimo fichero define los par’ametros fundamentales del registro de resoluci’on para el cual nuestro servidor de nombres es el autorizado. De arriba a abajo se declaran cosas como:

TTL 9

: N’umero m’aximo de saltos a realizar en una consulta DNS.

2007110701

: El instante de creaci’on del dominio dominio.X (año, mes, d’ia e identificador).

10800

: El tiempo de frescura (medido en segundos) del registro en un servidor de nombres cach’e. 3 horas.

7200

: Ante una falta del registro, un servidor de nombres no deber’ia reclamarlo a otro servidor no antes de 2 horas.

1296000

: Los servidores de nombres borrar’an este registro de sus cach’es a los 15 d’ias.

NS

: Name Server.

MX

: Mail eXchanger.

101.102.103.103

: Direcci’on IP del host que corre nuestro servidor de nombres.

7 Configuraci’on del cliente

La ’unica opci’on de configuraci’on que permiten los clientes es la especificaci’on del (o los) servidor(es) DNS. En Linux esta informaci’on est’a declarada en el fichero:

quen es texto (ASCII) y puede ser editado como administrador.

8 Ejemplos de consultas

8.1 Cu’ales son mis servidores DNS?

A la hora de determinar el servidor DNS que estamos utilizando existen dos alternativas:

1. Acceder a esta informaci’on en los ficheros de configuraci’on correspondientes. Por ejemplo, en Linux hay que leer el fichero
   /etc/resolv.conf

   Evidentemente, esta opci’on s’olo funciona bajo Linux.

   En este fichero aparecen al menos la IP de un servidor DNS. Al primero de ellos se le llama servidor DNS primario y deber’ia ser un servidor DNS pr’oximo, por motivos de eficiencia. El resto de direcciones IP son los llamados servidores secundarios porque, en el caso de fallar el primerio, se har’ia uso de estos.

2. Utilizar programas para chequear el funcionamiento del DNS como pueden ser nslookup y dig. nslookup funciona tanto desde la l’inea de comandos como de forma interactiva. dig s’olo lo hace desde la l’inea de comandos. Indicar adem’as que el resultado de la consulta no depende del host, ni de que ’este pertenezca al dominio por el que estamos preguntando. El resultado s’olo depende del dominio por el que preguntamos. Veamos algunos ejemplos:
   # Preguntamos a nuestro servidor DNS primario  
   #  el dominio "ual.es"  
   alumno$ dig ual.es  
    
   ; <<>> DiG 9.2.4 <<>> ual.es  
   ;; global options:  printcmd  
   ;; Got answer:  
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65305  
   ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0  
    
   ;; QUESTION SECTION:  
   ;ual.es.                                IN      A  
    
   ;; AUTHORITY SECTION:  
   ual.es.                 172800  IN      SOA     filabres.ual.es.\  
   postmaster.filabres.ual.es. 2006111502 16400 7200 2592000 172800  
    
   ;; Query time: 0 msec  
   ;; SERVER: 150.214.156.2#53(150.214.156.2)  
   ;; WHEN: Thu Nov 30 10:26:33 2006  
   ;; MSG SIZE  rcvd: 80

   En esta consulta, entre mucha otra informaci’on dig indica que el servior DNS autorizado para el dominio ual.es es filabres.ual.es.

8.2 Cu’al es la dirección IP del host ...?

En la siguiente consulta preguntamos a nuestro servidores DNS primario (o en su defecto, secundario) por la dirección IP del host www.google.es:

Esta respuesta es un poco complicada por dos motivos: (1) www.google.es y www.google.com son la misma m’aquina cuando hacemos la consulta a nuestro servidor de nombres y (2), el servidor Web est’a replicado tres veces en las direcciones IP 209.85.129.104, 209.85.129.147 y 209.85.129.99. Esto puede comprobarse si preguntamos por www.google.com:

Adem’as, como puede verse www.google.com es un alias de www.l.google.com.

8.3 Cu’ales son los servidores de nombres del dominio ...?

Podemos ver que existen tres servidores de nombres autorizados para el dominio “bit.edu”.

8.4 C’omo interrogamos a otro servidor DNS?

Ahora preguntamos al servidor DNS “bitsy.mit.edu” por el host “www.google.com”:

Como podemos ver, ambas respuestas son id’enticas (como en el caso de preguntar a filabres), pero diferentes comparadas con las que devuelve nuestro servidor de nombres. Esto significa que, si nos conectamos a www.google.es desde el MIT, veremos la versi’on americana de google.

Finalmente, n’otese que el servidor DNS no devuelve las direcciones IP de las r’eplicas del servidor Web siempre en el mismo orden. Esto se utiliza para distribuir la carga.

8.5 Averiguando la jerarqu’ia de servidores DNS

Como hemos comentado anteriormente, cuando consultamos a un servidor DNS sobre una direcci’on para la cual ’el no es el servidor DNS autorizado lo m’as frecuente es que ’este tenga que consultar a otro servidor DNS (consulta recursiva) o nos indique a qu’e otro servidor DNS podemos preguntar nosotros (consulta iterativa).

Activando el flag +trace de dig podemos conocer qu’e servidores DNS se han consultado. En el siguiente ejemplo preguntamos a bitsy.mit.edu por la dirección IP del host gogh.ace.ual.es:

Como podemos ver, bitsy.mit.edu consulta (en la versi’on recursiva) al servidor de nombres ra’iz a.root-servers.net, que consulta a NS3.NIC.FR, que consulta a chico.rediris.es, que consulta a filabres.ual.es.

8.6 Resoluci’on inversa

Finalmente, tambi’en podemos interrogar al servidor DNS por el nombre de un host a partir de su direccion IP:

Como podemos ver, el host es gogh.ace.ual.es.

9 Servidores DNS en la Web

Existen servidores Web que prestan servicio DNS. Ejemplos:

Utilice algunas de estas p’aginas Web para comprobar que el resultado coincide con el que devuelve dig para una determinada consulta.

10 Cuidado con el DNS!

El DNS es uno de los servicios m’as cr’iticos que existen en Internet. A continuaci’on mostramos algunos de los riesgos m’as importantes a los que nos exponemos cuando utilizamos un servidor DNS inseguro (m’as informaci’on en BULMA (http://bulma.net/body.phtml?nIdNoticia=1334)).

1. Si definimos un dominio e instalamos un servidor DNS autorizado para el mismo, estamos obligados a ofrecer informaci’on sobre el dominio definido. Esto significa que cualquier usuario de Internet puede conocer qu’e m’aquinas y con qu’e direcciones IP existen en nuestro dominio.
2. Los servidores DNS que delegan dominios a otros servidores (es decir, que ya no son servidores autorizados para ese sub-dominio) est’an obligados a escuchar las modificaciones que en dichos dominios se producen (en caso contrario, el DNS no escalar’ia). Si no tenemos cuidado cuando configuramos nuestro servidor y no controlamos adecuadamente “la transferencia de dominio”, un hacker puede instalar un servidor DNS y hacerlo pasar por el servidor DNS autorizado de ese dominio. Si esto ocurre, puede inyectar informaci’on falsa en el sistema DNS y hacer que cuando accedamos a un host en realidad entremos en otro. Imagine lo que ser’ia acceder a nuestra cuenta bancaria a trav’es del host del hacker, creyendo que estamos enviando los datos al servidor de nuestro banco cuando en realidad lo estamos haciendo a un host que controla el hacker.

11 DNS + DHCP

Cuando utilizamos el DHCP para gestionar redes p’ublicas en las que las direcciones IP asignadas son din’amicas, podemos configurar el servidor DHCP para que avise al servidor DNS autorizado de ese dominio de los cambios que se vayan produciendo en las asignaciones de las direcciones.

Este sistema tiene una gran ventaja: se gestiona s’olo. Sin embargo, no es muy recomendable su uso cuando vamos a instalar servicios importantes en los hosts del dominio. Supongamos que en uno de estos host tenemos un servidor Web que tiene miles de accesos diarios. En esta situaci’on la dirección IP de este host est’a diseminada por las cach’es de miles de servidores DNS de toda la Internet. Si dicho host recibe una nueva IP, muchas resoluciones ser’ian incorrectas hasta que las cach’es son actualizadas.