Las máquinas de Internet están identificadas por direcciones IP, que constan de 32 bits, aunque habitualmente se representan en un formato más sencillo de manejar para los humanos, que es el de cuatro números decimales separados por puntos. En realidad no hay una dirección IP por cada máquina de Internet, sino una (o más) por cada "punto de acceso a red", o interfaz de red: por ejemplo un router o encaminador tiene varias tarjetas de red, y asociada a cada una de ellas tiene una dirección IP. Por ejemplo, veamos la dirección IP de nuestro servidor:

Dirección IP (dotted-decimal): 66.227.74.170
Dirección IP (binario): 01000010 . 11100011 . 01001010 . 10101010

Sin embargo las direcciones IP en el formato llamado dotted-decimal no son lo bastante convenientes de cara a los usuarios. Una dirección IP no nos permite identificar la empresa, organismo o particular a quién pertenece de manera automática, y se hace tremendamente difícil recordar la dirección asociada a cada usuario o empresa. Las personas somos bastante mejores recordando nombres que números, especialmente si el nombre en cuestión guarda relación directa con la temática que se trata en dicha dirección.

Pues bien, en su concepción original el sistema y protocolo DNS se pensó como una base de datos que asociara las direcciones IP en Internet con nombres textuales fáciles de recordar para las personas. Cuando un usuario quisiera referirse a una máquina de Internet, usaría su nombre, e internamente el sistema DNS se encargaría de averiguar la direccón IP asociada, que es el dato que utilizan los protocolos de red para establecer la comunicación con el extremo remoto. Para el usuario es mucho más sencillo y fácil de recordar que www.24x7linux.com es una página web que trata de Linux, que no la dirección 66.227.74.170.

Sin embargo el DNS dispone de más información que las equivalencias entre cada nombre de máquina y su dirección IP en Internet. En ocasiones resulta necesario poder averiguar el nombre de una máquina a partir de su dirección IP (por ejemplo, en los log de muchos programas sólo aparecen direcciones IP, no nombres de máquina), y DNS también permite averiguar esta información. Y por ejemplo, cuando enviamos un correo electrónico debemos averiguar cuál es la dirección del servidor de correo del destinatario a partir de la dirección de correo del destinatario: el DNS también se encarga de almacenar y proporcionar esta información.

Piense ahora por un momento el tamaño que puede tener esta base de datos llamada DNS, encargada de albergar las equivalencias de nombres de máquina a dirección IP. Teniendo en cuenta que Internet cuenta con varios cientos de millones de máquinas, y que para máquina puede haber varias equivalencias almacenadas, puede suponer que dicha base de datos es tremendamente grande. Pero el problema no es ya el tamaño de la base de datos (en empresas grandes no es extraño tener bases de datos cuyos tamaños se miden en terabytes), sino el volumen de peticiones que recibe a lo largo del día. Por cada página web que visita se generan posiblemente varias consultas al DNS, así como para cada correo enviado, o cualquier otra actividad en Internet.

Suponiendo que en Internet existen aproximadamente unos 500 millones de máquinas y que cada una de ellas realiza de media 200 consultas diarias al DNS (la media seguro que es muy superior) se obtiene un número de, como mínimo mil millones de consultas diarias, lo que se traduce en más de un millón de ellas por segundo.

Resulta evidente que por razones de escalabilidad y para evitar un único punto de fallo la base de datos del DNS está distribuida a lo largo y ancho de Internet. En realidad el DNS consiste en una gran base de datos distribuida y jerárquica, donde cada servidor almacena sólo una pequeña parte del total de los datos. Cada una de estas partes está hospedada en un servidor DNS, que sólo conoce los servidores de nivel inferior, y que no requiere de ninguna autorización previa por parte del servidor de nivel inmediatamente superior para hacer cambios en su configuración.

Esta característica por la cual un servidor puede delegar la gestión de parte de su espacio de nombres a otro servidor diferente y del que sólo necesita saber la dirección IP que usar para llegar a él, dejando que el resto de las modificaciones sean responsabilidad del administrador del servidor de nivel inferior es el que proporciona una gran escalabilidad a la base de datos distribuída que es DNS.

