Resolución de Nombres

Una vez que se han configurado las direcciones IP y el ruteo, una red TCP/IP se encuentra totalmente operativa. Sin embargo, a los fines prácticos hay que cumplimentar un paso adicional: la configuración de la resolución de nombres.

Un servicio de resolución de nombres permite a las computadoras de una red transformar nombres en direcciones numéricas y viceversa.

Sabemos que, a fin de acceder a servicios a través de la red, es necesario hacer referencia a aquellas computadoras que los ofrecen, las cuales se conectan a una o más redes por medio de interfaces. Como se ha visto, cada interfaz de red conectada a una red TCP/IP se identifica con una dirección IP numérica, por lo que para hacer referencia a la misma, es necesario conocer dicho número.

Si bien los protocolos de comunicaciones y las aplicaciones informáticas se sienten a gusto utilizando números, no ocurre lo mismo con las personas, quienes prefieren utilizar nombres para designar a las computadoras de la red, ya que son más fáciles de recordar. Seguramente es más probable que el nombre del sitio web de la UTN Facultad Córdoba (www.frc.utn.edu.ar) esté mas presente en la memoria de sus usuarios que su dirección IP (170.210.248.211).

Otra razón para utilizar nombres en lugar de números es el aislar a los usuarios de posibles cambios en la distribución de las direcciones IP. Por ejemplo, si el programa que habitualmente se utiliza para leer correo electrónico está configurado para obtener mensajes a partir de la dirección IP 172.16.4.205, el administrador de red necesitará notificar a todos los usuarios que deberán reconfigurarlo si el servidor de correo se muda a otro equipo, o si la dirección IP del equipo en el que reside se cambia por alguna razón. Por medio de la utilización del servicio de resolución de nombres, el programa de correo electrónico puede configurarse para obtener los mensajes de una máquina llamada, por caso, mailhost, independientemente de dónde se ubique físicamente.

La tabla de Hosts

Para implementar un servicio de nombres es necesario confeccionar una lista en la que se relacionen nombres con direcciones IP; cuando un programa necesita resolver un nombre (esto es, dado un nombre encontrar la dirección IP), debe consultar dicha lista.

En un principio, la resolución de nombres se implementó por medio de un archivo ubicado en cada máquina de la red que contenía dicha lista. En el caso de Unix, ese archivo es el /etc/hosts y tiene el siguiente formato:

#
# Tabla de resolución de nombres
#
127.0.0.1 localhost
170.25.1.1 antares
170.25.1.2 rigel
170.25.1.254 orion
170.25.2.1 altair
170.25.2.254 orion
170.25.3.1 aldebaran
170.25.3.253 andromeda
170.25.3.254 orion
170.25.4.1 canoups
170.25.4.253 centauri
170.25.4.254 andromeda

Las líneas que comienzan con # se consideran comentarios y son ignoradas, mientras que las demás asocian un número de IP con el nombre asociado a la computadora.

Así, cuando el usuario ejecuta un comando como

$ telnet aldebaran

el programa telnet antes de iniciar la conexión transforma el nombre aldebaran en la dirección IP 170.25.3.1, según se consigna en la tabla de hosts.

Obsérvese además que los gateways de la red figuran varias veces en el listado, según la cantidad de interfaces que posean. También es posible asignar mas de un nombre a una misma interfaz (denominados alias):

170.25.1.254 orion mailhost

De esta manera, el comando

$ telnet orion

resulta totalmente equivalente al comando

$ telnet mailhost

La tabla de hosts provee de un mecanismo sencillo para implementar la resolución de nombres. Sin embargo, a medida que la red crece y debido a que la información está duplicada en cada host de la red, su mantenimiento se hace cada vez más trabajoso. La situación se complica si varias redes TCP/IP se interconectan, en cuyo caso, a las tareas de sincronización de tablas entre diferentes hosts hay que sumar el control de nombres duplicados para máquinas diferentes.

Para solucionar estos problemas de escalabilidad, el mecanismo de resolución de nombres evolucionó hacia uno mucho más sofisticado: el Servicio de Nombres de Dominio, o DNS (Domain Name Service).

Sin embargo, aún cuando se utilice DNS, es necesario contar con una tabla de hosts mínima a ser utilizada por el sistema operativo durante el arranque, con información suficiente para resolver el nombre de la máquina y el nombre "localhost" asociado con la dirección de loopback. Por ejemplo, la tabla de hosts de Canopus debiera contener mínimamente lo siguiente:

