Как мой браузер находит ближайшие корневые DNS-серверы?

в разрешении DNS-имен как браузеры определяют ближайшие DNS-серверы, доступные среди многих DNS-серверов?

как показывают другие ответы, Ваш браузер или другая клиентская программа не делает этот выбор. Клиентская программа запрашивает разрешение Службы имен, вызывая библиотеку, называемую распознавателем.

распознаватель определяет, с какими серверами он должен связаться, чтобы задать запрос. Это зависит от реализации решателя но обычно он советует, для того, список рекурсивных серверах, он был настроен с (либо статический, либо получив их посредством такого механизма, как DHCP.)

таким образом: ваша программа (на уровне пользователя) запрашивает у распознавателя разрешение имен, а распознаватель запрашивает серверы имен, которые были предоставлены ему через некоторый механизм конфигурации.

Я знаю, что есть 13 корневых серверов, но как DNS моего провайдера сервер знаете, к какому корневому DNS-серверу обратиться?

это также зависит от реализации. Я собираюсь описать, как это работает с BIND, так как

1. BIND является очень популярным сервером имен и шансы довольно хорошо, что ваш провайдер использует его, и
2. даже если ваш провайдер не использует BIND, некоторые альтернативы используют аналогичный механизм для выбора сервера имен из набора записей ресурсов NS.

для начала, давайте сначала поговорим о том, как рекурсивный сервер имен даже знает, какие серверы имен выбрать, чтобы поговорить с определенным доменом. Для каждого домена, доступного из корня (".") уровень сервера имен, администраторы, управляющие этим доменом, публикуют в содержащем его родительском домене набор записей ресурсов типа NS (т. е. сервер имен), чтобы публично делегировать серверам имен, указанным в записи ресурса, ответственность за разрешение запросов, связанных с этим доменом.

один из прелесть этой системы в том, что она позволяет распределенное иерархическое делегирование для системы доменных имен и единственный домен, для которого рекурсивный сервер требует a priori knowledge-корневой уровень, о котором настроен сервер. Раньше было наиболее распространено указывать RRset NS для корня через файл "hints", который привязывает загруженный, когда это началось, но некоторое время теперь 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.

это все серверы имен для root (".") домен и мы можем задать любые вопросы о корневом домене. Если мы зададим им вопрос о чем-то, что не находится в корневом домене, мы получим либо ошибку, либо, скорее всего, ссылку на другой набор серверов имен (например, "example.com? Я не отвечаю на вопросы о example.com.. попробуйте спросить самого .серверы имен домена com-они там..")

как тогда BIND знает какой сервер имен из набора NS rrset даст ему самый быстрый ответ?

ответ: изначально это не так. Но при своем поведении по умолчанию, он учится со временем и оседает на обычно спрашивать сервер с самым коротким временем туда и обратно.

времени цикла и отбор кандидата-серверы BIND полагается на время кругового пути (RTTs) к серверам имен в RRset, чтобы выбрать, какой сервер имен должен получить его запросит. При первом добавлении NS RRset для домена в кэш всем записям в наборе назначается небольшое случайное время кругового пути (порядка нескольких миллисекунд). После этого начального заполнения, когда запрос должен быть направлен на серверы имен, делегированные для данного домена, BIND проверяет свой кэш и (надеюсь) находит RRset. Он выбирает сервер с наименьшим временем RTT из набора и делает свой запрос. И когда запрос сделан, BIND обновляет RTTs для NS RRset следующим образом:

1. RTT сервера, который только что был запрошен, установлен в фактическое время кругового пути.
2. все остальные серверы в 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 сервер ничего, таблица РТТ может выглядеть это:

servera  --  8 ms
serverb  --  9 ms
serverc  --  7 ms

при первом запросе example.com затем мы отправимся на сервер и зададим наш вопрос. 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 домен мы должны иметь довольно приличную идею, которая nameserver дает нам самый быстрый ответ и мы будем после этого предпочитают этот сервер большинство времени.

почему большинство того времени и не все времени? И что с битом, который я упомянул ранее о "всех других серверах в RRset, их RTTs уменьшены на небольшую долю"? Ну, получается, что пока мы хотим предпочитаю самый быстрый сервер, мы не хотим списывать на других серверах постоянно. Возможно, сервер c самый быстрый сервер почти все время, но в то время мы впервые установили его RTT он был аномально занят. Возможно, сервер временно не работал, что привело к невероятно высокому RTT (после нашей попытки запросить его тайм-аут), но мы хотим начать спрашивать его снова после того, как он вернется в эксплуатацию. Регулируя другие значения сервера вниз каждый раз, рано или поздно они будут ползти ниже, чем средний RTT сервера, который мы предпочитаем. Когда это произойдет, мы бросим запрос в их направление и если время лучше, то отлично.. В противном случае, мы сбрасываем его RTT, и он возвращается к нижней части нашего списка приоритетов, пока он не ползет обратно на фронт снова. Подавляющее большинство наших запросов будет отправлено на самый быстрый сервер или серверы в наборе, но выбросы периодически проверяются, чтобы убедиться, что если условия изменились, таблица обновляется, чтобы отразить это, и лучший сервер все еще выбирается в среднем.