El esquema que se muestra en la figura siguiente expone los conceptos mencionados de manera gráfica. En dicho esquema los tres niveles superiores representan servidores DNS mientras que el nivel inferior representa máquinas cualquiera de Internet. Las líneas que unen unos servidores con otros y con las máquinas de Internet muestran la relación existente entre las citadas máquinas, que siempre es desde un nivel a uno situado por debajo.

En el tope de la jerarquía está la raíz, representada por un punto. El servidor de nombres raíz sólo tendrá información acerca de cómo llegar a los servidores de nivel inmeditamente inferior, que son conocidos como dominios de primer nivel, o TLD (Top Level Domain). Existen más de doscientos TLD definidos actualmente, entre dominios nacionales (uno por cada nación, definidos por su identificador de dos letras según el estándar ISO-3166) y dominios genéricos (com, net, org, gov, mil, edu, y algunos más). Cada uno de estos dominios está gestionado por una empresa u organismo diferente, y configurado en uno o más servidores DNS repartidos por Internet.

De alguna manera los servidores de nombres raíz han delegado la gestión de los espacios de nombres .es, .fr, .com, .net, etc. a otros servidores de DNS, de los cuales sólo tienen que saber su dirección (ya veremos luego para qué la necesitan). Por su parte cada gestor de un dominio de primer nivel puede decidir delegar la gestión de partes de su espacio de nombres, o dominios de segundo nivel, a otras autoridades o empresas, de las cuales sólo necesitará conocer las direcciones IP de sus propios servidores DNS. De esta manera el gestor del dominio .com puede delegar la gestión del subdominio "24x7linux", de manera que el receptor de esta delegación podrá gestionar a su antojo los nombres de dominio a partir de "24x7linux.com". Lo cual no impide que la autoridad que gestiona .es haga lo propio y delegue lagestión del subdominio "24x7linux", de manera que el receptor podrá gestionar sin impedimentos los nombres a partir de "24x7linux.es".

A todos los efectos los dominios "24x7linux.com" y "24x7linux.es" son distintos, no tienen porqué estar delegados a la misma autoridad, y sus contenidos no tienen porqué guardar relación alguna. Por ejemplo, para obtener la gestión del dominio "24x7linux.com" tuve que solicitarlo a la autoridad que gestiona el TLD .com (con la mediación de un registrador de Internet o registrar). Pero una vez me concedieron el dominio, yo puedo gestionarlo a mi antojo. Por ejemplo, puedo crear un nombre de máquina "www" dentro de mi dominio (es decir, www.24x7linux.com) y asociarlo con la dirección IP del servidor web que hospeda las páginas.

O puedo crear una máquina llamada "smtp", cuyo nombre completo o FQDN (Fully Qualified Domain Name) será "smtp.24x7linux.com" que se encargue de recoger el correo electrónico destinado a las direcciones de correo del dominio "24x7linux.com". Incluso puedo definir no un nombre de máquina sino un subdominio completo, por ejemplo "beta.24x7linux.com" que delegar a otra entidad para que lo gestione sin darme otros datos salvo las direcciones IP de los servidores de DNS que albergarán la información de dicha zona.

Antes de pasar a explicar con un ejemplo práctico cómo funcionan las consultas al DNS en Internet hay que hacer un par de comentarios previos. El primero, que no sólo la base de datos del DNS se compone de múltiples bases de datos más pequeñas, sino que cada base de datos (cada zona, o fracción del espacio de nombres) está replicada en (como mínimo) dos servidores físicos. Por ejemplo, existen en la actualidad trece servidores de nombres raíz (y próximamente un decimocuarto situado en España) repartidos por el mundo y que almacenan la información acerca de cuáles son los servidores de nombres para todos los dominios de primer nivel, así como los dominios de segundo nivel de (entre otros) el dominio .com.

