¿Cómo funciona, en principio, la resolución de nombres DNS?

Question 1

Suponiendo que su servidor de nombres configurado no tiene ningún resultado almacenado en caché a su disposición, ¿cuántos servidores de nombres debe consultar su servidor de nombres para resolver maps.google.com? ¿Qué comando(s) usarías para encontrar todos estos servidores de nombres? Enumere uno de cada nivel y explique por qué es necesario este nivel.

Bueno, analicemos este.

"Suponiendo que su servidor de nombres configurado no tenga ningún resultado almacenado en caché a su disposición"-- en primer lugar, si tieneNodatos almacenados en caché, entonces no puede resolver nada. Para preparar el caché del solucionador, necesita tener los registros NS y de dirección (A, AAAA) para la .zona (también conocida como raíz). Esos son los servidores de nombres raíz, que se encuentran en la root-servers.net.zona. No hay nada mágico en esa zona o esos servidores DNS. Sin embargo, estos datos a menudo se proporcionan "fuera de banda" al solucionador de DNS, precisamente para preparar el caché del solucionador. Los servidores de nombres exclusivamente autorizados no necesitan estos datos, pero los servidores de nombres de resolución sí.

Además, ¿"resolver" qué? ¿Algún tipo de RR con ese nombre? ¿Un ARR? ¿O algo mas? ¿Qué clase ( CH/Chaosnet, IN/Internet, ...)? El proceso exacto será diferente, pero la idea general sigue siendo la misma.

Si podemos asumir que sabemos cómo encontrar los servidores de nombres raíz pero nada más, y que por "resolver" nos referimos a obtener el contenido de cualquier IN ARR asociado con el nombre, se vuelve mucho más práctico.

Para resolver un nombre DNS, básicamente divide el nombre en etiquetas y luego avanza de derecha a izquierda. No olvides el .al final; realmente estarías resolviendo maps.google.com.en lugar de maps.google.com. Eso nos deja con la necesidad de resolver (lo sabemos, pero una implementación de resolución de DNS probablemente no lo haga):

.
com.
google.com.
maps.google.com.

Empiece por averiguar dónde solicitar el contenido de .. Eso es fácil; ya tenemos esa información: el servidor de nombres raíznombres y direcciones IP. Entonces tenemos un servidor de nombres raíz. Digamos que decidimos usar 198.41.0.4 ( a.root-servers.net, también 2001:503:ba3e::2:30) para continuar con la resolución de nombres. En la práctica, una de las primeras cosas que hará el solucionador probablemente será utilizar los datos del servidor raíz proporcionados para solicitar a uno de los servidores de la zona raíz una lista precisa de los servidores de nombres para la zona raíz, garantizando así que si alguno de los nombres y las direcciones IP son válidos y accesibles, tendrá un conjunto completo de datos para la zona raíz cuando comience la resolución.

Realice una consulta DNS para maps.google.com. IN A198.41.0.4. Te dirá en respuesta "no, no lo haré, pero aquí hay alguien que quizás lo sepa"; eso es una referencia. Contiene NSregistros de la zona más cercana que conoce el servidor en cuestión, junto con cualquier registro adhesivo que el servidor tenga disponible. Si no hay datos de pegamento disponibles, primero debe resolver el host nombrado en el registro NS que eligió, así que genere una resolución de nombre separada para obtener la dirección IP; Si hay datos de pegamento disponibles, tendrá la dirección IP de un servidor de nombres que esté al menos "más cerca" de la respuesta. En este caso, ese será el conjunto de servidores para la com.zona y también se proporcionan datos de pegamento.

Repita el proceso y haga com.la misma pregunta a uno de los servidores de nombres. Ellos tampoco lo saben, pero le derivarán a los servidores de nombres autorizados de Google. En este punto, en el caso general, será impredecible si se proporcionan o no datos de pegamento; no hay nada que impida que un comdominio tenga servidores de nombres solo ennl , por ejemplo, en cuyo caso es poco probable que los datos adhesivos estén disponibles en los servidores gTLD. Los datos sobre el pegamento proporcionados también pueden estar incompletos o, si tienes mucha mala suerte, ¡incluso pueden ser incorrectos! Tienes quesiempreEsté preparado para generar esa resolución de nombre separada que mencioné anteriormente.

