Каким образом при разрешении DNS-имен браузеры определяют ближайшие доступные DNS-серверы среди множества DNS-серверов?
Я знаю, что существует 13 корневых серверов, но как DNS-сервер моего интернет-провайдера узнает, к какому корневому DNS-серверу ему обращаться?
решение1
Ваш браузер этого не делает. Ваш браузер будет использовать стандартные системные вызовы для разрешения имен хостов (обычно, как я полагаю, getaddrinfo()), а они, в свою очередь, обычно проверяют содержимое для /etc/resolv.confпоиска настроенных разрешающих серверов имен и запрашивают их. Они, в свою очередь, либо пересылают запрос ОС вашего рабочего стола на серверы верхнего уровня (кэшируя любой ответ), либо выполняют рекурсивное разрешение самостоятельно. Обратите внимание, что большинство шагов в вышеприведенной цепочке настраиваются, поэтому то, что делает ваш браузер, на самом деле будет определяться локально; но приведенный выше сценарий является типичным.
Именно рекурсивно-разрешающим серверам имен в этой цепочке (будь то ваши локально настроенные авторитетные серверы имен или серверы некоторых интернет-провайдеров) необходимо знать, как найти корневые серверы, и они делают это с помощью предварительно настроенного файла зоны .(который обычно периодически обновляется путем запроса доступного корневого сервера имен).
Редактировать: Это не так. Это будет зависеть от реализации, но, на самом деле, в моем случае (BIND) он просто выбирает один и запрашивает его. Пока он получает ответ вовремя, он рекурсирует оттуда. Что заставляет вас думать, что происходит какая-то операция ранжирования?
решение2
Каким образом при разрешении DNS-имен браузеры определяют ближайшие доступные DNS-серверы среди множества DNS-серверов?
Как показывают другие ответы, ваш браузер или другая клиентская программа не делает этот выбор. Клиентская программа запрашивает разрешение службы имен, выполняя вызовы в библиотеку, называемую resolver.
Резолвер определяет, к каким серверам он должен обратиться, чтобы сделать запрос. Это зависит от реализации резолвера, нообычноон просматривает по порядку список рекурсивных резолверов, с которыми он был настроен (либо с помощью статической конфигурации, либо получая их через такой механизм, как DHCP).
Подводя итог: ваша (пользовательская) программа запрашивает у резолвера разрешение имен, а резолвер запрашивает серверы имен, которые были предоставлены ему через некий механизм конфигурации.
Я знаю, что существует 13 корневых серверов, но как DNS-сервер моего интернет-провайдера узнает, к какому корневому DNS-серверу ему обращаться?
Это также зависит от реализации. Я собираюсь описать, как это работает с BIND, поскольку
- BIND — очень популярный сервер имен, и весьма вероятно, что ваш интернет-провайдер его использует.
- Даже если ваш интернет-провайдер не использует BIND, некоторые альтернативы используют аналогичный механизм для выбора сервера имен из набора записей ресурсов NS.
Для начала давайте поговорим о том, как рекурсивный сервер имен вообще знает, какие серверы имен выбрать для связи с определенным доменом. Для каждого домена, который доступен с корневого уровня (".") сервера имен, администраторы, управляющие этим доменом, публикуют в содержащем родительском домене набор записей ресурсов типа NS (т. е. сервер имен), чтобы публично делегировать серверам имен, указанным в наборе записей ресурсов, ответственность за разрешение запросов, связанных с этим доменом.
Одно из преимуществ этой системы в том, что она допускает распределенное иерархическое делегирование для системы доменных имен и единственного домена, для которого требуется рекурсивный сервер.априориknowledge — это корневой уровень, на знание которого настроен сервер. Раньше было наиболее распространено указывать NS RRset для корня через файл «подсказок», который BIND загружал при запуске, но некоторое время назад IP-адреса, используемые корневыми серверами, были предопределены в BIND. [Отступление: вы все еще можете переопределить встроенные параметры, указав зону корневых подсказок, и на самом деле адрес d.root-servers.net недавно изменился, и новое местоположение не будет отражено во встроенном списке, пока не будут созданы и распространены новые версии BIND, включающие новую информацию. В настоящее время версии, содержащие новый IP-адрес корневых серверов D, находятся в стадии бета-тестирования.]
В любом случае, ключевой вывод здесь в том, что каждый домен связан с записью NS RRset, содержащей публично объявленные серверы имен для этого домена. Вы должны попробовать посмотреть на несколько самостоятельно. Давайте посмотрим на корень:
$ dig . ns +edns=0 @f.root-servers.net.
Я просто вырежу раздел ответов, который будет содержать возвращаемый NS RRset в непредсказуемом порядке (здесь я немного умолчу — порядок обычно определяется конфигурацией сервера имен, с которым я общаюсь. Разные корневые элементы могут отвечать в разном порядке, но упорядоченные элементы должны быть одинаковыми).
;; 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.
Это все серверы имен для корневого домена ("."), и мы можем задать любому из них вопросы о корневом домене. Если мы зададим им вопрос о чем-то, что не находится в корневом домене, мы получим либо ошибку, либо, что более вероятно, перенаправление на другой набор серверов имен (например, "example.com? Я не отвечаю на вопросы о example.com.. Попробуйте спросить серверы имен домена .com — они там..")
Как же тогда BIND узнает, какой сервер имен из NS RRset даст ему самый быстрый ответ?
Ответ: изначально нет. Но при своем поведении по умолчанию он со временем учится и останавливается наобычнозапрашивая сервер с наименьшим временем прохождения сигнала туда и обратно.
Время прохождения сигнала туда и обратно и выбор кандидатов на роль сервера имен BIND полагается на время приема-передачи (RTT) к серверам имен в RRset, чтобы выбрать, какой сервер имен должен получать свои запросы. Когда NS RRset для домена добавляется в кэш в первый раз, всем записям в наборе назначается небольшое случайное время приема-передачи, порядка нескольких миллисекунд. После этой начальной подготовки, когда запрос необходимо направить на серверы имен, делегированные для данного домена, BIND проверяет свой кэш и (надеюсь) находит RRset. Он выбирает сервер с наименьшим временем RTT из набора и делает свой запрос. И когда запрос выполнен, BIND обновляет RTT для NS RRset следующим образом:
- RTT сервера, к которому был отправлен запрос, устанавливается равным его фактическому времени приема-передачи.
- У всех остальных серверов в RRset RTT уменьшены на небольшую долю (~3-4%, я думаю...)
Давайте посмотрим, как это работает, на примере. Когда мой рекурсивный резолвер впервые встречает домен example.com, он загружает NS RRset для example.com в свой кэш. Предположим, администраторы example.com объявили три сервера имен для example.com, поэтому NS RRset выглядит так:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Предположим также для примера, что вашему резолверу требуется следующее количество времени для получения ответа от каждого из серверов в этом наборе:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Теперь, когда example.com NS RRset загружается в первый раз, веса RTT заполняются небольшими случайными значениями. Поэтому, прежде чем мы когда-либо что-либо спросим у сервера имен example.com, таблица RTT может выглядеть следующим образом:
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
В первый раз, когда мы запрашиваем example.com, мы собираемся перейти на serverc и задать наш вопрос. Serverc отвечает 50 мс, поэтому после того, как наш запрос выполнен, мы обновляем нашу таблицу RTT, так что теперь она выглядит так:
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.
В следующий раз мы, очевидно, выберем servera, так как у него сейчас самое низкое время круговой передачи. После всего нескольких запросов к домену example.com у нас должно быть довольно приличное представление о том, какой сервер имен дает нам самый быстрый ответ, и мы в дальнейшем предпочтем этот сервербольшинствовремени.
Почемубольшинствовремени и невсевремени? А что случилось с тем, что я упомянул ранее о том, что "Все остальные серверы в RRset имеют свои RTT, уменьшенные на небольшую долю"? Ну, оказывается, что в то время как мы хотимпредпочитатьсамый быстрый сервер, мы не хотим списывать другие серверы навсегда. Возможно, сервер c является самым быстрым сервером почти все время, но в то время, когда мы впервые установили его RTT, он был аномально занят. Возможно, сервер временно не работал, что привело к невероятно высокому RTT (после того, как наша попытка запросить его истечет), но мы хотим начать спрашивать его снова, когда он снова заработает. Регулируя значения других серверов в сторону уменьшения каждый раз, рано или поздно они будут ползти ниже среднего RTT сервера, который мы предпочитаем. Когда это произойдет, мы отправим запрос в их сторону, и если время будет лучше, то отлично. В противном случае мы сбрасываем его RTT, и он возвращается в конец нашего списка приоритетов, пока снова не подберется вперед. Подавляющее большинство наших запросов будет отправлено на самый быстрый сервер или серверы в наборе, но выбросы периодически проверяются, чтобы убедиться, что если условия изменились, таблица обновляется, чтобы отразить это, и лучший сервер по-прежнему выбирается в среднем.
решение3
13 корневых серверов имен на самом деле не являются 13 серверами. Каждый из них представляет собой распределенный кластер серверов в различных местах по всему миру, и доступ к ним осуществляется через стандартную IP-маршрутизацию, как и к любому другому серверу.
Что касаетсякоторыйroot nameserver, к которому DNS-сервер провайдера выбирает обращаться, это, вероятно, зависит от деталей их DNS-резолвера. Может быть, это совершенно случайно, может быть, это взвешено, но я не могу вам сказать.
Редактировать: если вы имели в виду, как работает интернет-провайдернаходитьлюбой из 13 серверов имен, есть их публичный список и соответствующие им IP-адреса, которые есть практически у каждого компьютера. Оттуда остается только выбрать один и позволить маршрутизаторам интернета сделать все остальное.