+++ to secure your transactions use the Bitcoin Mixer Service +++

 

6.2. C�mo funciona el DNS

El DNS organiza los nombres de m�quina (hostname) en una jerarqu�a de dominios. Un dominio es una colecci�n de nodos relacionados de alguna forma—porque est�n en la misma red, tal como los nodos de una universidad—. Por ejemplo, las universidades americanas se agrupan en el dominio edu. Cada universidad tiene all� un subdominio, tal como la universidad Groucho Marx, que posee el subdominio groucho.edu. A su vez, podemos encontrar nuevos subdominios dentro, como el Departamento de Matem�ticas (maths). Finalmente, un nodo de ese departamento llamado erdos tendr� un nombre completo (conocido como totalmente cualificado) tal como erdos.maths.groucho.edu. Este nombre totalmente cualificado tambi�n se conoce por las siglas FQDN.

En Figura 6-1 vemos una parte del espacio de nombres. La ra�z del �rbol, que se identifica con un punto sencillo, es lo que se denomina dominio ra�z y es el origen de todos los dominios. Para indicar que un nombre es FQDN, a veces se termina su escritura en un punto. Este punto significa que el �ltimo componente del nombre es el dominio ra�z.

Figura 6-1. Una parte del espacio de nombres de dominios

Dependiendiendo de su localizaci�n en la jerarqu�a, un dominio puede ser de primer nivel (top-level), segundo nivel o tercer nivel. Se pueden a�adir todos los niveles que queramos, pero no son habituales. Los que siguen son los dominios de primer nivel que veremos con frecuencia:

DominioDescripci�n
edu

Instituciones universitarias, casi todas norteamericanas.

com

Organizaciones comerciales.

org

Organizaciones no comerciales. Las redes privadas UUCP suelen estar en este dominio.

net

Pasarelas y otras redes administrativas.

mil

El ej�rcito norteamericano.

gov

El gobierno norteamericano.

uucp

Dominio para redes UUCP.

Inicialmente los cuatro primeros dominios de la lista anterior pertenec�an solo a los Estados Unidos, sin embargo, los cambios de pol�tica posteriores han hecho que estos dominios, llamados de dominios globales primer nivel (gTLD) sean realmente globales. Adem�s se est�n negociando nuevos dominios de primer nivel.[1]

Fuera de los Estados Unidos, cada pa�s suele tener su propio dominio de primer nivel codificado con las dos letras del pa�s definidas en la tabla ISO-3166. Finlandia, por ejemplo, usa el dominio fi; en Espa�a se usa el dominio es; en M�xico se usa mx; en Argentina, ar, etc. Por debajo de cada dominio de primer nivel, cada pa�s organiza los dominios a su manera. Algunos crean a segundo nivel una serie de dominios similares a los gTLD. Por ejemplo, en Argentina encontramos los dominios com.ar para las empresas, y org.ar para las organizaciones sin �nimo de lucro. Otros pa�ses, como Espa�a, ponen directamente como nombres de segundo nivel las instituciones o empresas que los solicitan. Por ejemplo, tenemos hispalinux.es.

Por supuesto, el hecho de que un nombre est� en uno de estos dominios nacionales, no implica que la m�quina est� realmente en ese pa�s; significa simplemente que ha sido registrada en el NIC de ese pa�s. Un fabricante sueco puede tener oficinas en Australia y tener sus ordenadores de all� registrados en el dominio se.

La organizaci�n del espacio de nombres en una jerarqu�a de nombres de dominio sirve para resolver f�cilmente el problema de la unicidad de los nombres; adem�s muchos nombres completamente cualificados son f�ciles de recordar. Bajo esta premisa es conveniente dividir un dominio con gran n�mero de m�quinas en subdominios.

El sistema DNS hace m�s cosas. Permite delegar la autoridad de un subdominio a sus administradores. Por ejemplo, los responsables del Centro de C�lculo Groucho pueden crear un subdominio para cada departamento, y delegar su control a �stos. As�, cada departamento puede definir libremente todos los nodos que quiera dentro de su subdominio e incluso crear nuevos subdominios y delegarlos.

Para esto, el espacio de nombres se divide en zonas, cada una asignada a un dominio. Hay que ver la diferencia entre zona y dominio: por ejemplo, el dominio groucho.edu incluye todas las m�quinas y subdominios de �ste. Mientras que la zona groucho.edu solo incluye las m�quinas del dominio, no los subdominios delegados. Es decir, los nodos del subdominio physics.groucho.edu pertenecen a una zona diferente. En Figura 6-1, el inicio de la zona se marca con un peque�o c�rculo a la derecha del nombre de dominio.