Básicamente, continúa hasta obtener una respuesta con el aaindicador (respuesta autorizada) configurado. Esa respuesta le dirá lo que está pidiendo o que el RR que solicitó no existe (ya sea NXDOMAINcon NOERRORregistros de datos de respuesta cero). Siga atento a respuestas como SERVFAIL(y retroceda un paso y pruebe con otro servidor si obtiene uno; si todos los servidores nombrados devuelven SERVFAIL, falle el proceso de resolución de nombres y regrese SERVFAILal cliente).

La alternativa a solicitar el nombre RR completo de cada servidor (lo que podría considerarse una mala práctica) es utilizar la lista dividida de etiquetas que determinamos anteriormente, solicitar los servidores de nombres proporcionados por el servidor más hacia la raíz para IN NSy IN A/ IN AAAARRs. para esa etiqueta y utilícelos para avanzar en el proceso de resolución de nombres. En la práctica, esto es sólo marginalmente diferente y se sigue aplicando el mismo proceso.

Puede simular todo este proceso utilizando la +traceopción de la digutilidad, que viene como parte de BIND, o set debugen formato nslookup.

También vale la pena recordar que algunos tipos de RR (en particular NS, MXy algunos otros; además,A6 se usó razonablemente bien durante un tiempo pero ha quedado obsoleto) pueden hacer referencia a otros RR, y lo hacen. En ese caso, es posible que tengas que generaraún otraproceso de resolución de nombres para dar una respuesta completa y útil a su cliente.

Answer

Suponiendo que su servidor de nombres configurado no tiene ningún resultado almacenado en caché a su disposición, ¿cuántos servidores de nombres debe consultar su servidor de nombres para resolver maps.google.com? ¿Qué comando(s) usarías para encontrar todos estos servidores de nombres? Enumere uno de cada nivel y explique por qué es necesario este nivel.

Bueno, analicemos este.

"Suponiendo que su servidor de nombres configurado no tenga ningún resultado almacenado en caché a su disposición"-- en primer lugar, si tieneNodatos almacenados en caché, entonces no puede resolver nada. Para preparar el caché del solucionador, necesita tener los registros NS y de dirección (A, AAAA) para la .zona (también conocida como raíz). Esos son los servidores de nombres raíz, que se encuentran en la root-servers.net.zona. No hay nada mágico en esa zona o esos servidores DNS. Sin embargo, estos datos a menudo se proporcionan "fuera de banda" al solucionador de DNS, precisamente para preparar el caché del solucionador. Los servidores de nombres exclusivamente autorizados no necesitan estos datos, pero los servidores de nombres de resolución sí.

Además, ¿"resolver" qué? ¿Algún tipo de RR con ese nombre? ¿Un ARR? ¿O algo mas? ¿Qué clase ( CH/Chaosnet, IN/Internet, ...)? El proceso exacto será diferente, pero la idea general sigue siendo la misma.

Si podemos asumir que sabemos cómo encontrar los servidores de nombres raíz pero nada más, y que por "resolver" nos referimos a obtener el contenido de cualquier IN ARR asociado con el nombre, se vuelve mucho más práctico.

Para resolver un nombre DNS, básicamente divide el nombre en etiquetas y luego avanza de derecha a izquierda. No olvides el .al final; realmente estarías resolviendo maps.google.com.en lugar de maps.google.com. Eso nos deja con la necesidad de resolver (lo sabemos, pero una implementación de resolución de DNS probablemente no lo haga):

.
com.
google.com.
maps.google.com.

Empiece por averiguar dónde solicitar el contenido de .. Eso es fácil; ya tenemos esa información: el servidor de nombres raíznombres y direcciones IP. Entonces tenemos un servidor de nombres raíz. Digamos que decidimos usar 198.41.0.4 ( a.root-servers.net, también 2001:503:ba3e::2:30) para continuar con la resolución de nombres. En la práctica, una de las primeras cosas que hará el solucionador probablemente será utilizar los datos del servidor raíz proporcionados para solicitar a uno de los servidores de la zona raíz una lista precisa de los servidores de nombres para la zona raíz, garantizando así que si alguno de los nombres y las direcciones IP son válidos y accesibles, tendrá un conjunto completo de datos para la zona raíz cuando comience la resolución.

