El sistema de nombre de

dominios de Internet
explicado para los no
expertos.
Memorando de Internet Society n. 16
por Daniel Karrenberg*

El sistema de nombres de dominios de Internet explicado para los no expertos

Estimados no expertos:
Esta introduccin se ha creado pensando en ustedes, que siempre quisieron o necesitaron saber
cmo funcionan los nombres de Internet. El sistema de nombres de dominio (DNS) de Internet es
una tecnologa fascinante; casi todas las aplicaciones de Internet la usan. Cuando haya ledo
esta introduccin, no se convertir en un experto de DNS de repente, pero entender como
funciona DNS y podr distinguir entre expertos en DNS e impostores.
Estimados expertos:
Este documento no es para ustedes. Aqu generalizaremos a menudo para explicar mejor los
principios hasta el punto en el que algunas explicaciones no sean correctas, estrictamente
hablando, hasta el ltimo detalle. Podrn encontrar una descripcin ms detallada en los
estndares de Internet correspondientes.
El objetivo de DNS
El objetivo de DNS es permitir que las aplicaciones de Internet y sus usuarios den un nombre a
cosas que no tienen un nombre global nico. El beneficio ms claro es el uso de nombres de fcil
memorizacin para cosas como pginas Web y cuentas de correo electrnico, ms que
memorizar nmeros largos o cdigos. El beneficio menos obvio, pero de igual importancia, es la
separacin del nombre de algo de su ubicacin. Las cosas se pueden mudar a una ubicacin
completamente diferente en la red, de manera transparente, sin cambiar el nombre.
www.isoc.org puede estar en un ordenador de Virginia hoy y en otro ordenador de Ginebra
maana sin que nadie se d cuenta.
Para conseguir esta separacin, los nombres se tienen que traducir en otros identificadores que
las aplicaciones usan para comunicarse a travs de los protocolos apropiados de Internet.
Veamos qu pasa cuando me enva un mensaje de correo electrnico a
Daniel.karrenger@ripe.net! Un servidor de correo, que intenta entregar el mensaje, tiene que
encontrar dnde se tiene que enviar el correo de los buzones de ripe.net. Es en este momento

www.internetsociety.org

cuando DNS entra en juego. El servidor de correo transmite esta pregunta, llamada consulta en
la terminologa DNS, al DNS. Y recibe rpidamente la siguiente respuesta:
ripe.net. 1800 IN MX 100 postman.ripe.net.
ripe.net. 1800 IN MX 150 postboy.ripe.net.
Los correos de ripe.net deberan enviarse primero al ordenador llamado postman.ripe.net. Si
postman.ripe.net no est disponible, prueba postboy.ripe.net.
El servidor har una conexin con postman.ripe.net. Para hacerlo, necesita saber la direccin
numrica de Internet de postman.ripe.net. Esta direccin numrica es suficiente para enviar
paquetes de Internet al ordenador llamado postman.ripe.net desde cualquier parte de Internet.
Se vuelve a consultar a DNS y este contesta 193.0.0.199.
postman.ripe.net. 172800 IN A 193.0.0.199
A partir de este momento, el servidor de correo que entrega su mensaje puede comunicarse
directamente con el servidor de correo que recibe y almacena mi correo para que yo lo pueda leer
ms adelante.
Es obvio que la informacin que hemos obtenido antes, para el ejemplo, no proviene de una lista
central que est en algn sitio. Esta lista sera demasiado larga, cambiara demasiadas veces y
su repositorio se vera abrumado rpidamente por el nmero de consultas.
As que, cmo funciona?
Sigamos a la consulta DNS que se inicia en su ordenador! Su ordenador conoce la direccin de
un servidor de almacenamiento en cach de DNS que est cerca y enviar la consulta al
mismo. Los servidores de almacenamiento en cach normalmente ofrecidos por aquellos que le
proveen del servicio de conexin de Internet. Puede tratarse de su proveedor de servicios de
Internet (ISP) en una configuracin residencial o su departamento empresarial de TI en un
entorno de oficina. Su ordenador aprender la direccin de los servidores de almacenamiento en
cach disponibles de forma automtica cuando se conecte a la red o su administrador de redes la
configurar de manera esttica.
Cuando la consulta llegue al servidor de almacenamiento en cach existe la posibilidad de que
este servidor sepa la respuesta porque la recuerda, la tiene en cach en terminologa de DNS,
de una transaccin anterior. De modo que si alguien que usa el mismo servidor de
almacenamiento en cach ha enviado un correo a ripe.net recientemente, la informacin
necesaria ya estar disponible, y todo lo que el servidor de almacenamiento en cach tiene que
hacer es enviar las respuestas guardadas a su ordenador. Ahora ya entiende cmo el
almacenamiento en cach acelera, de manera considerable, el tiempo de respuesta para
consultas de nombres populares. Otro efecto importante del almacenamiento en cach es la
reduccin de la carga en DNS, ya que muchas consultas no pasan de los servidores de
almacenamiento en cach.
Detalle: jerarquas de cach
Los servidores de almacenamiento en cach tambin se pueden organizar en una jerarqua.
Esta operacin tiene sentido en casos en los que la capacidad de la red est limitada o la
latencia de la red entre el servidor DNS y el resto de Internet sea alta. Cuando conecta un
porttil a Internet a travs de una conexin de acceso telefnico lenta, tiene sentido ejecutar un

