Consulta iterativa y recursiva

Al preguntar a un servidor DNS se pueden realizar dos tipos de consulta: la consulta iterativa y la consulta recursiva.

Una consulta DNS es una pregunta que un cliente DNS le hace a un servidor DNS. Un servidor DNS almacena registros de recursos especificados con un nombre DNS especificado. Un cliente DNS pregunta a un servidor DNS por los registros que este almacena en su base de datos.

Un cliente necesita la dirección IP de un recurso y consulta a un servidor DNS preguntando por un nombre de dominio. El servidor DNS resuelve un nombre de dominio en una dirección IP. El servidor DNS responde al cliente DNS con una dirección IP.

Las consultas a la base de datos DNS se llevan a cabo entre un cliente DNS y un servidor DNS, o entre dos servidores DNS. Si la pregunta se realiza con un nombre de dominio decimos que la búsqueda es directa pero si la pregunta se realiza con una dirección IP decimos que es una búsqueda inversa.

Tipos de consultas DNS

Como mencionamos al inicio de este artículo las consultas a un servidor DNS pueden ser consulta recursiva o iterativa. Es decir, tenemos la consulta DNS recursiva y la consulta DNS iterativa.

Para distinguir una consulta recursiva de una consulta iterativa tenemos que tener en cuenta la información con la que se pregunta, la información que se solicita y se espera y los agentes que intervienen en dicha consulta.

Consulta recursiva

Una consulta recursiva obliga a un servidor DNS para responder a una solicitud con un error o una respuesta de éxito. Los clientes DNS (resoluciones) normalmente realizan consultas recursivas. Con una consulta recursiva, el servidor DNS debe ponerse en contacto con otros servidores DNS que necesita para resolver la solicitud. Cuando reciba una respuesta correcta de DNS (los otros servidores), a continuación, envía una respuesta al cliente DNS. La consulta recursiva es el tipo de consulta típica usado por una resolución de consultas a un servidor DNS y por un servidor DNS consulta su reenviador, que es otro servidor DNS configurado para procesar solicitudes reenviadas a él.

Cuando un servidor DNS procesa una consulta recursiva y la consulta no se puede resolver desde datos locales (archivos de zona local o caché de consultas anteriores), la consulta recursiva debe trasladarse a un servidor DNS raíz. Cada aplicación basada en estándares de DNS incluye un archivo de caché o sugerencias del servidor raíz que contiene entradas para los servidores DNS de raíz de los dominios de Internet. (Si el servidor DNS está configurado con un reenviador, el reenviador se utiliza antes de que se utilice un servidor raíz.)

Consulta iterativa

Una consulta iterativa es uno en el que se espera que el servidor DNS responda con la mejor información local que tiene, basado en lo que sabe el servidor DNS de los archivos de zona local o de la caché. Esta respuesta es también conocida como una remisión, si el servidor DNS no está autorizado para el nombre. Si un servidor DNS no tiene ninguna información local que puede responder la consulta, simplemente envía una respuesta negativa. Un servidor DNS realiza este tipo de consulta al intentar encontrar nombres fuera de su dominio local (o dominios) (al no está configurado con un reenviador). Podría tener que consultar un número de servidores DNS externos en un intento de resolver el nombre.

Veamos un ejemplo de ambos tipos de consultas.

Ejemplo de consulta DNS

La figura muestra que un número de consultas se utilizaron para determinar la dirección IP de www.whitehouse.gov. La secuencia de consulta se describe a continuación:

• Consulta recursiva para www.whitehouse.gov (registro de recursos)
• Consulta iterativa para www.whitehouse.gov (registro de recursos)
• Referencia al servidor de nombre .gov (registros de recursos NS, para .gov);Para mayor simplicidad, recurrentes consulta por el servidor DNS (a la izquierda) para resolver las direcciones IP del Host, nombres del servidor de nombres devuelven por otros servidores DNS se han omitido.
• Consulta iterativa para www.whitehouse.gov (registro de recursos)
• Referencia al servidor de nombres de whitehouse.gov (registro de recursos NS, para whitehouse.gov)
• Consulta iterativa para www.whitehouse.gov (registro de recursos)
• Respuesta a la consulta iterativa del servidor de whitehouse.gov (dirección IP de www.whitehouse.gov)
• Respuesta a la consulta recursiva original del servidor DNS local para la resolución (dirección IP de www.whitehouse.gov)

Time-to-Live para registros de recursos

El valor de Time-to-Live (TTL) en un registro de recursos indica un período de tiempo utilizado por otros servidores DNS para determinar cuánto tiempo en caché la información de un registro antes de caducar y descartarlo. Por ejemplo, la mayoría de los registros de recursos creados por el servicio servidor DNS heredan el TTL mínimo (predeterminado) de una hora desde el inicio del registro de recursos de autoridad (SOA), lo que impide que extendido otros servidores DNS en caché.

Resolución de un cliente DNS almacena en caché las respuestas que recibe cuando resuelva las consultas DNS. Estos en caché respuestas entonces se utiliza para responder las consultas posteriores de la misma información. Los datos en caché, sin embargo, tienen una vida limitada especificada en el parámetro TTL devuelto con los datos de respuesta. TTL garantiza que el servidor DNS no mantiene información de tanto tiempo que se convierte en obsoleto. TTL de la caché se puede establecer en la base de datos DNS (para cada registro de recursos individuales, especificando el campo TTL del registro y cada zona mediante el campo TTL mínimo del registro SOA) así como en el lado de resolución del cliente DNS especificando el TTL máximo la resolución permite almacenar en caché los registros de recursos.

Hay dos factores opuestos entre sí a tener en cuenta al establecer el valor de TTL. La primera es la precisión de la información almacenada en caché y el segundo es la utilización de los servidores DNS y la cantidad de tráfico de red. Si el TTL es breve, a continuación, la probabilidad de que la información se reduce considerablemente, pero aumenta la utilización de los servidores DNS y tráfico de red, ya que el cliente DNS debe consultar servidores DNS para los datos caducados la próxima vez que se solicite. Si el período de vida es larga, las respuestas almacenadas en caché pueden quedarse anticuadas, lo que significa que la resolución podría enviar respuestas incorrectas a las consultas. Al mismo tiempo, un valor del TTL disminuye la utilización de los servidores DNS y reduce el tráfico de red porque el cliente DNS responde a las consultas con sus datos en caché.

Si se responde a una consulta con una entrada de caché, el período de vida de la entrada también se pasa con la respuesta. De este modo las resoluciones que recibe la respuesta saben cuánto la entrada es válida. Las resoluciones de respetan el período de vida desde el servidor de respuesta;no restablece basándose en su propio período de vida. En consecuencia, las entradas realmente caducan lugar live a perpetuidad cuando pasen de servidor DNS al servidor DNS con un valor TTL.

Nota En general, no configure nunca el valor de TTL a cero. La diferencia entre el valor 0 ó 60 es mínima a la exactitud del registro, pero cuando el TTL se establece en 0, hay un impacto significativo en el rendimiento del servidor DNS porque el servidor DNS está consultando constantemente los datos caducados.