Proceso de resolución de un nombre de dominio.

Proceso de resolución de un
nombre de dominio.
Javier Rodríguez Granados
Proceso de resolución de un
nombre de dominio.
La resolución de un nombre de dominio es la traducción
de un FQDN a su correspondiente dirección IP.
El proceso de resolución sería el siguiente:

En un programa del equipo local el usuario utiliza un
nombre de dominio totalmente cualificado (FQDN).

A continuación, el programa solicita al resolver la
resolución de ese nombre. Su modo de actuación
depende del sistema operativo:
GNU/Linux:

El resolver compara el nombre solicitado con el del propio host. Si es el
mismo, el nombre queda resuelto a la IP local. Para ello utiliza la
información que encuentra en el archivo /etc/hostname (que le informa
del nombre de máquina local) y la concatena con la indicada en la
directiva domain del archivo /etc/resolv.conf si la hubiera.

En caso de no haber resuelto el nombre, el resolver consulta los datos
del archivo /etc/hosts. Se trata de un archivo de texto que contiene por
cada línea una dirección IP y su correspondiente nombre de dominio
separados por un espacio o más (las líneas que empiezan con el
carácter 'almohadilla' son comentarios y no son tenidas en cuenta). Si el
resolver encuentra aquí la respuesta a su consulta detiene el proceso.

En caso contrario, el resolver comprueba que en la caché del resolver
no está la respuesta a la consulta en cuestión. Si está presente en ella,
el resolver ofrece este dato a la aplicación que lo solicitó y termina el
proceso.

Finalmente, si aún no se ha resuelto el nombre, el resolver procede a
consultar al primer servidor DNS que figure en el archivo
/etc/resolv.conf.
Windows:

El resolver compara el nombre solicitado con el del propio host. Si es el
mismo, el nombre queda resuelto a la IP local.

Se carga en la caché del resolver el contenido del archivo hosts. Este
archivo de Windows es un archivo de texto idéntico al utilizado por
GNU/Linux.

Se intenta resolver el nombre utilizando la caché del resolver (que,
aparte del contenido del archivo host, incluirá también las respuestas a
consultas DNS realizadas anteriormente). Si la consulta no coincide con
una entrada de la caché, el proceso de resolución continúa.

El resolver consultará al servidor DNS preferido (establecido de manera
gráfica por el usuario) tal y como se especifica a continuación.
Proceso de resolución de un
nombre de dominio.

Cuando el servidor DNS recibe la consulta del resolver, primero
comprueba su archivo de zona (en caso de que lo tenga). Si el
nombre consultado coincide con algún registro de su archivo de
zona, el servidor DNS responde al resolver con autoridad.

Si no existe ninguna información en la zona para el nombre
consultado, a continuación el servidor comprueba si puede resolver
el nombre mediante la información almacenada en su caché local
(que contendrá resultados de consultas anteriores).
Si aquí se encuentra una coincidencia, el servidor responde con
esta información.
Si aun no se ha conseguido una respuesta a la consulta, lo más
normal es que el servidor DNS siga intentando por todos los medios
resolverla, bien preguntando a otros servidores DNS que tenga
configurados (denominados forwarders) o bien preguntando
directamente a los servidores raíz.
Proceso de resolución de un
nombre de dominio.

Finalmente, cuando el servidor DNS obtiene por uno de los dos
medios la respuesta la envía al resolver. La respuesta se almacena
tanto en la caché del servidor DNS consultado como en la caché
local del resolver.
Consultas recursivas.
Consisten en la mejor respuesta que el servidor de nombres pueda
dar. En las consultas recursivas el servidor y no el cliente el que
pregunta a otros servidores de nombres por la información
solicitada del dominio.
En las resoluciones recursivas, el servidor no tiene la información
en sus datos locales, por lo que busca y se pone en contacto con un
servidor DNS raíz, y en caso de ser necesario repite el mismo
proceso básico (consultar a un servidor remoto y seguir a la
siguiente referencia) hasta que obtiene la mejor respuesta a la
pregunta.
Cuando existe más de un servidor autoritario para una zona, Bind
utiliza el menor valor en la métrica RTT para seleccionar el servidor.
El RTT es una medida para determinar cuánto tarda un servidor en
responder una consulta.
Consultas recursivas.
El proceso de resolución normal se da de la siguiente
manera:









1) El servidor A recibe una consulta recursiva desde el cliente DNS.
2) El servidor A envía una consulta recursiva a B.
3) El servidor B refiere a A otro servidor de nombres, incluyendo a C.
4) El servidor A envía una consulta recursiva a C.
5) El servidor C refiere a A otro servidor de nombres, incluyendo a D.
6) El servidor A envía una consulta recursiva a D.
7) El servidor D responde.
8) El servidor A regresa la respuesta al resolver.
9) El resolver entrega la resolución al programa que solicitó la información.
Consultas iterativas.
Las resoluciones iterativas consisten en la respuesta
completa que el servidor de nombres pueda dar. El
servidor de nombres consulta sus datos locales
(incluyendo su caché) buscando los datos solicitados.
El servidor encargado de hacer la resolución realiza
iterativamente preguntas a los diferentes DNS de la
jerarquía asociada al nombre que se desea resolver,
hasta descender en ella hasta la máquina que contiene
la zona autoritativa para el nombre que se desea
resolver.
Consultas iterativas.
Primero consulta sus datos locales, si no está allí busca
entonces en su cache y si aún no encuentra nada
devuelve la respuesta al servidor más cercano al
dominio buscado. Si el servidor falla, no lo vuelve a
reintentar.
Caché y TTL.

Como en casi todos los procesos donde se realizan consultas
disponemos de una caché para acelerar éstas. El almacenamiento
en caché es el proceso de almacenar temporalmente la información
que se acaba de consultar en una memoria rápida. De esta forma si
se vuelve a consultar en lugar de realizar una consulta DNS lo que
se hace es recuperarla de esa rápida memoria ganando mucho
tiempo.
Caché y TTL.
Cuando un servidor está procesando una consulta recursiva es
posible que se tengan que realizar varias consultas hasta encontrar
la respuesta definitiva. En el peor de los casos para resolver un
nombre, el servidor local comienza en la raíz del DNS y va mirando
hacia abajo hasta que encuentra los datos solicitados.
Para mejorar estos tiempos de consulta, el servidor guarda la
información de la resolución en su caché durante un tiempo. Este
periodo de tiempo se denomina Time to Live (TTL) y se especifica
en segundos.
El administrador del servidor que contiene la zona primaria es el
que tiene este valor del TTL. Cuanto más pequeño sea el valor del
TTL, más consistentes serán los datos, por contra generará más
carga de trabajo en el servidor.
Caché y TTL.
Una vez que el servidor guarda los datos en la caché, el tiempo TTL
empieza a descontarse hasta llegar a 0, en ese momento se borra
de la caché. Mientras el valor de TTL esté activo lógicamente el
servidor DNS resolverá las peticiones de consulta con su caché.
Esta es la razón por la cual los cambios realizados en el DNS no se
propagan instantáneamente a través del sistema. Dependiendo de
la naturaleza de los mismos (y de la configuración de cada
servidor), la propagación puede tardar desde algunos minutos hasta
varios días. Correo electrónico y resolución de nombres.
Recursividad y caché.
El recursivo es un servidor capaz de encontrar la respuesta a
cualquier consulta DNS, y puede encontrar información acerca de
casi todos los dominios, por ejemplo google.com, linux.org,
gentoo.org .
Generalmente estos servidores están abiertos a cualquier IP , en
otras palabras, pueden ser consultados por cualquier maquina en el
mundo.
El problema es que muchas entidades hacen que el mismo servidor
actúe tanto como autoritativo como recursivo. Una práctica sana es
tenerlos separados, lo cual previene el problema denominado
"envenenamiento de cache".
Si es imposible tenerlos separados, es recomendable que permitan
recursión a solo un rango de IPs "confiables".
Recursividad y caché.
Posibles riesgos de tener un servidor recursivo en
Internet:
Ser una víctima de ataques de envenenamiento de
caché, la cual hace que el servidor afectado almacene
información falsa.
Dicha información puede ser utilizada para comprometer
la seguridad de los clientes que hacen consultas al
servidor afectado, por ejemplo redireccionar google.com
a un sitio con malware, o redireccionar sitios de bancos
con la intención de obtener información confidencial del
usuario.
Recursividad y caché.
El servidor podría ser ocupado para un ataque DoS
distribuido el cual puede tener las siguientes
consecuencias:

La gran cantidad de consultas DNS recibidas por el
servidor y la gran cantidad de respuestas enviadas a la
víctima pueden consumir una considerable cantidad de
ancho de banda.

Problemas legales ya que si, por ejemplo, un equipo de
un ISP ataca a un cliente, seguramente el cliente lo
demandará.