Suponiendo que su servidor de nombres configurado no tiene ningún resultado 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? Liste uno de cada nivel y explique por qué se necesita este nivel.
Bueno, escojamos este aparte.
"Asumiendo que su servidor de nombres configurado no tiene ningún resultado en caché a su disposición" - En primer lugar, si se ha ningún caché de datos en absoluto, entonces no puede resolver nada. Para cebar la memoria caché del resolutor, debe tener los registros NS y de dirección (A, AAAA) para la zona .(raíz de AKA). 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 DNS, precisamente para cebar el caché del resolutor. Los servidores de nombres con autorización exclusiva no necesitan estos datos, pero los servidores de nombres resueltos sí.
Además, "resolver" a 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 suponer 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 trabaja de derecha a izquierda. No te olvides de .al final; realmente estarías resolviendo en maps.google.com.lugar de hacerlo 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 hará):
.com.google.com.maps.google.com.
Comience por averiguar dónde pedir el contenido .. Eso es fácil; ya tenemos esa información: los nombres del servidor de nombres raíz y las direcciones IP . Entonces tenemos un servidor de nombres raíz. Digamos que decidimos usar 198.41.0.4 ( a.root-servers.nettambié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á usar los datos del servidor raíz proporcionados para pedirle a uno de los servidores de la zona raíz una lista precisa de los servidores de nombres para la zona raíz, asegurando así que si alguno de los nombres y las direcciones IP son válidos y accesibles, tendrá un conjunto completo y completo de datos para la zona raíz cuando comience la resolución.
Dispara 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 podría saber"; Eso es una referencia. Contiene NSregistros de la zona más cercana que el servidor en cuestión conoce, junto con cualquier registro de pegamento que el servidor tenga disponible. Si no hay datos de pegamento disponibles, primero debe resolver ese host nombrado en el registro NS que seleccionó, de modo 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, haciendo com.la misma pregunta a uno de los servidores de nombres. Ellos tampoco lo saben, pero lo remitirá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 nl, por ejemplo, en cuyo caso es poco probable que los datos de pegamento estén disponibles en los servidores de gTLD. Los datos de pegamento proporcionados también pueden estar incompletos, o si realmente tienes mala suerte, ¡incluso podrían ser incorrectos! Usted tiene que siempre estar preparado para desovar fuera de que la resolución de nombres separada que he mencionado anteriormente.
Básicamente, continúa hasta obtener una respuesta con el aaconjunto de indicadores (respuesta autorizada). Esa respuesta le dirá lo que está pidiendo, o que el RR que solicitó no existe ( NXDOMAINo NOERRORcon registros de datos de respuesta cero). Siga buscando respuestas como SERVFAIL(y retroceda un paso e intente con otro servidor si obtiene uno; si todos los servidores con nombre regresan SERVFAIL, falle el proceso de resolución de nombres y regrese SERVFAILal cliente).
La alternativa a solicitar el nombre completo de RR de cada servidor (que podría considerarse una mala práctica) es utilizar la lista dividida de etiquetas que determinamos anteriormente, preguntar a los servidores de nombres dados por el servidor más hacia la raíz IN NSy IN A/ IN AAAARR para esa etiqueta y úselas para avanzar en el proceso de resolución de nombres. Eso es solo marginalmente diferente en la práctica, y el mismo proceso todavía se aplica.
Puede simular todo este proceso utilizando la +traceopción de la digutilidad, que viene como parte de BIND, o set debugen nslookup.
También vale la pena recordar que algunos tipos de RR (en particular NS, MXy algunos otros; también, A6se usó razonablemente bien durante un tiempo pero ha quedado en desuso) pueden y hacen referencia a otros RR. En ese caso, es posible que necesite generar otro proceso de resolución de nombres para dar una respuesta completa y útil a su cliente.
dig +trace, pero no estoy seguro de qué se entiende por niveles. Esta podría ser una pregunta para Server Fault.