En este momento estoy tomando un curso en línea para Linux sysadmin y me hicieron una pregunta que generalmente no entiendo. Sé cómo buscar un servidor de nombres, si estoy en lo correcto, al menos está usando el comando cavar para encontrar la dirección en el comando de la sección adicional, pero me perdí un poco cuando me hicieron la siguiente pregunta.
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.
No quiero la respuesta, solo me gustaría saber qué se me pide que haga exactamente.
dig +trace, pero no estoy seguro de qué se entiende por niveles. Esta podría ser una pregunta para Server Fault.Respuestas:
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 laroot-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 enmaps.google.com.lugar de hacerlomaps.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. ContieneNSregistros 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 lacom.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 uncomdominio tenga servidores de nombres solonl, 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 (NXDOMAINoNOERRORcon registros de datos de respuesta cero). Siga buscando respuestas comoSERVFAIL(y retroceda un paso e intente con otro servidor si obtiene uno; si todos los servidores con nombre regresanSERVFAIL, falle el proceso de resolución de nombres y regreseSERVFAILal 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 NSyIN 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 ladigutilidad, que viene como parte de BIND, oset debugennslookup.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.fuente
digpara el nombre ns1.google.com una vez que haya recibido una referencia que no incluya una dirección IP en los registros de pegamento proporcionados. Luego continuaría con el proceso de resolución de nombres anterior.Hay un
dnstracercomando (es posible que deba instalarlo, al menos en Debian, ese también es el nombre del paquete) que rastreará la resolución del nombre. También puede (como señala Koveras en un comentario) usardig.Aquí está con dnstracer.
-s .significa comenzar con la raíz;-4significa usar IPv4 (v6 está roto aquí ...);-osignifica mostrar realmente las direcciones IP resueltas al final (he omitido esa parte de la salida, hay muchas).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 lleva 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, la salida es mucho más detallada (así que haré muchos cortes):digademás muestra que hizo una consulta para obtener la lista actual de servidores de nombres raíz. Esto es algo que un servidor DNS suele hacer con muy poca frecuencia. Así que no estoy seguro si lo cuenta en su caja de caché en frío.Por supuesto, puede también observar las consultas reales sobre el alambre con, por ejemplo,
wireshark.fuente
digsi no tienednstracer(o si le gustadigel formato). Las direcciones IP que genera dnstracer son las direcciones IP de los servidores de nombres; Sus nombres están a la izquierda. a.root-servers.net es 198.41.0.4, etc. Esos son los servidores que se consultan, y le indica para qué zona también entre corchetes. Sospecho que el primer nivel es * .root-servers.net (para.), en segundo lugar es * .gtld-servers.net (para.com), etc.