6.2.1. B�squedas con DNS

Veremos ahora la parte m�s ingeniosa del DNS. La idea es que si queremos buscar la direcci�n IP del sistema erdos, DNS pensar�, “Preguntemos a la gente que lo maneja, y nos lo dir�.”

De hecho, el DNS es como una gigantesca base de datos distribuida. Est� realizada a trav�s de los llamados servidores de nombres, que proporcionan la informaci�n de uno o varios dominios. Para cada zona, debe haber dos o m�s servidores de nombres capaces de responder por ella. Para obtener la direcci�n IP de erdos, todo lo que necesitamos es contactar con el servidor de nombres de la zona groucho.edu y obtendremos los datos solicitados.

Pensaremos, es m�s f�cil decirlo que hacerlo pues, �c�mo llegamos al servidor de nombres de la Universidad Groucho Marx? En el caso de que nuestro ordenador no est� equipado con un or�culo de resoluci�n de direcciones, el DNS nos lo hace tambi�n. Cuando nuestra aplicaci�n quiera buscar la informaci�n de erdos, contactar� con un servidor de nombres local, quien lleva a cabo una secuencia de peticiones. En primer lugar pregunta al servidor de nombres ra�z, preguntando por erdos.maths.groucho.edu. El servidor ra�z reconoce que el nombre no pertenece a ninguna de sus zonas de autoridad pero s� sabe qu� hacer con la zona edu. Esto es, devuelve a nuestro servidor m�s informaci�n sobre los servidores de nombres que pueden servir la zona edu. Ahora nuestro servidor preguntar� por este nombre a uno de esos servidores. Ellos nos enviar�n a uno que tenga informaci�n autorizada del dominio groucho.edu. Ahora nuestro servidor interrogar� a �ste y finalmente obtendr� la direcci�n de erdos.

Aparentemente la b�squeda de una direcci�n IP supone mucho tr�fico, sin embargo es min�sculo si lo comparamos con la consulta de un gigantesco fichero HOSTS.TXT. Aun as� hay t�cnicas para mejorar el rendimiento.

Para acelerar futuras peticiones de nombres, el servidor almacena la informaci�n obtenida en la b�squeda anterior en su cach� local. As�, la pr�xima vez que busquemos alg�n nodo de groucho.edu, ya no habr� que ir a los servidores ra�z o los de la zona edu.[2]

Por supuesto, el servidor de nombres no almacenar� para siempre la informaci�n en la cach�; la limpiar� cada cierto tiempo. El tiempo de vida se llama TTL (del ingl�s time to live). En cada zona DNS el administrador asigna un valor de TTL.

6.2.2. Tipos de servidores de nombres

Los servidores de nombres que mantienen oficialmente la informaci�n de una zona se conocen como autorizados de la zona, y a veces se conocen como servidores principales o maestros. Cualquier petici�n de nodos de esa zona ir� a parar a uno de estos servidores principales.

Los servidores principales deben estar bien sincronizados. Es decir, uno de ellos ser� llamado primario, que carga su informaci�n de un fichero, y hacer a los dem�s secundarios, que obtienen su informaci�n pidi�ndosela peri�dicamente al primario.

El objetivo de tener varios servidores principales es distribuir la carga y dar cierta tolerancia a fallos. Cuando uno de los servidores principales falla, todas las peticiones acabar�n en los dem�s. Por supuesto, este esquema no nos protege de fallos del servidor que produzcan errores en todas las peticiones DNS, como podr�an ser errores del software.

Tambi�n podemos instalar un servidor de nombres que no es maestro de ninguna zona.[3] Esto es �til, para dar servicio de nombres a una red local aprovechando sus caracter�sticas de ahorro de ancho de banda gracias a su cach�. Estos servidores se conocen como de s�lo-cach�.

6.2.3. La base de datos DNS

Hemos visto que el DNS no s�lo sabe de direcciones IP de m�quinas, pero tambi�n almacena otras informaciones.

Cada unidad de informaci�n del DNS se llama Registro de Recurso (RR). Cada registro tiene un tipo asociado que describe el dato que contiene, y una clase que especifica el tipo de red al que se aplica. Esto �ltimo se adapta a diferentes esquemas de direcci�n, como direcciones IP (la clase IN), direcciones Hesiod (utilizadas por el sistema Kerberos del MIT) y algunas m�s. El RR t�pico es el registro A, que asocia un nombre completamente cualificado con una direcci�n IP.

