José Urzúa Reinoso
    Tesis Magister

Algoritmo de un Resolver

Cuando un resolver recibe un requerimiento de un usuario, generará una o más consultas DNS hacia los servidores de nombres adecuados. El algoritmo que utiliza el resolver para buscar las respuestas a las consultas, utiliza ciertas estructuras de datos que representan el estado de un requerimiento, las que son:

  • SNAME: El nombre del dominio para el cual se realizará la búsqueda.
  • STYPE: El QTYPE de la búsqueda solicitada.
  • SCLASS: Corresponde al QCLASS de la búsqueda solicitada.
  • SLIST: Es una estructura que describe los servidores de nombres y la zona en la cual el resolver está actualmente tramitando la consulta. Esta estructura mantiene la información de cual es el mejor servidor de nombres para la información que se desea buscar. Esta estructura contiene el equivalente a una zona, con el servidor de nombres de la zona, direcciones conocidas de ese servidor de nombres, e información histórica que puede ser usada para sugerir algún servidor de nombres como el mejor para responder alguna consulta.
  • SBELT: (Safety Belt) Es una estructura del mismo tipo que SLIST, la cual es inicializada desde un archivo de configuración, y una lista de servidores que deberían ser usados cuando el resolver no encuentra en la información local alguna guía para seleccionar un servidor de nombres adecuado.
  • CACHE: Estructura que almacena los resultados de las búsquedas ya realizadas. Desde que los resolvers son los responsables de eliminar los RRs para los cuales ha expirado su TTL, muchas implementaciones convierten ese TTL en un tiempo de ordenamiento cuando el RR es almacenado en el cache.

El algoritmo de más alto nivel utilizado por un resolver tiene cuatro pasos, que son:

  1. Revisar si la respuesta está en la información local, si es así, retornarla al cliente.
  2. Buscar los mejores servidores para consultar.
  3. Enviar las consultas a los mejores servidores hasta que alguno retorne una respuesta.
  4. Analizar la respuesta:
    • Si la respuesta responde la pregunta o contiene un name error, se almacena la información en cache y se responde al cliente.
    • Si la respuesta contiene una delegación a otro servidor, se almacena en cache la delegación y vuelve al paso 2.
    • Si la respuesta contiene un CNAME y no es lo solicitado, se almacena en cache el CNAME, se cambia el SNAME al canonical name en el CNAME RR y vuelve al paso 1.
    • Si la respuesta muestra una falla en el servidor u otro contenido erróneo, elimina el servidor de SLIST y vuelve al paso 3.

En el paso 1 se busca en cache por la información deseada. Si la información está en cache, se asume que es la mejor para el uso normal. Algunos resolvers tienen una opción en la interfaz de usuario que permite forzar al resolver a ignorar la información de cache y consultar a un servidor con autoridad. Esto no es recomendado por defecto.

En el paso 2 se busca un servidor de nombres para preguntar la información requerida. La estrategia general es buscar en los RRs disponibles localmente, comenzando con SNAME, luego el dominio padre de SNAME, luego el padre del padre de SNAME, y así sucesivamente hasta llegar hasta la raíz.

En el paso 3, se envían las consultas hasta que una respuesta es recibida. La estrategia es hacer un ciclo con todas las direcciones de todos los servidores con un tiempo de espera entre cada transmisión. En la práctica, es recomendable usar todas las direcciones IP de un servidor. La estructura SLIST contiene típicamente los valores para controlar los tiempos de espera y mantener alguna señal de las transmisiones previas.

En el paso 4 se analiza la respuesta. El resolver debería revisar que la respuesta corresponde a la consulta enviada por medio del campo ID en la respuesta. La respuesta ideal es de un servidor con autoridad para la consulta el cual entrega la información solicitada o un error de nombre. Los datos son enviados al usuario y se almacena en cache para un uso futuro si el TTL es mayor que cero. Más detalles de implementación se pueden revisar en el RFC 1035 [#!rfc:1035!#].

 


Estudios
Curriculum
Tesis Magister
Paper
Memoria
DTEs
CADCC 2002

Personal
Blog
Rugby
Xblast!
Parcela 31
Contacto


Inicio
Valid HTML 4.01! View Jose Urzua's profile on LinkedIn