www.internetsociety.org

servidor de almacenamiento en cach desde el porttil. De esa forma, cada vez que hace clic
en un hiperenlace en el mismo sitio Web, no tendr problemas de trfico de DNS con el enlace
de acceso telefnico. Ese tipo de servidor de almacenamiento en cach se configura a
menudo para enviar todas las consultas para las que no tiene respuestas en cach al servidor
de almacenamiento en cach del ISP.
En ocasiones, las redes empresariales cuentan con servidores de almacenamiento en cach
locales que en su lugar enviarn consultas a servidores de almacenamiento en cach
empresariales antes de enviar la informacin a Internet. De este modo, el servidor de
almacenamiento en cach empresarial puede crear una cach ms amplia basndose en
todas las consultas de la empresa.
Ms all de la cach
Si el servidor de almacenamiento en cach no encuentra la respuesta a la consulta en su cach,
tiene que encontrar otro servidor de DNS que tenga la respuesta. En nuestro ejemplo, buscar
un servidor que tenga las respuestas para los nombres que terminen en ripe.net. En
terminologa de DNS, tal servidor se considera autoritativo para el dominio de ripe.net.
En muchos casos, el servidor de almacenamiento en cach ya conoce la direccin del servidor
autorizado de ripe.net. Si alguien que ha usado el mismo servidor de almacenamiento en cach
ha navegado recientemente por www.ripe.net, el servidor de almacenamiento en cach busc y
encontr el servidor autoritativo para ripe.net en ese momento, y como es un servidor de
almacenamiento en cach, evidentemente guard la direccin del servidor autorizado.
De modo que el servidor de almacenamiento en cach enviar la consulta sobre el servidor de
correo ripe.net al servidor autorizado de ripe.net, recibir una respuesta, enviar una respuesta
a travs de su ordenador y guardar la respuesta en la cach.
Tenga en cuenta que hasta el momento solo el servidor de almacenamiento en cach y el
servidor autorizado de ripe.net han respondido a esta consulta.
Redundancia: muchos servidores con las mismas respuestas
Pero, qu pasara si no encuentra el servidor de almacenamiento en cach local o el servidor
autorizado de ripe.net? Obviamente, su servidor de correo no obtendra una respuesta y no
podra entregar su mensaje de inmediato. Pondra su mensaje en la cola y volvera a intentarlo
despus. Sin embargo, si su navegador web necesitase encontrar la direccin www.ripe.net
cuando hizo clic en un hiperenlace de ese sitio, la respuesta sera diferente. El navegador
parecera estar parado mientras espera a que se resuelva la consulta de www.ripe.net a una
direccin numrica puesto que no podra ponerse en contacto con el servidor web sin conocer
esa direccin numrica. En ese caso, o se aburrira de esperar y hara otra cosa, o su navegador
le dara un mensaje de error cuando hubiese pasado el tiempo de espera para la consulta DNS.
Esto no sucede a menudo porque hay mucho potencial para la redundancia en la arquitectura de
Internet, en especial de DNS.
Para asegurar una gran disponibilidad, DNS tiene mltiples servidores con los mismos datos.
Para resolver el problema de falta de disponibilidad del servidor de almacenamiento en cach
local, su ordenador normalmente tiene varios configurados entre los que puede elegir uno. De
ese modo, nos aseguramos de que siempre haya un servidor de almacenamiento en cach
disponible. Pero, qu ocurre con los servidores autorizados?

