José Urzúa Reinoso
    Tesis Magister

Resolvers

Los resolvers son programas que funcionan como una interfaz entre los programas de usuario y los servidores de nombres de dominio. En un caso simple, un resolver recibe requerimientos desde un programa de un usuario (programas de envío de emails, Telnet, FTP) en forma de una llamada de una sub-rutina o llamada de sistema, y responde con la información solicitada en una forma compatible con el formato de los datos del host local.

Un resolver podría estar ubicado físicamente en la misma máquina que los programas que solicitan sus servicios, pero el resolver necesitará consultar servidores de nombres que están funcionando en otros hosts. El tiempo que el resolver usará para responder una consulta, puede variar desde milisegundos a varios segundos, esto se debe a que el resolver puede obtener las respuestas consultando a servidores externos u obtener la información desde la memoria cache local.

Un objetivo importante del resolver es eliminar el tiempo de espera de respuesta de las redes y la carga en los servidores de nombres por una alta cantidad de requerimientos. Este objetivo lo cumple respondiendo los requerimientos usando su memoria cache, como primera prioridad. Esto permite que los cache que son compartidos por múltiples procesos, usuarios y máquinas son más eficientes que los cache no-compartidos.

La interfaz típica de un cliente con un resolver tiene tres funciones principales:

  1. Traducción de un nombre de host a una dirección IP. Esta función es a menudo definida como para imitar las funciones que cumplía el archivo HOSTS.TXT. Dado un grupo de caracteres, el cliente esperará una o más direcciones IP de 32 bits. Bajo el sistema del DNS esto se traduce en requerimientos que solicitan RRs de tipo A. Dado que el DNS no conserva el orden de los RRs, esta función que consulta podría tomarse el tiempo de ordenar las direcciones que obtuvo o seleccionar la mejor si el programa cliente sólo recibe una dirección IP como respuesta. Se recomienda que en las respuestas se retorne todas las direcciones IP que se encontraron.
  2. Traducción desde una dirección IP a un nombre de host. Dada una dirección IP de 32 bits, el cliente espera recibir un grupo de caracteres que identificarán un nombre de hosts. Los octetos de la dirección IP serán invertidos, usados como componentes de un nombre, y se agregará el sufijo IN-ADDR.ARPA. Una consulta de tipo PTR será usada para obtener el RR con el nombre primario del host. Por ejemplo, un requerimiento por el nombre de hosts correspondiente a la dirección IP 1.2.3.4 buscará los RRs de tipo PTR para el nombre de dominio 4.3.2.1.IN-ADDR.ARPA.
  3. Funciones generales de búsqueda. Esta función obtiene información arbitraria desde el DNS, y tiene contraparte en otros sistemas. El cliente provee un QNAME, QTYPE y QCLASS y espera recibir todos los RRs que concuerdan con el requerimiento. Esta función a menudo usa el formato del DNS para todos los datos que necesita.

Cuando el resolver decide que función es la que utilizará, comúnmente obtendrá uno de los siguientes resultados antes de pasarlos al cliente:

  • Uno o más RRs que entregan los datos requeridos. En este caso, el resolver entrega la respuesta en el formato adecuado.
  • Un error de nombre (Name Error, NE). Esto sucede cuando el nombre solicitado no existe. Por ejemplo, cuando el usuario comete algún error al escribir el nombre.
  • Un error de datos no encontrados. Esto sucede cuando el nombre que se solicita existe, pero los datos del tipo apropiado para la respuesta no se encuentra. Por ejemplo, al aplicar la función de buscar la dirección IP de un host a una casilla de email, aunque el nombre exista se generará el error por que el RR de tipo A no existe.

Es importante hacer notar que las funciones de traducción entre un nombre de host y una dirección IP, combinarán los errores de nombre y los de datos no encontrados, retornando un único tipo de error, pero en general esta función no debería hacerlo. Una razón para esto, es que la aplicación preguntará primero por un tipo de información del nombre, seguido por un nuevo requerimiento al mismo nombre pero por alguna información distinta, si los dos errores se combinan, las consultas inservibles harán mas lenta la aplicación.

Mientras un resolver se presta a responder un requerimiento particular, se puede encontrar con que el nombre en cuestión es un alias. Por ejemplo, el resolver está usando el nombre dado (que es un alias) para traducir del nombre de host a una dirección IP, por lo que encuentra un RR de tipo CNAME. Si es posible, el resolver retornará al cliente el alias que obtuvo, dependiendo de las condiciones. En muchos casos, el resolver simplemente reinicia la consulta con el nuevo nombre cuando encuentra un CNAME. Sin embargo, esto no debería realizarse por parte del resolver, pues pueden existir consultas en donde el QTYPE es por un CNAME, en donde el usuario está interesado en saber el RR de tipo CNAME por sí mismo, y no el RR que es apuntado por el alias.

Variadas condiciones especiales pueden ocurrir con el uso de alias. Múltiples niveles de alias deberían afectar la eficiencia con la que se obtienen las respuestas, pero no debería indicarse como un error. Ciclos de alias y alias que apuntan a nombres que no existen deben generar un error, el cual debe ser entregado al cliente.

En la figura 2.4, se puede apreciar un esquema de funcionamiento general entre un resolver, un servidor de nombres y otros resolver y servidores externos.

Figure 2.4: Ejemplo de Funcionamiento General.

 


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