José Urzúa Reinoso

Tesis Magister

Next: Problemas Comunes en el Up: Funcionamiento Previous: Algoritmo de un Resolver Contents

Algoritmo de Resolución

Los algoritmos actuales utilizados por los servidores de nombres dependen directamente del sistema operativo y de las estructuras de datos utilizadas para almacenar los RRs. El algoritmo que se describirá asume que los RRs son almacenados en una estructura con forma de árbol, uno por cada zona, y otros para el cache:

Asignar o sacar el valor que indica disponibilidad de recursión en la respuesta, dependiendo si el servidor de nombres provee este servicio o no. Si el servicio de recursividad está disponible y el requerimiento lo solicita (por medio del bit RD), se debe ir al paso 5, de lo contrario al paso 2.
Buscar en las zonas disponibles por la zona ancestro más cercana a QNAME. Si una zona es encontrada se va al paso 3, de lo contrario al paso 4.
Comienza la búsqueda hacia abajo, etiqueta por etiqueta, en la zona. El proceso de búsqueda puede tomar diferentes caminos:
- Si el QNAME es encontrado, se ha encontrado el nodo. Si la información del nodo es un CNAME, y el QTYPE no es un CNAME, copia el RR de tipo CNAME en la sección de respuesta, cambia el QNAME por el nombre canónico en el RR de tipo CNAME, y vuelve al paso 1. Si no, copia todos los RR que coinciden con QTYPE en la sección de respuesta y va al paso 6.
- Si algún calce con la respuesta está fuera de la zona autoritativa, se tiene una referencia. Esto sucede cuando se encuentra un nodo con RRs de tipo NS determinando el límite al final de la zona. Se copia los RRs de tipo NS para la sub-zona en la sección de autoridad de la respuesta. Se ponen las direcciones disponibles en la sección adicional, usando glue RRs si la dirección no está disponible en los datos autoritativos de cache. Se va al paso 4.
- Si para alguna etiqueta no se logra un calce, es decir, la etiqueta correspondiente no existe, se busca si la etiqueta * existe. Si la etiqueta * no existe, se revisa si el nombre que se está buscando es el QNAME original en la consulta o es un nombre que se tiene debido a un CNAME. Si el nombre es original, se asigna un error de nombre de manera autoritativa en la respuesta y retorna. Otro caso también retorna.
  Si la etiqueta * existe, compara este RRs contra el QTYPE. Si se encuentra un calce, lo copia en la sección respuesta, pero asigna el dueño del RR como el que viene en QNAME, y no el nodo con la etiqueta *. Se va al paso 6.
Comienza la búsqueda en el cache. Si QNAME es encontrado en el cache, se copia todos los RRs anexados a él, que calzan con QTYPE, en la sección respuesta. Si no existe delegación para los datos autoritativos, se busca el mejor desde el cache, y se asigna en la sección de autoridad. Se va al paso 6.
Usar un resolver local o una copia del algoritmo del resolver para responder la consulta. Almacenar el resultado, incluyendo cualquier CNAME intermediario, en la sección respuesta.
Usando solo información local, se agregan otros RRs que pueden ser útiles para la sección adicional de la consulta. Terminar.

En el algoritmo descrito, se puede apreciar que se entrega un tratamiento especial a los RRs, cuyo nombre de dueño comienza con *. Estos RRs son llamados wildcards, y son usadas como instrucciones para sintetizar RRs. Cuando se dan las condiciones apropiadas, el servidor de nombre crea RRs con un nombre de dueño igual al nombre que viene en la consulta, y el contenido se toma desde el RRs de tipo wildcard.

Los contenidos de un RR de tipo wildcard sigue las reglas y formato estándar de los RRs. Los wildcard en la zona tienen un dueño que controlará las consultas por nombres que ellos calzarán. El nombre del dueño del wildcard es de la forma: *.dominio, en donde dominio es cualquier nombre de dominio y no debe contener otra etiqueta * dentro de él, y debería ser un dato autoritativo para la zona. Los wildcard son aplicados para los descendientes del dominio, pero no para el dominio mismo.

Para mostrar el uso de los RRs de tipo wildcard, suponga el nombre de dominio de una institución llamado: universidad.cl. y un servidor llamado mail.universidad.cl. el cual actúa como servidor de emails para el dominio. Además, los siguientes registros están en la zona del dominio universidad.cl.:

universidad.cl.          IN    MX     10 mail.universidad.cl.
*.universidad.cl.        IN    MX     10 mail.universidad.cl.

mail.universidad.cl.     IN    A      146.83.4.11
mail.universidad.cl.     IN    MX     10 mail.universidad.cl.

*.mail.universidad.cl.   IN    MX     10 mail.universidad.cl.

Estos registros presentes en la zona, podrían causar que cualquier requirimiento por un registro de tipo MX de cualquier nombre de dominio que termine en universidad.cl. retornará un registro que apuntará a mail.universidad.cl.. El efecto del primer wildcard (*.universidad.cl.) es eliminado al colocar información explicita para el registro mail.universidad.cl. (registro A y MX respectivamente), por lo que para mantener el efecto del wildcard es necesario agregarlo nuevamente al final.

Estudios

Personal

Inicio