www.internetsociety.org

Para mejorar la disponibilidad de los servidores autorizados de nombres siempre se cuenta con
varios para cada dominio. En nuestro ejemplo de ripe.net, existen cinco servidores, tres en
Europa, uno en Norteamrica y uno en Australia.
ripe.net.
ripe.net.
ripe.net.
ripe.net.
ripe.net.

172800 IN NS ns.ripe.net.
172800 IN NS ns2.nic.fr.
172800 IN NS sunic.sunet.se.
172800 IN NS auth03.ns.uu.net.
172800 IN NS munnari.OZ.AU.

Nuestro servidor de almacenamiento en cach no cuenta nicamente con un lugar para buscar
informacin autorizada sobre los nombres de ripe.net sino con cinco, todos ellos con el mismo
nivel de autorizacin. Puede elegir libremente cualquiera de ellos, dependiendo de sus
preferencias, ya que todos tienen la misma informacin. La eleccin puede ser aleatoria o
basada en los tiempos de respuesta de esos servidores. Es importante recordar que cualquier
eleccin es vlida.
Este mecanismo ofrece el potencial de una redundancia muy fuerte que cubre al servidor y a los
problemas de conexin, puesto que los servidores pueden estar ubicados en cualquier lugar de
Internet. Est claro que el nivel de redundancia real depende del diseo y la ubicacin de los
servidores. Una empresa bastante grande descubri este hecho hace unos aos cuando dos de
sus servidores autorizados de dominio que estaban en la misma sala de ordenadores no podan
encontrarse desde Internet debido a un problema de redes que no poda ser.
Introducir informacin en los DNS
Se escribe informacin en DNS cambiando las bases de datos que los servidores autorizados
de dominio usan para responder a las consultas. Cmo se mantienen esas bases de datos y
cmo se transmiten a los servidores es una implementacin local, completamente transparente
para los clientes de DNS y fuera del alcance de esta descripcin.
Para los dominios ms pequeos, a menudo se cambia un archivo de texto local en uno de los
servidores autorizados y luego se transfiere el cambio al resto. En este caso, el servidor
autorizado en el que se mantiene el archivo principal se considera el principal y el resto de
los servidores autorizados los servidores secundarios. Sin embargo, esta distincin es
invisible para el resto de DNS puesto que todos los servidores se consideran iguales en
trminos de autorizacin.
Subir en la jerarqua
Ahora pensemos en la siguiente situacin: cuando el servidor de almacenamiento en cach
acaba de iniciarse y tiene una cach vaca. Por consiguiente, no conoce la respuesta a su
consulta ni sabe dnde estn los servidores autorizados de ripe.net. Sin embargo, sabe que es
posible hacer preguntas sobre ripe.net a un servidor autorizado de net ya que los puntos
separan las diferentes partes de un nombre de dominio. Este conocimiento forma misma del
protocolo de DNS, que implica: en caso de desconocer los servidores autorizados de un
servidor, elimine la parte izquierda del nombre incluyendo el primer punto
y enve la consulta original a un servidor autorizado para encontrar el nombre.
En nuestro ejemplo, el servidor autorizado de net no conoce la respuesta a la consulta
something.ripe.net, ya que solo los servidores ripe.net tienen esa informacin, pero sabe cules
son los servidores autorizados para las consultas ripe.net. De modo, que en lugar de responder

www.internetsociety.org

