En la resolución de nombres DNS, ¿cómo determinan los navegadores los servidores DNS más cercanos disponibles entre muchos servidores DNS?
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?
Respuesta1
Tu navegador no. Su navegador utilizará las llamadas al sistema estándar para resolver nombres de host (generalmente, creo, getaddrinfo()) y estos, a su vez, generalmente examinarán el contenido de /etc/resolv.confpara encontrar los servidores de nombres de resolución configurados y los consultarán. A su vez, reenviarán la consulta del sistema operativo de su escritorio a 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 de la cadena anterior son configurables, por lo que lo que realmente haga su navegador estará determinado 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 los servidores de algún 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. for .(que normalmente se actualiza periódicamente consultando un servidor de nombres raíz disponible).
Editar: No es así. Dependerá de la implementación, pero en mi caso (BIND), simplemente elige uno y lo consulta. Siempre que obtenga una respuesta a tiempo, se repetirá desde allí. ¿Qué te hace pensar que se está llevando a cabo algún tipo de operación de alcance?
Respuesta2
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 realizando llamadas a una biblioteca llamada solucionador.
El solucionador determina con qué servidores debe contactar para realizar una consulta. Depende de la implementación del solucionador perogeneralmenteconsulta, en orden, una lista de solucionadores recursivos con los que ha sido configurado (ya sea mediante configuración estática o recibiéndolos a través de un mecanismo como DHCP).
En resumen, entonces: su programa (a nivel de usuario) solicita al solucionador la resolución de nombres y el solucionador solicita 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 muy probable que su ISP lo esté utilizando, y
- Incluso si su ISP no utiliza BIND, algunas alternativas utilizan un mecanismo similar para la selección del servidor de nombres de un conjunto de registros de recursos NS.
Para empezar, hablemos primero de cómo un servidor de nombres recurrente sabe incluso qué servidores de nombres elegir para comunicarse 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 que lo contiene, un conjunto de registros de recursos del tipo de registro NS (es decir, servidor de nombres) para delegar públicamente a los servidores de nombres. nombrado en el registro de recursos establece la responsabilidad de resolver consultas relacionadas con ese dominio.
Una de las ventajas 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 requiere un servidor recursivo.a prioriEl 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 cargaba cuando se iniciaba, pero desde hace un tiempo las direcciones IP utilizadas por los servidores raíz han sido predefinidas 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 se actualice Se crean 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 registro NS que contiene los servidores de nombres anunciados públicamente para ese dominio. Deberías intentar mirar algunos tú mismo. Veamos la raíz:
$ dig . ns +edns=0 @f.root-servers.net.
Voy a simplemente recortar la sección de respuestas, que contendrá el NS RRset devuelto en un orden no predecible (estoy pasando por alto un poco aquí; el orden está determinado generalmente por la configuración del servidor de nombres con el que estoy hablando). . Diferentes raíces pueden responder con diferentes ordenamientos, 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 remisión 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 es así. Pero bajo su comportamiento predeterminado, aprende con el tiempo y se adaptageneralmentepreguntando al servidor con el menor tiempo de ida y vuelta.
Tiempos de ida y vuelta y selección de servidores de nombres candidatos BIND se basa en 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 al 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. Después de esa preparación inicial, cuando es necesario dirigir una consulta a los servidores de nombres delegados para un dominio determinado, 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 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 con un ejemplo. La primera vez que mi solucionador recursivo encuentra el dominio example.com, carga NS RRset for example.com en su caché. Digamos que los administradores de example.com han anunciado tres servidores de nombres para example.com, por lo que 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 solucionador necesita las siguientes cantidades de tiempo para 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 example.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 ejemplo.com, la tabla RTT podría verse así:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
La primera vez que consultemos example.com, iremos a serverc y haremos nuestra pregunta. Serverc tarda 50 ms en responder, por lo que una vez realizada nuestra consulta actualizamos nuestra tabla RTT para que ahora diga:
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 sólo 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.mayoríadel tiempo.
Por quémayoríadel tiempo y notodo¿del tiempo? ¿Y qué pasa con lo que mencioné antes sobre "Todos los demás servidores en el RRset tienen sus RTT reducidos en una pequeña fracción"? Bueno, resulta que si bien queremospreferirel servidor más rápido, no queremos cancelar los otros servidores permanentemente. Quizás el servidor c sea 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 se agotó), pero queremos comenzar a preguntar nuevamente después de que vuelva a estar en servicio. Al ajustar los valores de los otros servidores hacia abajo cada vez, tarde o temprano caerán por debajo del RTT promedio del servidor que preferimos. Cuando eso suceda, enviaremos una consulta en su dirección y si el momento es mejor, entonces genial. De lo contrario, reiniciamos su RTT y vuelve al final de nuestra lista de prioridades hasta que vuelve 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 garantizar que, si las condiciones han cambiado, la tabla se actualice para reflejar eso y se siga seleccionando el mejor servidor en promedio.
Respuesta3
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 enrutamiento IP estándar, como cualquier otro servidor.
Como paracualservidor de nombres raíz con el que el servidor DNS del ISP elige contactar, eso probablemente depende de los detalles de su solucionador de DNS. Tal vez sea completamente aleatorio, tal vez esté ponderado, pero no podría decírtelo.
Editar: si quisiste decir, ¿cómo funciona el ISP?encontrarcualquiera de los 13 servidores de nombres, hay una lista pública de ellos y sus correspondientes direcciones IP que básicamente todas las computadoras tienen. A partir de ahí, sólo es cuestión de elegir uno y dejar que los enrutadores de Internet hagan el resto.