127.0.0.1 localhost
170.25.4.1 canoups

Servicio de Nombres de Dominio (DNS)

La tabla de hosts fue reemplazada por un esquema mucho más potente y flexible, adecuado para las necesidades de escalabilidad y tolerancia a fallas de grandes redes como la Internet.

El DNS es un servicio cliente/servidor, en el cual cuando un proceso necesita resolver un nombre se contacta vía TCP/IP20 con otro proceso, llamado servidor de nombres, quien realiza el proceso de resolución y retorna una respuesta. Como en todo sistema cliente/servidor, ambos procesos pueden ejecutarse sobre la misma maquina o en máquinas completamente diferentes.

Un servidor DNS mantiene la lista de direcciones y nombres de una o más agrupaciones de computadoras, llamadas dominios. Dichas agrupaciones se forman de manera conceptual (por área geográfica, motivos organizacionales, por proyectos, etc.) y no tienen necesariamente que tener un correlato con direcciones de red o estructura de subredes.

Además de contener computadoras, un dominio puede particionarse en otros subdominios. Este particionamiento se realiza a los fines de permitir la delegación de tareas administrativas. El administrador de un subdominio puede cambiar datos de las computadoras del mismo e incluso crear nuevos subdominios que delegar a terceros.

Esto da como resultado una estructura jerárquica, similar a un árbol invertido, en donde para llegar a un dominio en particular, se debe seguir una trayectoria de dominios encadenados a partir de un dominio raíz.

Inmediatamente por debajo del dominio raíz, se encuentran los dominios de alto nivel. Inicialmente, los diseñadores de ARPANET (la red predecesora de Internet) concibieron los dominios de alto nivel como dominios organizacionales:

 

Mas tarde, en vistas a la expansión de la Internet por todo el mundo, se crearon nuevos dominios de alto nivel, uno por cada país: los dominios regionales. Los dominios regionales se designan según un estándar internacional llamado ISO 3166, que asigna a cada país un código de dos letras21. Por ejemplo:

 

La administración del DNS a escala global recae en un organismo llamado Internet Network Information Center (o InterNIC), al cual debe recurrirse para solicitar la creación de un subdominio de los dominios de alto nivel. El InterNIC, por su parte, delega la administración de los dominios regionales a las autoridades del país correspondiente; en el caso de la Argentina, es responsabilidad de la Cancillería.

Dichas organizaciones son las responsables de decidir la forma en que particionarán el dominio regional. Usualmente, tal como ocurre en Argentina, deciden hacer un paralelo de los dominios organizacionales de alto nivel. Así, por ejemplo, existen los dominios com.ar, org.ar, gov.ar, edu.ar, etc. Sin embargo, algunos países deciden seguir algún otro tipo de esquema; por ejemplo, algunos de los subdominios de Gran Bretaña son co.uk (por "corporations"), ac.uk (por "academic community"), etc.

Cuando una organización poseedora de una red desea que se le asigne un dominio, deberá primero decidir bajo que dominio desea ubicarse, para luego solicitar al organismo que lo administre la delegación de un subdominio. Si dicho organismo considera pertinente la solicitud, creará el dominio solicitado y a partir de ese momento la organización solicitante será la responsable de administrarlo, pudiendo agregar máquinas al dominio o incluso particionarlo en mas subdominios.

Por ejemplo, la Universidad Tecnológica Nacional gestionó en Cancillería el dominio utn.edu.ar al cual pertenecen las computadoras del Rectorado (en Buenos Aires); luego decidió crear un subdominio para cada una de sus Facultades Regionales. Así, por ejemplo, existen los dominios frc.utn.edu.ar (Facultad Córdoba), frba.frc.utn.edu.ar (Facultad Buenos Aires), frlp.frc.utn.edu.ar (Facultad La Plata), etc.

Dentro de un dominio, sus administradores están en libertad de crear nombres para sus computadoras. El nombre que se asigne a cada máquina se combinará con el nombre del dominio para formar el Nombre de Dominio Totalmente Calificado (conocido como FQDN, por Fully Qualified Domain Name), tal como:

khitomer.frc.utn.edu.ar

