 |
Tesis Magister |
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.
|
|