¿ Cómo funciona ?

El Sistema de Nombres de Dominio de Internet (Internet Domain Name System) es una implementación específica del concepto de servidor de nombres, optimizado a las condiciones de la red de Internet. Dicha implementación cubre tres requisitos:

1. Necesidad de una jerarquía de nombres.
2. Necesidad de un balanceo de carga entre los servidores de nombres.
3. Necesidad de delegar la administración de los servidores de nombres.

El DNS se implementa a través de una estructura de árbol, que es una estructura jerárquica. En el nivel superior se encuentra el nodo raíz, le siguen los nodos de dominios de primer nivel (TLD, Top Level Domain), a continuación vienen los nodos de dominios de segundo nivel (SLD, Second Level Domain), y por último, termina con un número indefinido de nodos de niveles inferiores. Todos estos niveles se separan con un punto al escribirlos.

Los TLDs se dividen en dos tipos:

1. Dominios genéricos (Generic TLD, gTLD): .com, .net, .org, etc.
2. Dominios geográficos o dominios de código de país (Country Code TLD, ccTLD): .es, .fr, .uk, etc. (Siempre con dos caracteres)

Lo que comúnmente se llama nombre de dominio (domain name), por ejemplo, asir.es, consiste en la combinación de un SLD y un TLD, escritos de izquierda a derecha, colocando el nivel más bajo de la jerarquía a la izquierda y el más alto a la derecha.

Los conceptos de autoridad y delegación son básicos en el sistema de nombres de dominios. Cada nodo de la jerarquía se asigna a una autoridad, que es una entidad o persona responsable de la organización y explotación del nodo. Dicha autoridad puede delegar la organización de los niveles más bajos de su nombre de dominio. Los límites de la delegación se reflejan a través de acuerdos entre la autoridad principal y la delegada, no tienen que ser en todas partes iguales.

La autoridad del dominio raíz lo tuvo en un principio la IANA, y a partir de 1998 esta se integró dentro de la ICANN (entidad sin ánimo de lucro), desde donde se crearon los registradores acreditados, que son organizaciones en las que delega, la ICANN, responsabilidades limitadas para la venta y administración de trozos de la jerarquía de nombres de dominio.

Los gTLD son autoritariamente administrados por la ICANN y los ccTLD son delegados por la ICANN individualmente a los países. Cada país tiene derecho a definir sus propias reglas de segmentación y delegación de su ccTLD. Por ejemplo, Estados Unidos ha hecho una segmentación para sus estados, así .ny.us lo ha asignado al estado de Nueva York, en cambio, España, cuyo ccTLD es .es no ha hecho este tipo de segmentación geográfica.

El ccTLD .es fue concedido por la ICANN en 1988 y gestionado en los primeros años por RedIRIS. Desde el 2000, la gestión corre a cargo de la entidad pública empresarial Red.es, adscrita al Ministerio de Industria, Turismo y Comercio a través de la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información.

Teniendo en cuenta todo lo anterior, entenderemos que www.asir.com está compuesto por dos partes, www y .asir.com. El nombre de dominio es .asir.com que fue delegado por la ICANN a una determinada entidad, la cual es ahora la dueña de todo lo que vaya a la izquierda del dominio delegado, y como tal, ha decidido dar el nombre www al equipo donde están alojadas las páginas del sitio web. Este nombre, www, es un convenio para nombrar aquellos equipos que alojan y sirven páginas web, pero se podría haber puesto cualquier otro nombre como nombre del host (miordenador.asir.com). Lo único que se exige es que los nombres de los host deben ser únicos dentro del nombre del dominio.

A veces nos encontramos con nombres como: www.informatica.asir.com, donde deberíamos distinguir dos partes, .asir.com como nombre del dominio y www.informatica, donde www es el nombre del host. Y entonces, ¿qué es .informatica?. Es lo que se denomina subdominio. La autoridad delegada (el dueño) del nombre del dominio .asir.com ha decidido que su organización será mejor servida con una estructura de subdominios basada en departamentos (informatica, contabilidad, etc.). También, podría haber decidido, delegar el subdominio .informatica.asir.com a otra entidad.

En resumen, el propietario de un nombre de dominio, puede delegar, con las reglas que desee, cualquier cosa a la izquierda del nombre de dominio del que es dueño. La entidad delegada es la responsable de la administración del nombre del dominio; y la unidad delegada es lo que se conoce dentro de las especificaciones DNS como zona (zone).

A los nombres como www.asir.com, www.informatica.asir.com, etc. se les denomina FQDN (Full Qualified Domain Name), que no es más que un nombre que incluye el nombre de un equipo y el nombre del dominio de ese equipo. Técnicamente, un FQDN debe acabar en punto (www.asir.com.), como referencia al nodo raíz, pero suele ser habitual no ponerlo.

