Proceso de resolucin 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: l En un programa del equipo local el usuario utiliza un nombre de dominio totalmente cualificado (FQDN). l 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: l 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. l 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. l 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. l 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: l El resolver compara el nombre solicitado con el del propio host. Si es el mismo, el nombre queda resuelto a la IP local. l 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. l 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. l 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. l 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. l 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. l 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: l l l l l 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. l 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 Do. S distribuido el cual puede tener las siguientes consecuencias: l 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. l Problemas legales ya que si, por ejemplo, un equipo de un ISP ataca a un cliente, seguramente el cliente lo demandará.