a la consulta, el servidor net responder con una lista de los servidores autorizados de ripe.net,
una referencia en terminologa DNS. El servidor de almacenamiento en cach recibir la
referencia de los servidores ripe.net. Al igual que en los ejemplos anteriores, luego har la
pregunta a uno de los servidores autorizados de ripe.net, obtendr la respuesta y la reenviar al
cliente que mand la consulta. Adems, como es un servidor cach, guardar la respuesta y la
lista de servidores autorizados de ripe.net para usarlos en el futuro. Sencillo.
Pero, un momento, hemos asumido que la cach estaba vaca, de modo, que, cmo sabe el
servidor de almacenamiento en cach dnde estn los servidores autorizados de net? En otras
palabras, qu pasa cuando hemos quitado todas las partes del nombre de dominio y an no
sabemos dnde buscar la respuesta?
Para este caso, existe un conjunto especial de servidores autorizados, los servidores raz de
DNS. Estos servidores conocen las direcciones de todos los servidores autorizados de los
nombres que no tienen un punto detrs, los dominios de nivel superior (TLD) como org, com,
ch, uk.
Los servidores raz son los nicos servidores DNS que se tienen que encontrar sin necesidad de
informacin en la cach. Para resolver este problema de arranque, todos los servidores de
almacenamiento en cach tienen una lista preconfigurada de las direcciones numricas de todos
los servidores raz. Cuando se inicia, un servidor de almacenamiento en cach enviar consultas
a la lista actual de servidores raz para obtener cada una de esas direcciones y en su lugar
obtendr una respuesta. Una vez que ha obtenido la lista, sabe dnde puede enviar consultas
para nombres que no tienen puntos. Esto suena a algo innecesariamente complicado, pero
asegura que el servidor de almacenamiento en cach seguir funcionando an cuando las
direcciones de los servidores raz cambian pero la lista preconfigurada no se ha actualizado.
Estas direcciones cambian poco, pero lo hacen de cuando en cuando. Un servidor de
almacenamiento en cach podr usar todos los servidores raz siempre y cuando pueda alcanzar
una de las direcciones preconfiguradas.
Nombre de dominio
Los puntos dividen los dominios en diferentes partes. Esta divisin divide todos los nombres en
diferentes dominios en los que la misma parte de un nombre se puede volver a usar, por ejemplo,
ripe.net no es lo mismo que ripe.org. Lo ms importante, estos dominios pueden tener un
administrador completamente diferente. El administrador de los nombres net no tiene por qu
saber nada de los dominios org. El dominio org es independiente del dominio net. Debido a la
naturaleza jerrquica de esta estructura, los administradores de subdominios de un dominio
pueden ser independientes, por ejemplo isoc.org no tiene que coordinarse con nanog.org, ni
siquiera conocerlo.
Un ltimo ejemplo
Una vez ms, observe qu pasa cuando un servidor de almacenamiento en cach que acaba de
iniciarse recibe una consulta para la direccin www.isoc.org. Despus de iniciarse, el servidor
obtuvo la lista de los servidores raz y sus direcciones. Cuando la consulta llegue, no encontrar
la respuesta para www.isoc.org en la cach, tampoco tendr la direccin del dominio autorizado
isoc.org, ni la direccin del servidor autorizado de org. Como no tendr otra eleccin, le pedir
al servidor raz la direccin de www.isoc.org. El servidor raz contestar con una referencia de la
lista de los servidores autorizados de org. Nuestro servidor cach enviar la consulta de
www.isoc.org a uno de ellos y obtendr otra lista de referencia de todos los servidores

www.internetsociety.org

autorizados de isoc.org. Cuando enve la consulta a uno de esos servidores, recibir la

respuesta. Todo ello sucede tpicamente en menos de un segundo.
A partir de ese momento, el servidor de almacenamiento en cach puede responder a la misma
consulta una y otra vez, desde la cach sin tener que consultar a otro servidor. Tambin puede
enviar cualquier consulta something.isoc.org directamente a un servidor isoc.org y enviar una
pregunta directamente a un servidor autorizado de org sobre una consulta .org. Solo cuando la
consulta termine en algo que no sea .org tendr que volver a buscar en el servidor raz. La
cach pronto tendr listas de los servidores autorizados de los dominios ms populares, en
especial de los TLD populares; Normalmente el servidor de almacenamiento en cach no tendr
que volver a consultar esta informacin durante varios das. Este diseo nos asegura que solo
una pequea fraccin de todas las consultas las procesan los servidores raz o los servidores
autorizados de TLD.

www.internetsociety.org