La longitud máxima permitida para un FQDN (RFC 1035, RFC 1123, RFC 2181) es de 255 caracteres, con una restricción adicional de 63 bytes por etiqueta dentro de un nombre de dominio. Las etiquetas FQDN se restringen a un juego de caracteres limitado: letras A-Z, los dígitos, y el carácter guión (-), y no distinguen mayúsculas de minúsculas. En el dominio .es, desde octubre de 2007, se pueden incluir caracteres especiales, como la ñ, ç o vocales acentuadas á, é, í, ó , ú y ü.

La implementación del DNS de Internet se lleva acabo mediante una serie de servidores de nombres (ejecutan software DNS), y la responsabilidad del buen funcionamiento de estos equipos recae sobre las entidades autoritarias de los dominios de nombres.

Los servidores DNS raíz son los recursos más críticos de Internet. Cuando un servidor de nombres cualquiera es consultado por un nombre del que no tiene información, lo primero que hace es acudir con la consulta a uno de los servidores raíz. En la actualidad existen 13 servidores raíz en todo el mundo, y son conocidos por todos los demás servidores de nombres a través de un fichero de zona especial que se instala junto con el software de DNS.

Los servidores TLD (gTLD y ccTLD), son gestionados por una variedad de organizaciones en virtud de acuerdos con la ICANN.

Las organizaciones a las que les han sido delegadas los nombres de dominio, son las responsables de los servidores que implementan dichos dominios, por lo que pueden tener sus propios servidores DNS, como mínimo dos, por seguridad, y encargarse de ellos. Pero pueden también decidir delegar la responsabilidad de la gestión de los servidores a un ISP, a una empresa de hosting web o a un registrador de nombres de dominios.

El proceso de consulta a los servidores se puede resumir en los siguientes pasos:

1. Un equipo de un usuario realiza la consulta del nombre fred.example.com al DNS que tiene configurado, y lo normal será que no tenga respuesta autoritaria, por lo que recurre a uno de los 13 servidores DNS raíz.
2. El servidor raíz le responde con una referencia al servidor o servidores del TLD de su consulta (.com).
3. El equipo del usuario le envía la consulta (fred.example.com) al servidor del TLD.
4. El servidor del TLD responde con una referencia al servidor del nombre de dominio de su consulta (.example.com).
5. El equipo del usuario le envía la consulta (fred.example.com) al servidor del dominio .example.com.
6. El servidor del dominio envía al equipo del usuario una respuesta autoritaria de su consulta.

Estos pasos pueden verse en la siguiente imagen:

Como se ha dicho, los servidores raiz son 13 a nivel mundial, pero en realidad cada uno de ellos son un grupo de varios servidores DNS físicos, pero usando una técnica denominada anycasting, cada grupo utiliza una única IP. En realidad ocupan unos 200 servidores. A los 13 servidores raíz se les ha asignado un FQDN, que van desde a.root-servers.net hasta m.root-servers.net.

La actualización de los servidores raíz consiste en tener la última versión un fichero que lista los servidores autoritarios de cada TLD. De esto se encarga la ICANN, y por seguridad, solo puede ser realizado desde sus equipos, además de hacerse utilizando transacciones seguras, es decir, utilizando DNSSEC.

Como se mencionó anteriormente, los TLD se dividen en TLD genéricos (gTLD) y TLD de países (ccTLD). En 2004, la ICANN decidió dividir los gTLD en dos grupos, los gTLD patrocinados (sTLD, sponsor TLD) y los gTLD no patrocinados.

Los sTLD se han creado para representar a comunidades específicas, y deben tener un patrocinador (sponsor) responsable de su creación y administración. El concepto de comunidad se basa en cuestiones étnicas, geográficas, profesionales, culturales, etc. Algunos ejemplos de estos dominios son:

sTLD	Comunidad	Patrocinador
.aero	Miembros de la industria del transporte aéreo	SITA
.asia	Región de Asia, Australia y el Pacífico	DotAsia Organisation Ltd.
.museum	Museos	Museum Domain Management Association
.gal	Comunidad cultural gallega	Asociación PuntoGal
.eus	Comunidad cultural vasca	Asociación PutuEus
.cat	Comunidad cultural catalana	Asociación PuntCat

Los ccTLD consisten siempre en dos caracteres que representan a un país, pero como la definición de país es espinosa, la ICANN se ha lavado las manos y asigna los dos caracteres en base al documento ISO 3166, creado y mantenido por las Naciones Unidas, que supuestamente tienen más claro lo que es un país, y la ICANN en última instancia, ante cualquier queja, puede decir: «lo que digan las Naciones Unidas».