El otro detalle interesante que comentar es que cada una de estas equivalencias entre nombre y dirección IP, IP y nombre, nombre y servidor de correo, etc. se identifican por un tipo de consulta DNS, lo que se conoce como el tipo de registro de recurso, o RR (Resource Record). Por ejemplo, la equivalencia entre nombre de máquina y sus direcciones IP (que pueden ser varias) se almacena en registros de tipo A (Address). La equivalencia inversa de dirección IP a nombre de máquina en registros de tipo PTR (PoinTeR), el registro que indica el servidor de correo entrante para un nombre de dominio concreto es de tipo MX (Mail eXchanger), los servidores de DNS para cada dominio se representan mediante registros NS (Name Server), y así un largo etcétera que puede consultar en el sitio oficial del IANA (Internet Assigned Numbers Authority).

Supongamos que el usuario en la máquina llamada "cliente" dentro de la red de la figura abre su navegador y teclea la URL http://www.rediris.es para visitar la página web en cuestión. Su navegador usa unas funciones de librería locales para realizar una consulta recursiva al servidor DNS que tenga configurado (en el archivo /etc/resolv.conf en el caso de Linux), que se identifica en la figura como paso 1. En una consulta recursiva se hace una pregunta al servidor DNS y quedamos a la espera de recibir como respuesta, bien la información solicitada, bien la indicación de que la información pedida no existe. En este caso el navegador quiere averiguar la dirección IP asociada a la máquina "www.rediris.es", de manera que solicitará el RR de tipo A correspondiente.

El servidor DNS local recibe la consulta y antes de hacer nada comprueba en su caché de DNS si ya sabe la respuesta a la consulta que acaba de recibir: por razones de eficiencia los servidores DNS pueden almacenar cierto tiempo en caché la información que vayan aprendiendo en sus consultas a otros servidores DNS. Está claro que en ocasiones la información cacheada no será igual a la real, de hecho los únicos servidores DNS de todo Internet que contendrán información fiable de "www.rediris.es" serán precisamente los servidores de nombres del dominio "rediris.es". Cuando un servidor de nombres contiene información fiable para una zona se dice que es authoritative para esa zona.

Para cada dominio deberá haber varios servidores authoritative, al menos dos: uno de ellos será el primario (o maestro), y los demás serán secundarios (o esclavos) del primero. En el primario su administrador creará los distintos mapeos de información o RR correspondientes a la zona a la que da servicio, y los secundarios cada cierto tiempo (configurable), o cuando haya novedades en el primario, conectarán con éste y obtendrán la información actualizada: este proceso mediante el cual los secundarios se actualizan a partir de la información del primario se conoce como transferencia de zona. Por cierto, que cada RR definido en el maestro tiene asociado un tiempo de vida o TTL (Time To Live), que es precisamente el tiempo durante el que esta información se considera válida una vez cacheada en un servidor DNS intermedio.

Volviendo al ejemplo, el servidor DNS de la red local donde está se da cuenta que no tiene la respuesta en caché e inicia una consulta de tipo iterativo (paso 2): preguntará a algún servidor DNS (ahora veremos cuál) y quedará a la espera de obtener la respuesta a su consulta, que la información solicitada no existe, o la información de otro servidor DNS donde puede encontrar más información. Y el servidor en principio sólo conoce la localización de los trece (pronto catorce) servidores de nombres raíz, que forman parte de sus archivos de configuración. Puesto que las direcciones de los servidores raíz no cambian a menudo (hace unos meses hubo un cambio en un servidor raíz, el primero en cinco años) no hay problema en tenerlas como parte de unos archivos de configuración estáticos.

En el paso 2 el servidor selecciona uno de los trece servidores de nombres raíz que tiene en su archivo de configuración y le hace la misma consulta que recibió del cliente, en concreto pide el RR de tipo A asociado a "www.rediris.es". El servidor de nombres raíz consultado (por ejemplo, el "a.root-servers.net") no dispone de la información solicitada, pero sí que sabe los servidores DNS de todos los TLD, incluyendo los del dominio .es. Entonces responde al servidor con la lista de todos los servidores de nombres que controlan el dominio .es, de los que hay ocho en total (paso 3).

