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.
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:
| Dominio | Descripció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.
Ejemplo 6-4. Extracto del fichero named.hosts del Departamento de Físicas
; Informacion autoritativa physics.groucho.edu.
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
1999090200 ; numero de serie
360000 ; refresco
3600 ; reintento
3600000 ; caducidad
3600 ; TTL predeterminado
}
;
; Servidores de nombres
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Fisica Teorica (subred 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Laboratorio (subred 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
... |
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.
Ejemplo 6-5. Un extracto del fichero named.hosts de GMU
; Zona de datos para la zona groucho.edu
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 ; serie no
360000 ; refresco
3600 ; reintento
3600000 ; expiración
3600 ; ttl por omisión
}
....
;
; Registros glue para la zona physics.groucho.edu
physics IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
... |
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.
Ejemplo 6-6. Extracto del fichero named.rev de la subred 12
; dominio 12.76.149.in-addr.arpa
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
1999090200 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu. |
Ejemplo 6-7. Extracto del fichero named.rev de la Red 149.76
; dominio 76.149.in-addr.arpa
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 360000 3600 3600000 3600
}
...
; subnet 4: Mathematics Dept.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; subnet 12: Physics Dept, separate zone
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
... |
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.