En el proceso de respuesta a una consulta DNS, tienen mucha importancia las distintas caché que intervienen, pues reducen mucho el tiempo de respuesta. Las caché DNS son almacenes temporales de las últimas respuestas a consultas DNS; cuando se realiza una consulta lo primero que se hace es ver si la respuesta está en la caché y si es así, la respuesta se suministra directamente.

A las respuestas que se almacenan en las caché, se les asigna un tiempo, denominado tiempo de vida (TTL, Time To Live); si transcurrido dicho tiempo, la respuesta no es utilizada de nuevo, esta se elimina de la cache, liberando así espacio para almacenar otras respuestas.

La siguiente imagen ejemplifica todo el procedimiento de respuesta a una consulta DNS, incluyendo las caché:

Dos conceptos muy importantes, ya mencionados, son la zona y el fichero de zona que la describe, convirtiendo el nombre de dominio en entidades operacionales como equipos, servidores de correo, servicios y otras características usadas por el software DNS. Los subdominios delegados por el dueño del nombre de dominio, también pueden ser descritos utilizando un fichero de zona.

El fichero de zona describe, usando los denominados recursos de registro (RR, Resource Record), la parte del nombre de dominio que es manejada por el software DNS, es decir, la zona. El formato de estos ficheros y sus RR están estandarizados en el RFC 1035, por lo que pueden intercambiarse entre los distintos software DNS estándar que existen. Estos ficheros fundamentalmente suelen contener los siguientes RR:

• El RR SOA (Start Of Authority) que presenta las propiedades de la zona y es obligatorio.
• RR A y AAAA, que especifican los equipos (host) de la zona.
• Datos que describen información global de la zona como: los servidores de correo del dominio (RR MX), los servidores de nombres autoritarios del dominio (RR NS).
• En el caso de subdominios delegados, los servidores de nombres responsables del subdominio (RR NS).
• En el caso de subdominios delegados, un registro que permita alcanzar al servidor del dominio el servidor del subdominio (RR A o AAAA).

Solo, a modo de ejemplo, en este momento, un fichero de zona tiene el siguiente aspecto:

; IPv4 zone file for asir.com
$TTL 2d       ; default TTL for zone
$ORIGIN asir.com.
; Start of Authority record defining the key characteristics of the zone (domain)
@         IN    SOA     ns1.asir.com. hostmaster.asir.com. (
                        2016040800      ; sn = serial number
                        12h             ; refresh
                        15m             ; retry = refresh retry
                        3w              ; expiry
                        2h              ; nx = nxdomain ttl
                        )
; name servers Resource Records for the domain
          IN    NS      ns1.asir.com.
; the second name servers is
; external to this zone (domain).
          IN    NS      ns2.asir.net.
; mail server Resource Records for the zone (domain)
    3w    IN    MX      10    mail.asir.com.
; the second mail servers is
; external to the zone (domain)
          IN    MX      20    mail.otrodominio.com.
; domain hosts includes NS and MX records defined above
; plus any others required
ns1       IN    A       192.168.1.10
mail      IN    A       192.168.1.11
prof      IN    A       192.168.1.12
www       IN    A       192.168.1.13

El fichero de zona se encuentra en el servidor de nombres (servidor DNS), pero como ya se ha dicho, es aconsejable tener más de uno de estos servidores por seguridad, de hecho, en grandes empresas es frecuente instalar tres o más, y cada uno de ellos debe tener acceso al fichero de zona. Para resolver este problema de una forma cómoda para los administradores, el protocolo DNS establece que un único servidor será el maestro (master), el cual tendrá el fichero de zona que será actualizado; el resto de servidores, los esclavos (slave), recibirán una copia mediante lo que se denomina una transferencia de zona.

Es importante tener en cuenta que las respuestas a las consultas DNS, tanto del maestro como de los esclavos, son autoritarias sobre el nombre del dominio que implementa su fichero de zona.

Por último, para acabar con esta introducción, debemos hablar de los distintos programas que implementan el funcionamiento descrito anteriormente, es decir, el protocolo DNS.

El programa servidor DNS más ampliamente usado es BIND (Berkeley Internet Name Domain), que es una implementación multiplataforma de código abierto (licencia BSD) del protocolo DNS y llevada a cabo por la ISC (Internet Systems Consortium). La IETF lo califica como una implementación de alta calidad. También Microsoft tiene su propia implementación y otra importante es NSD. Como una implementación ligera podemos destacar dnsmasq, que además es un servidor de DHCP.

Históricamente los servidores raíz han usado BIND, pero el hecho de que todos tuvieran el mismo software suponía un problema de seguridad, pues si al programa, en un momento dado, se le descubriera un agujero de seguridad, todos los servidores raíz podrían ser atacados a la vez a través de él y podrían dejar de funcionar, con las consecuencias que ya, en este punto, nos podemos imaginar. Para evitar esto, algunos de los servidores raíz corren el servidor NSD.