El servidor de nombres local recibe la respuesta (paso 3) y continua con su consulta de tipo iterativo. Aún no sabe la respuesta a la consulta del cliente, pero está más cerca que antes, pues sabe los servidores de nombres del TLD .es, cosa que antes no sabía. De los ocho servidores selecciona uno, típicamente el primero, y le hace la consulta que recibió del cliente en su red local (paso 4). Supongamos que el servidor DNS al que pregunta es "NS1.NIC.es".

El servidor DNS "NS1.NIC.es" tampoco sabe la respuesta, puesto que no es servidor de nombres authoritative para el dominio "rediris.es". Pero lo que sí sabe son las direcciones de los servidores DNS del dominio de segundo nivel "rediris.es", que es la respuesta que envía al servidor de nombres que le preguntó (paso 5).

El servidor de la red local no ceja en su empeño puesto que está cada vez más cerca de obtener la respuesta a la consulta que le hizo inicialmente la máquina "cliente" de su red local. Ahora seleccionará uno de los tres servidores de nombres averiguados en el paso anterior (por ejemplo, "chico.rediris.es"), y le pedirá el RR de tipo A asociado al nombre de máquina "www.rediris.es" (paso 6). En este caso el servidor consultado sí sabe la respuesta, puesto que es authoritative para el dominio "rediris.es", devolviendo al servidor que preguntó la información solicitada (paso 7). En este punto el servidor de nombres de la red local ya puede responder a la máquina "cliente" (paso 8), cuyo navegador podrá finalmente conectar con el puerto 80 del servidor remoto "www.rediris.es" y solicitar la página principal, tal y como se explica en este artículo sobre protocolo HTTP.

Es interesante decir qué puertos y tipo de protocolo de nivel de transporta usa el protocolo DNS para su funcionamiento, así sabremos qué tipo de tráfico permitir en nuestro cortafuegos sin comprometer la seguridad perimetral de nuestra red más allá de lo estrictamente necesario. El protocolo DNS, por lo general, transporta las peticiones y las respuestas en datagramas UDP. El servicio DNS tiene reservado para atender las consultas de los clientes el puerto número 53. Sin embargo en ocasiones el protocolo DNS usa protocolo de transporte TCP, manteniendo el 53 como puerto para dar servicio a los clientes.

El uso de TCP como protocolo de transporte se reduce a dos situaciones concretas: por una parte, para transportas las respuestas mayores de 512 octetos de longitud, cosa poco habitual, pero que sucede con determinados dominios. Si tenemos bloqueado el tráfico TCP hacia y desde el puerto 53 veremos que la resolución de nombres mediante DNS funciona casi siempre, pero falla a la hora de consultar información en determinados dominios.

La otra situación en la que se usa protocolo TCP es en las transferencias de zona desde el servidor primario a los servidores secundarios. Si bien el proceso de transferencia lo inician siempre los secundarios hacia el primario por razones de fiabilidad se establece una conexión TCP desde cada secundario al primario para descargarse una copia de las bases de datos de las zonas DNS para las que es authoritative.

Ya para terminar esta (larga) introducción al protocolo DNS vamos a ejecutar algunos comandos del sistema operativo para hacer consultas típicas al DNS que tienen lugar a diario por el mero uso de las mismas para funciones como navegar por Internet, enviar correo electrónico, etc. Usaremos para ello el comando host, disponible en cualquier UNIX o Linux, que junto con los comandos dig y nslookup se usan para consultar los servidores DNS de manera manual.

usuario@cliente:~$ host -t a www.rediris.es
www.rediris.es          CNAME   sun.rediris.es
sun.rediris.es          A       130.206.1.2

El comando anterior realiza una consulta DNS de tipo A para averiguar la dirección IP asociada al nombre de máquina "www.rediris.es". La consulta se efectua al servidor DNS configurado en el archivo /etc/resolv.conf, que en el caso de la máquina sobre la que se ha ejecutado reside en el propio PC. Vemos que la respuesta a la consulta indica que "www.rediris.es" es un CNAME (Canonical NAME, es decir, un alias) para la máquina "sun.rediris.es", que a su vez tiene una dirección IP igual a "130.206.1.2".