Gestin de cambios
Qu pasa cuando la informacin de los servidores autorizados se ha actualizado pero los
servidores de almacenamiento en cach del mundo an tienen en cach la informacin antigua y
posiblemente incorrecta?
Aqu es donde el tiempo de vida (TTL) del DNS entra en juego. Cada parte de la informacin de
DNS se puede guardar en cach por separado y tiene un tiempo de vida asociado. Cuando este
tiempo vence, la informacin en cach se elimina y se tiene que volver a obtener de un servidor
autorizado si es necesario. TTL no se configura de manera local en el servidor local, sino en el
servidor autorizado y se transmite junto con la informacin en s. De esta manera el
administrador de un dominio, pude controlar el tiempo que tarda en hacerse conocer un cambio
en todo Internet. Al elegir bien los valores, se puede configurar el intercambio entre poder
cambiar las cosas con rapidez, por un lado, y minimizar los recursos informticos y de redes
necesarios para los servidores de redes, por otro lado. Si no se espera que la informacin en
particular vaya a cambiar en el futuro, se puede configurar una TTL alta, tambin se puede
configurar una TTL baja para informacin que cambiar a menudo. La prctica normal es reducir
la TTL transmitida con la informacin que se va a cambiar, de modo que el cambio se haga
visible ms rpido en todo Internet; Cuando se ha hecho el cambio, TTL vuelve a aumentar.
Con esto termina nuestra introduccin a DNS para no expertos. Esperamos que la haya
disfrutado y haya adquirido un conocimiento bsico de uno de los pilares de Internet de hoy en
da. Igual est interesado en tener ms informacin sobre temas relacionados para personas no
expertas. En estos momentos estamos preparando introducciones similares sobre la actual
evolucin del sistema de servidores raz de DNS.

www.internetsociety.org

Una cobertura mayor por parte de Internet Society

Artculos detallados, artculos acadmicos, enlaces y otros recursos disponibles en:
www.isoc.org/internet/issues
RFC relevantes sobre IETF
Las RFC bsicas que describen DNS son:

1034 Nombres de dominio: conceptos e instalaciones

1035 Nombres de dominio: implementacin y especificaciones

Estas RFC se han actualizado y ampliado en numerosas RFC incluyendo:

RFC1101,
RFC1183,
RFC1348,
RFC1876,
RFC1982,
RFC1995,
RFC1996,
RFC2065,
RFC2136,
RFC2137,
RFC2181,
RFC2308,
RFC2535,
RFC2845, y
RFC3425.
Acerca del autor
Daniel Karrenberg trabaja en RIPE NCC como Director cientfico. Est interesado en medidas de
Internet, el desarrollo de DNS y la evolucin de lo que otras personas llaman a menudo la
Gobernanza de Internet.
En 1990, Daniel lider la fundacin de RIPE NCC, el primero de los Registros Regionales de
Internet. Ha ayudado a dar forma a la poltica de distribucin de direcciones de Internet,
transfiriendo el desarrollo y la implementacin de la poltica a la regin. Tambin trajo a Europa
el segundo servidor raz de nombres DNS en 1997.

Internet Society
Galerie Jean-Malbuisson 15
CH-1204 Ginebra, Suiza
Tel: +41 22 807 1444
Fax: +41 22 807 1445
http://www.internetsociety.org
1775 Wiehle Ave. Suite 201
Reston, VA 20190, EE. UU.
Tel.: +1 703 439 2120
Fax: +1 703 326 9881
Correo electrnico: info@isoc.org

www.internetsociety.org

En los 80, Daniel ayud a construir EUnet y lider la labor de transicin a los Protocolos de
Internet, lo que convirti a EUnet en el primer ISP paneuropeo y trajo conexiones de Internet a
muchos lugares en y alrededor de Europa.
Reconocimientos
La serie de documentos informativos para miembros de ISOC es posible gracias a la generosa
ayuda de los patrocinadores platino de ISOC: Afilias, APNIC, ARIN, Microsoft, Qualys, Ripe NCC
y Agencia sueca de cooperacin internacional para el desarrollo.
Ms informacin sobre el programa de patrocinio platino:
http://www.isoc.org/isoc/
http://www.isoc.org/isoc/membership/platinum.shtml