Un nodo puede ser conocido por m�s de un nombre. Por ejemplo, podemos tener un servidor que proporciona tanto servicio FTP como WWW, y tendr� dos nombres: ftp.maquinas.org y www.maquinas.org. Sin embargo, uno de estos nombres debe ser identificado como oficial o can�nico. La diferencia es que el can�nico es el �nico registro A que debe existir apuntando a esa direcci�n IP, mientras que el resto de los nombres deben ser alias (registros CNAME), que apuntan al nombre can�nico.

No vamos a revisar todos los tipos de RR aqu�, pero veremos alg�n ejemplo m�s amplio. En Ejemplo 6-4 vemos una parte de la base de datos DNS que est� cargada en los servidores de nombres para la zona physics.groucho.edu.

Aparte de los registros A y CNAME, vemos al principio un registro especial, de varias l�neas. Es el registro SOA, que se�aliza el inicio de autoridad, que almacena diversos par�metros de la zona de la que es autoritativo el servidor. El registro SOA incluye, por ejemplo, el tiempo de vida predeterminado de los registros (TTL).

N�tese que todos los nombres del fichero de ejemplo que no finalizan en un punto deben interpretarse relativos al dominio physics.groucho.edu. El nombre especial (@) utilizado en el registro SOA representa al propio nombre del dominio.

Hemos visto antes que los servidores de nombres para el dominio groucho.edu tienen que saber acerca de la zona physics para poder realizar peticiones a sus servidores de nombres. Esto normalmente se realiza mediante dos registros: los registros DNS que proporcionan el FQDN del servidor de nombres, y el registro A que asocia ese FQDN con una direcci�n IP. Puesto que estos registros son los que mantienen el espacio de nombres, se conocen frecuentemente como registros glue. S�lo son instancias de registros para los que una zona padre mantiene informaci�n sobre nodos de la zona subordinada. Los registros glue apuntando a los servidores de nombres de physics.groucho.edu se muestran en Ejemplo 6-5.

6.2.4. Resoluci�n inversa

La operaci�n m�s habitual con el DNS es obtener la direcci�n IP correspondiente a un nombre de nodo. Sin embargo, a veces queremos hacer la operaci�n opuesta: encontrar el nombre a partir de la direcci�n IP. Esto se conoce como resoluci�n inversa, y la usan diversas aplicaciones para comprobaci�n de identidad del cliente. Cuando se utiliza el fichero hosts, la resoluci�n se realiza mediante una b�squeda simple en el fichero. Con el DNS, una b�squeda exhaustiva en el espacio de nombres carece de sentido. En su lugar, existe un dominio especial, el in-addr.arpa, que contiene las direcciones IP de todos los sistemas en una notaci�n de puntos invertida. Por ejemplo, a la direcci�n 1.2.3.4 le corresponde el nombre 4.3.2.1.in-addr.arpa. El registro de recurso (RR) que define esto se llama registro PTR.

Cuando se crea una zona de autoridad, ello suele significar que sus administradores tienen control total sobre c�mo se asignan los nombres a las direcciones. Puesto que normalmente tienen bajo su control una o m�s redes o subredes IP, se da una situaci�n de mapeo uno-a-varios entre zonas DNS y redes IP. El Departamento de F�sica, por ejemplo, comprende las subredes 149.76.8.0, 149.76.12.0 y 149.76.14.0.

En consecuencia, deben crearse nuevas zonas en el dominio in-addr.arpa para la zona de F�sica, deleg�ndose a �sta las siguientes: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, y 14.76.149.in-addr.arpa. De otro modo, cada vez que instal�semos un nuevo nodo en el laboratorio Collider, habr�a que contactar con el que gestiona la red padre para que actualizase su fichero de zona in-addr.arpa.

En Ejemplo 6-6 se muestra la base de datos para la subred 12. Los registros glue correspondientes a la base de datos de la zona padre se muestran en Ejemplo 6-7.

Las zonas de in-addr.arpa s�lo pueden ser creadas por superconjuntos de redes IP. Hay una restricci�n m�s severa: las m�scaras de estas redes deben contener los octetos completos. Es decir, podemos crear una zona para una red con m�scara 255.255.255.0 pero no para una del tipo 255.255.255.128. El motivo es que para especificar la red delegada 149.76.4.0 tenemos el dominio 4.76.149.in-addr.arpa, pero para la red 149.76.4.128 no tenemos forma de nombrar el dominio in-addr correspondiente.

Notas

[1]

N. del T.: Ya han sido aprobados algunos, cuya elecci�n no ha estado exenta de pol�mica.

[2]

Si la informaci�n no se almacenara en cach�, el sistema ser�a realmente ineficiente.

[3]

En todo caso debe servir el dominio localhost y resoluci�n inversa de 127.0.0.1.