Tu navegador no. Su navegador utilizará las llamadas estándar del sistema para resolver nombres de host (por lo general, creo, getaddrinfo() ), y estos a su vez generalmente examinarán el contenido de /etc/resolv.conf para encontrar los servidores de nombres de resolución configurados y consultarlos. A su vez, reenviarán la consulta del sistema operativo de su escritorio a los servidores ascendentes (almacenando en caché cualquier respuesta) o realizarán una resolución recursiva ellos mismos. Tenga en cuenta que la mayoría de los pasos en la cadena anterior son configurables, por lo que lo que su navegador haga en realidad se determinará localmente; pero el escenario anterior es típico.
Son los servidores de nombres de resolución recursiva en esa cadena (ya sean sus servidores de nombres autorizados configurados localmente o algunos servidores de ISP en el futuro) los que necesitan saber cómo encontrar los servidores raíz, y lo hacen a través de un archivo de zona preconfigurado. para . (que generalmente se actualiza periódicamente consultando un servidor de nombres raíz disponible).
Editar :No lo hace. Dependerá de la implementación, pero en mi caso (BIND), simplemente elige uno y lo consulta. Siempre que obtenga una respuesta a tiempo, recurre hacia abajo desde allí. ¿Qué te hace pensar que se está llevando a cabo algún tipo de operación de alcance?
En la resolución de nombres DNS, ¿cómo determinan los navegadores los servidores DNS más cercanos disponibles entre muchos servidores DNS?
Como indican las otras respuestas, su navegador u otro programa cliente no realiza esta selección. Un programa cliente solicita la resolución del servicio de nombres haciendo llamadas a una biblioteca llamada resolver.
El resolutor determina a qué servidores debe contactar para hacer una consulta. Depende de la implementación del resolutor, pero normalmente consulta, en orden, una lista de resolutores recursivos con los que ha sido configurado (ya sea por configuración estática o al recibirlos a través de un mecanismo como DHCP).
Entonces, en resumen:su programa (a nivel de usuario) le pide al resolutor la resolución de nombres y el resolutor pregunta a los servidores de nombres que se le han proporcionado a través de algún mecanismo de configuración.
Soy consciente de que hay 13 servidores raíz, pero ¿cómo sabe el servidor DNS de mi ISP con qué servidor DNS raíz contactar?
Esto también depende de la implementación. Voy a describir cómo funciona con BIND, ya que
- BIND es un servidor de nombres muy popular y es bastante probable que su ISP lo esté utilizando, y
- Incluso si su ISP no usa BIND, algunas alternativas usan un mecanismo similar para la selección del servidor de nombres desde un conjunto de registros de recursos NS.
Para empezar, hablemos primero sobre cómo un servidor de nombres recurrente incluso sabe qué servidores de nombres elegir para hablar con un dominio específico. Para cada dominio al que se puede acceder desde el nivel raíz (".") del servidor de nombres, los administradores que administran ese dominio publican, en el dominio principal contenedor, un conjunto de registros de recursos de tipo de registro NS (es decir, servidor de nombres) para delegar públicamente a los servidores de nombres. nombrado en el registro de recursos establezca la responsabilidad de resolver las consultas que tengan que ver con ese dominio.
Una de las bellezas de este sistema es que permite la delegación jerárquica distribuida para el sistema de nombres de dominio y el único dominio para el que se requiere un servidor recursivo a priori conocimiento es el nivel raíz, que el servidor está configurado para conocer. Solía ser más común especificar el NS RRset para la raíz a través de un archivo de "sugerencias" que BIND cargó cuando comenzó, pero desde hace un tiempo, las direcciones IP utilizadas por los servidores raíz se han predefinido en BIND. [Digresión:aún puede anular las funciones integradas especificando una zona de sugerencia raíz y, de hecho, la dirección de d.root-servers.net cambió recientemente y la nueva ubicación no se reflejará en la lista integrada hasta que sea nueva se construyen y distribuyen versiones de BIND que incluyen la nueva información. Actualmente, las versiones que contienen la nueva dirección IP de los servidores raíz D están en versión beta.]
De todos modos, la conclusión clave aquí es que cada dominio tiene asociado un RRset de registros NS que contiene los servidores de nombres anunciados públicamente para ese dominio. Deberías intentar mirar algunos tú mismo. Miremos la raíz:
$ dig . ns +edns=0 @f.root-servers.net.
Voy a recortar la sección de respuesta, que contendrá el NS RRset devuelto en un orden no predecible (estoy pasando por alto un poco aquí, el orden generalmente está determinado por la configuración del servidor de nombres con el que estoy hablando) Diferentes raíces pueden responder con diferentes pedidos, pero los elementos que se ordenan deben ser los mismos.)
;; ANSWER SECTION:
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
Esos son todos los servidores de nombres para el dominio raíz (".") y podemos hacerles preguntas a cualquiera de ellos sobre el dominio raíz. Si les hacemos una pregunta sobre algo que no está en el dominio raíz, recibiremos un error o, más probablemente, una referencia a otro conjunto de servidores de nombres (por ejemplo, "ejemplo.com? No respondo preguntas sobre ejemplo.com. . Intente preguntar a los servidores de nombres de dominio .com -- están allí...")
Entonces, ¿cómo sabe BIND qué servidor de nombres del NS RRset le dará la respuesta más rápida?
La respuesta es:inicialmente no lo hace. Pero bajo su comportamiento predeterminado, aprende con el tiempo y se establece en generalmente preguntando al servidor con el tiempo de ida y vuelta más corto.
Tiempos de ida y vuelta y selección de servidores de nombres candidatos BIND se basa en los tiempos de ida y vuelta (RTT) a los servidores de nombres en un RRset para elegir qué servidor de nombres debe recibir sus consultas. La primera vez que se agrega a la memoria caché un NS RRset para un dominio, a todos los registros del conjunto se les asigna un pequeño tiempo de ida y vuelta aleatorio, del orden de unos pocos milisegundos. ser dirigido a los servidores de nombres delegados para un dominio dado, BIND verifica su caché y (con suerte) encuentra el RRset. Elige el servidor con el tiempo RTT más bajo del conjunto y realiza su consulta. Y cuando finaliza la consulta, BIND actualiza los RTT para el NS RRset de la siguiente manera:
- el RTT del servidor que se acaba de consultar se establece en su tiempo de ida y vuelta real.
- Todos los demás servidores en el RRset tienen sus RTT reducidos en una pequeña fracción (~3-4%, creo...)
Veamos cómo funciona esto recorriendo un ejemplo. La primera vez que mi solucionador recursivo encuentra el dominio ejemplo.com, carga el NS RRset para ejemplo.com en su caché. Digamos que los administradores de example.com han anunciado tres servidores de nombres para example.com, por lo que el NS RRset se ve así:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Supongamos también, por el bien de este ejemplo, que su resolutor tarda las siguientes cantidades de tiempo en recibir una respuesta de cada uno de los servidores de este conjunto:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Ahora, la primera vez que se carga el NS RRset de ejemplo.com, los pesos RTT se preparan con pequeños valores aleatorios. Entonces, antes de que le hayamos preguntado algo a un servidor de nombres de example.com, la tabla RTT podría verse así:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
La primera vez que consultamos example.com, iremos a serverc y haremos nuestra pregunta. Serverc tarda 50 ms en responder, por lo que una vez finalizada nuestra consulta, actualizamos nuestra tabla RTT para que ahora lea:
servera -- 7 ms // reduced by a small fraction
serverb -- 8 ms // reduced by a small fraction
serverc -- 50 ms // updated to reflect the actual round trip time.
La próxima vez obviamente elegiremos servera, ya que ahora tiene el tiempo de ida y vuelta más bajo. Después de solo unas pocas consultas al dominio example.com, deberíamos tener una idea bastante decente de qué servidor de nombres nos da la respuesta más rápida y, a partir de entonces, preferiremos ese servidor más. de la época.
Por qué la mayoría del tiempo y no todo ¿del tiempo? ¿Y qué pasa con el bit que mencioné anteriormente sobre "Todos los demás servidores en el RRset tienen sus RTT reducidos en una pequeña fracción"? Bueno, resulta que mientras queremos preferir el servidor más rápido, no queremos cancelar los otros servidores de forma permanente. Tal vez el servidor c es el servidor más rápido casi todo el tiempo, pero en el momento en que configuramos su RTT por primera vez, estaba anormalmente ocupado. Tal vez un servidor estuvo temporalmente fuera de servicio, lo que resultó en un RTT increíblemente alto (después de que nuestro intento de consultarlo agotó el tiempo de espera), pero queremos comenzar a preguntarlo nuevamente después de que vuelva a estar en servicio. Al ajustar los valores de los otros servidores a la baja cada vez, tarde o temprano se reducirán más que el RTT promedio del servidor que preferimos. Cuando eso suceda, lanzaremos una consulta en su dirección y si el tiempo es mejor, entonces genial. De lo contrario, restableceremos su RTT y volverá al final de nuestra lista de prioridades hasta que regrese al frente nuevamente. La gran mayoría de nuestras consultas se dirigirán al servidor o servidores más rápidos del conjunto, pero los valores atípicos se prueban periódicamente para asegurarse de que, si las condiciones han cambiado, la tabla se actualice para reflejar eso y el mejor servidor todavía se seleccione en promedio.
Los 13 servidores de nombres raíz no son en realidad 13 servidores. Cada uno es un grupo distribuido de servidores en varios sitios alrededor del mundo, y se accede a ellos a través de un enrutamiento IP estándar, como cualquier otro servidor.
En cuanto a cuál El servidor de nombres raíz que el servidor DNS del ISP elige contactar, eso probablemente depende de los detalles de su resolución de DNS. Tal vez sea completamente aleatorio, tal vez esté ponderado, pero no podría decírtelo.
Editar:si se refería a, ¿cómo encuentra el ISP cualquiera de los 13 servidores de nombres, hay una lista pública de ellos y sus correspondientes direcciones IP que básicamente tiene cada computadora. A partir de ahí, solo es cuestión de elegir uno y dejar que los enrutadores de Internet hagan el resto.