usuario@cliente:~$ host -t a www.cnn.com
www.cnn.com             CNAME   cnn.com
cnn.com                 A       64.236.16.84
cnn.com                 A       64.236.16.116
cnn.com                 A       64.236.24.4
cnn.com                 A       64.236.24.12
cnn.com                 A       64.236.24.20
cnn.com                 A       64.236.24.28
cnn.com                 A       64.236.16.20
cnn.com                 A       64.236.16.52

Este caso es similar al anterior, pero ahora hay más de una IP asociada a un mismo nombre de dominio. Cuando su navegador trate de conectar a la página "www.cnn.com" consultará al DNS como hemos hecho ahora, obtendrá esta misma lista de direcciones IP y tratará de conectar con la primera de la lista. El servidor siempre responde con la lista de IP en un orden distinto, así que por término medio 1/8 de las veces se conectará con cada uno de los servidores reales asociados a cada IP. Este sencillo mecanismo de round robin DNS es un método simple de repartir la carga de un sitio web entre varios servidores reales que contengan la misma copia de las páginas.

usuario@cliente:~$ host -t ns es. d.root-servers.net
es                      NS      NS1.NIC.es
es                      NS      INECO.NIC.es
es                      NS      NS3.NIC.FR
es                      NS      MUNNARI.OZ.AU
es                      NS      PRADES.CESCA.es
es                      NS      SUN.REDIRIS.es
es                      NS      SUNIC.SUNET.SE
es                      NS      NS.UU.NET

En el comando anterior le hemos preguntado directamente al servidor de nombres raíz "d.root-servers.net" los servidores de nombres que gestionar el TLD .es.

usuario@cliente:~$ host -t mx 24x7linux.com
24x7linux.com           MX      10 smtp.24x7linux.com
usuario@cliente:~$ host -t a smtp.24x7linux.com
smtp.24x7linux.com      A       66.227.74.170

Con el primer comando hemos preguntado qué máquina de Internet se encarga de recoger el correo destinado a los usuarios en el dominio "24x7linux.com", y hemos averiguado que se trata de la máquina de nombre "smtp.24x7linux.com". Para poder conectar con dicha máquina y enviarle nuestro mensaje debemos averiguar su IP, lo que conseguimos mediante el segundo comando mostrado. Esta pareja de búsquedas son las que llevan a cabo los servidores de correo cuando tienen que enviar un mensaje.

usuario@cliente:~$ host -t ptr 217.227.203.49
Name: pD9E3CB31.dip.t-dialin.net
Address: 217.227.203.49

Una consulta al DNS de tipo PTR con una dirección IP como parámetro trata de encontrar el nombre de máquina al que corresponde tal dirección IP. Esta búsqueda es típica de los analizadores de log o por ejemplo cuando quiere saber de dónde provienen los múltiples intentos de conexión registrados en su cortafuegos, destinados a servicios que no ofrece.

usuario@cliente:~$ host -t soa 24x7linux.com
24x7linux.com           SOA     ns7.zoneedit.com dnsadmin.zoneedit.com (
                        7       ;serial (version)
                        7200    ;refresh period (2 hours)
                        600     ;retry interval (10 minutes)
                        1209600 ;expire time (2 weeks)
                        43200   ;default ttl (12 hours)
                        )

Ya para terminar veamos un último tipo de RR del que no habíamos hablado en concreto hasta ahora, el RR de tipo SOA (Start Of Authority). En él se definen, aparte del servidor de nombres primario (ns7.zoneedit.com), la dirección de correo electrónico del administrador del mismo (dnsadmin.zoneedit.com), el tiempo de vida (TTL) predeterminado de todos los RR de esta zona en las caché DNS de Internet, y los parámetros de las transferencias de zonas desde el servidor primario hacia los secundarios.

Los parámetros restantes indican que los servidores secundarios contactarán con el primario cada dos horas, y comprobarán si ha habido modificaciones en su base de datos comparando el número de serie (serial) con el visto en la visita anterior (no mira el contenido de la base de datos, sólo el número de serie). Si la conexión del secundario al primario no es posible lo reintenta cada 10 minutos, pero si transcurre una semana desde la última actualización con el primario, el secundario deja de responder a las consultas sobre ese dominio en concreto.

Última modificación: 19-December-2004 08:50:30 -0500