В разрешении имен DNS как браузеры определяют ближайшие DNS-серверы, доступные среди многих DNS-серверов?
Я знаю, что существует 13 корневых серверов, но как DNS-сервер моего интернет-провайдера узнает, с каким корневым DNS-сервером связаться?
3 ответа
12
Ваш браузер не Ваш браузер будет использовать стандартные системные вызовы для разрешения имен хостов (обычно, я полагаю, getaddrinfo()), и они, в свою очередь, обычно проверяют содержимое /etc/resolv.conf чтобы найти настроенные разрешающие серверы имен, и запрашивают их. Они, в свою очередь, либо перенаправят запрос операционной системы вашего компьютера на вышестоящие серверы (кэшируя любой ответ), либо выполнят рекурсивное разрешение самостоятельно. Обратите внимание, что большинство шагов в приведенной выше цепочке являются настраиваемыми, поэтому то, что на самом деле делает ваш браузер, будет определяться локально; но сценарий выше типичен.
Именно рекурсивно-разрешающие серверы имен в этой цепочке (будь то локально настроенные авторитетные серверы имен или серверы некоторых интернет-провайдеров) должны знать, как найти корневые серверы, и они делают это через предварительно настроенный файл зоны. . (который обычно периодически обновляется путем запроса доступного корневого сервера имен).
Изменить: это не так. Это будет зависеть от реализации, но в моем случае (BIND) просто выбирает один и запрашивает его. Пока он получает ответ вовремя, он возвращается оттуда. Что заставляет вас думать, что происходит какая-либо операция измерения дальности?
10
В разрешении имен DNS как браузеры определяют ближайшие DNS-серверы, доступные среди многих DNS-серверов?
Как показывают другие ответы, ваш браузер или другая клиентская программа не делают этого выбора. Клиентская программа запрашивает разрешение службы имен, вызывая библиотеку, называемую распознавателем.
Решатель определяет, с какими серверами ему следует связаться, чтобы задать запрос. Это зависит от реализации преобразователя, но обычно он просматривает, по порядку, список рекурсивных преобразователей, с которыми он был настроен (либо статической конфигурацией, либо путем получения их через механизм, такой как DHCP).
Итак, ваша программа уровня пользователя запрашивает распознаватель для разрешения имен, а распознаватель запрашивает серверы имен, которые были ему предоставлены через некоторый механизм конфигурации.
Я знаю, что существует 13 корневых серверов, но как DNS-сервер моего интернет-провайдера узнает, с каким корневым DNS-сервером связаться?
Это также зависит от реализации. Я собираюсь описать, как это работает с BIND, так как
- BIND - очень популярный сервер имен, и вполне вероятно, что ваш провайдер использует его, и
- Даже если ваш провайдер не использует BIND, некоторые альтернативы используют аналогичный механизм для выбора сервера имен из набора записей ресурсов NS.
Для начала давайте поговорим сначала о том, как рекурсивный сервер имен даже знает, какие серверы имен выбрать для связи с конкретным доменом. Для каждого домена, доступного с корневого (".") Уровня сервера имен, администраторы, управляющие этим доменом, публикуют в содержащем родительском домене набор записей ресурсов типа записи NS (т.е. сервера имен) для публичного делегирования серверам имен. named в записи ресурса устанавливает ответственность за разрешение запросов, связанных с этим доменом.
Одна из прелестей этой системы заключается в том, что она позволяет распределенное иерархическое делегирование для системы доменных имен, и единственный домен, для которого рекурсивный сервер требует априорных знаний, - это корневой уровень, о котором сервер сконфигурирован, чтобы знать. Раньше было наиболее распространенным указывать NS RRset для корня через файл "подсказок", который BIND загружал при запуске, но на некоторое время IP-адреса, используемые корневыми серверами, были предварительно определены в BIND. [Отступление: вы по-прежнему можете переопределить встроенные модули, указав корневую зону подсказок, и фактически адрес d.root-servers.net недавно изменился, и новое местоположение не будет отражено во встроенном списке до появления нового версии BIND создаются и распространяются с новой информацией. В настоящее время версии, содержащие новый IP-адрес корневых серверов D, находятся в стадии бета-тестирования.]
Как бы то ни было, ключевым моментом здесь является то, что каждый домен имеет связанный с ним набор записей записей NS, содержащий публично объявленные серверы имен для этого домена. Вы должны попробовать взглянуть на несколько самостоятельно. Давайте посмотрим на корень:
$ 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) для серверов имен в наборе RR для выбора того, какой сервер имен должен получать свои запросы. Когда в первый раз набор NS RR для домена добавляется в кэш, всем записям в наборе назначается небольшое случайное время кругового обхода, порядка нескольких миллисекунд. После этого начального заполнения, когда запрос должен быть направлен на серверы имен, делегированные для данного домена, 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.
В следующий раз мы, очевидно, выберем серверу, так как теперь у нее самое низкое время в оба конца. После нескольких запросов к домену example.com у нас должно получиться довольно приличное представление о том, какой сервер имен дает нам самый быстрый ответ, и после этого мы будем предпочитать этот сервер большую часть времени.
Почему большую часть времени, а не все время? И что случилось с битом, о котором я упоминал ранее о том, что "у всех других серверов в RRset их RTT уменьшены на небольшую долю"? Что ж, получается, что, хотя мы хотим отдать предпочтение быстрейшему серверу, мы не хотим постоянно списывать другие серверы. Возможно, сервер c является самым быстрым сервером почти все время, но в то время, когда мы впервые устанавливали его RTT, он был аномально занят. Возможно, сервер временно вышел из строя, что привело к невероятно высокому RTT (после того, как наша попытка запросить его истекло), но мы хотим начать запрашивать его снова после того, как он вернется в эксплуатацию. Изменяя значения других серверов в сторону понижения каждый раз, рано или поздно они будут ползти ниже среднего значения RTT сервера, который мы предпочитаем. Когда это произойдет, мы бросим запрос в их направлении, и если время будет лучше, то отлично .. В противном случае мы сбрасываем его RTT, и он возвращается к нижней части нашего списка приоритетов, пока снова не переместится обратно на фронт. Подавляющее большинство наших запросов будет направлено на самые быстрые серверы или серверы в наборе, но выбросы периодически проверяются, чтобы убедиться, что если условия изменились, таблица обновляется, чтобы отразить это, и лучший сервер все еще выбирается в среднем.
2
13 корневых серверов имен на самом деле не 13 серверов. Каждый из них представляет собой распределенный кластер серверов в разных местах по всему миру, и доступ к ним осуществляется через стандартную IP-маршрутизацию, как и любой другой сервер.
Относительно того, с каким корневым сервером имен выбирает DNS-сервер интернет-провайдера, это, вероятно, зависит от деталей их DNS-распознавателя. Может быть, это совершенно случайно, может быть, это взвешенно, но я не могу вам сказать.
Изменить: если вы имели в виду, как интернет-провайдер находит какой-либо из 13 серверов имен, есть общедоступный список их и соответствующих им IP-адресов, которые в основном есть у каждого компьютера. Оттуда, это просто вопрос выбора одного и позволить маршрутизаторам Интернета сделать все остальное.