De esta manera, aunque dos dominios tengan máquinas con el mismo nombre, siempre será posible distinguirlas por medio del FQDN23.

En síntesis, la estructura del DNS puede reflejarse de la siguiente manera (con el dominio raíz representado por un punto):

Resolución de nombres basada en DNS

Supongamos que un programa ejecutándose en una máquina en el dominio frc.utn.edu.ar requiere iniciar una conexión con otra computadora. Dado que el primer paso es obtener su dirección IP, dicha aplicación deberá realizar una petición de resolución a algún server de nombres.

Como se mencionó anteriormente, un server de nombres posee las tablas de direcciones y nombres referentes a uno o más dominios. Si la petición de resolución hace referencia a una máquina perteneciente a alguno de los dominios administrados localmente (en cuyo caso se dice que el server tiene autoridad sobre ese dominio), el server consulta la tabla respectiva y contesta la petición. En caso contrario deberá realizar una serie de consultas siguiendo la jerarquía de dominios a partir del dominio raíz, hasta encontrar el server que tiene autoridad sobre el dominio al cual pertenece el nombre buscado.

Supongamos, por ejemplo, que se intenta resolver el nombre andromeda.galaxia.org.ar. El server de nombres local (frc.utn.edu.ar) redirige la consulta a los servidores de nombres del dominio raíz, los cuales le contestan con la dirección IP del server DNS del dominio ar. El server local realiza una nueva consulta, esta vez al server de ar, quien responde con la dirección del server que tiene autoridad sobre org.ar. Tras una nueva consulta, el server local recibe la dirección del servidor de nombres de galaxia.org.ar, que al ser consultado retorna la dirección IP de la computadora andrómeda.

Esta estrategia de consulta se denomina iterativa, debido a que el server de nombres local recibe como respuesta la dirección de otro server de nombres, por lo que debe repetir la operación (esto es, iterar) hasta que reciba la dirección IP del nombre a resolver. Existe otra posible configuración, llamada recursiva, según la cual un server de nombres puede ser configurado de tal forma que retorne siempre la dirección final buscada; si, por ejemplo, el server de nombres de ar fuera recursivo, en vez de retornar la dirección de org.ar para que luego el server que inició la consulta continúe iterando, realizaría la iteración él mismo.

Cualquiera sea la estrategia utilizada, puede observarse que una única resolución implica múltiples consultas a través de la Internet. Para minimizar demoras en las comunicaciones, el diseño del DNS incluye la posibilidad de que los servidores de nombres guarden temporalmente las respuestas a las consultas que se han recibido, es decir, mantienen un cache de consultas previas que pueden ser reutilizadas si la consulta se repite.

El Dominio de Reversa

Un server DNS permite también realizar operaciones de resolución inversa, esto es, obtener un nombre a partir de una dirección IP. Para ello, existe un dominio especial llamado in-addr.arpa y conocido como dominio de reversa, cuyos subdominios se forman a partir de los valores numéricos de las direcciones IP, tomados en orden inverso.

Por ejemplo, la dirección IP 170.25.3.1, pertenece al dominio de reversa 1.3.25.170.in-addr.arpa.

Cuando a una red se le asigna un número de red, usualmente también se le delega la administración de su correspondiente dominio de reversa. Por ejemplo, el dominio de reversa correspondiente a 170.25 sería 25.170.in-addr.arpa, quedando en manos de su administrador la decisión de crear subdominios para cada una de sus subredes (por ejemplo, 1.25.170.in-addr.arpa, 2.25.170.in-addr.arpa, etc.)
 

 


20. Estrictamente, la comunicación entre el cliente y el server DNS se realiza mediante conexiones UDP.

21. A pesar de esto, y por tradición histórica, las organizaciones norteamericanas no se inscriben en el dominio regional de los EE.UU sino directamente en los dominios organizacionales de alto nivel.

22. En "DNS and BIND" de Albitz & Cricket se hace la siguiente aclaración: "La excepción es Gran Bretaña. De acuerdo a ISO 3166 el dominio de la Gran Bretaña debiera ser gb, pero en su lugar, Gran Bretaña e Irlanda del Norte utilizan uk (por United Kingdom). También conducen los automóviles del lado equivocado de la calle"

23. De hecho, la única forma de referenciar una computadora desde otra red es por medio de su FQDN.