Realice una consulta DNS para maps.google.com. IN A198.41.0.4. Te dirá en respuesta "no, no lo haré, pero aquí hay alguien que quizás lo sepa"; eso es una referencia. Contiene NSregistros de la zona más cercana que conoce el servidor en cuestión, junto con cualquier registro adhesivo que el servidor tenga disponible. Si no hay datos de pegamento disponibles, primero debe resolver el host nombrado en el registro NS que eligió, así que genere una resolución de nombre separada para obtener la dirección IP; Si hay datos de pegamento disponibles, tendrá la dirección IP de un servidor de nombres que esté al menos "más cerca" de la respuesta. En este caso, ese será el conjunto de servidores para la com.zona y también se proporcionan datos de pegamento.

Repita el proceso y haga com.la misma pregunta a uno de los servidores de nombres. Ellos tampoco lo saben, pero le derivarán a los servidores de nombres autorizados de Google. En este punto, en el caso general, será impredecible si se proporcionan o no datos de pegamento; no hay nada que impida que un comdominio tenga servidores de nombres solo ennl , por ejemplo, en cuyo caso es poco probable que los datos adhesivos estén disponibles en los servidores gTLD. Los datos sobre el pegamento proporcionados también pueden estar incompletos o, si tienes mucha mala suerte, ¡incluso pueden ser incorrectos! Tienes quesiempreEsté preparado para generar esa resolución de nombre separada que mencioné anteriormente.

Básicamente, continúa hasta obtener una respuesta con el aaindicador (respuesta autorizada) configurado. Esa respuesta le dirá lo que está pidiendo o que el RR que solicitó no existe (ya sea NXDOMAINcon NOERRORregistros de datos de respuesta cero). Siga atento a respuestas como SERVFAIL(y retroceda un paso y pruebe con otro servidor si obtiene uno; si todos los servidores nombrados devuelven SERVFAIL, falle el proceso de resolución de nombres y regrese SERVFAILal cliente).

La alternativa a solicitar el nombre RR completo de cada servidor (lo que podría considerarse una mala práctica) es utilizar la lista dividida de etiquetas que determinamos anteriormente, solicitar los servidores de nombres proporcionados por el servidor más hacia la raíz para IN NSy IN A/ IN AAAARRs. para esa etiqueta y utilícelos para avanzar en el proceso de resolución de nombres. En la práctica, esto es sólo marginalmente diferente y se sigue aplicando el mismo proceso.

Puede simular todo este proceso utilizando la +traceopción de la digutilidad, que viene como parte de BIND, o set debugen formato nslookup.

También vale la pena recordar que algunos tipos de RR (en particular NS, MXy algunos otros; además,A6 se usó razonablemente bien durante un tiempo pero ha quedado obsoleto) pueden hacer referencia a otros RR, y lo hacen. En ese caso, es posible que tengas que generaraún otraproceso de resolución de nombres para dar una respuesta completa y útil a su cliente.

Question 2

Hay un dnstracercomando (es posible que necesite instalarlo, al menos en Debian, ese también es el nombre del paquete) que rastreará la resolución de nombres. También puedes (como señala Koveras en un comentario) usar dig.

Aquí está con dnstracer. -s .significa comenzar con la raíz; -4significa usar IPv4 (v6 está roto aquí...); -osignifica mostrar las direcciones IP resueltas al final (he omitido esa parte del resultado, hay muchas).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

Esa salida continúa, ya que dnstracer rastrea todas las rutas (para que pueda ver si, por ejemplo, algunos de los servidores de nombres tienen una zona desactualizada).

Entonces, puede ver que se necesita una consulta al servidor de nombres raíz, luego una a los servidores gtld (el servidor para la zona .com) y finalmente una a un servidor de nombres de Google.

Con dig, el resultado es mucho más detallado (por lo que recortaré mucho):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

digAdemás, muestra que realizó una consulta para obtener la lista actual de servidores de nombres raíz. Esto es algo que un servidor DNS normalmente hace con muy poca frecuencia. Así que no estoy seguro de si lo cuentas en tu caso de caché inactivo.

Por supuesto, también puede ver las consultas reales en el cable con, por ejemplo, wireshark.

Answer