К сожалению, ответ здесь - «это зависит от обстоятельств». Факторы, от которых это зависит, будут зависеть от домена и того, как настроены серверы-владельцы, а также от того, как настроен ваш собственный локальный DNS.
Во-первых, например, в отношении возвращаемых записей NS: вполне разрешено рандомизировать порядок, в котором эти записи возвращаются, поэтому порядок может отличаться при каждом запросе. С другой стороны, это делается не всеми реализациями DNS, поэтому вы вполне можете получить статически упорядоченный список. Дело в том, что вы не можете быть уверены.
Затем некоторые реализации DNS будут запрашивать каждый NS параллельно и использовать тот, который ответит первым. Другие будут попадать в каждый, определять самый быстрый из некоторого количества запросов и использовать его. Или это может быть просто круговой алгоритм.
Существует несколько RFC для DNS, из которых я нашел два наиболее полезных:
http://www.faqs.org/rfcs/rfc1912.html
http://www.faqs.org/rfcs/rfc1033.html
Я понимаю, что это что-то вроде отсутствия ответа, без каких-либо окончательных ответов, но, учитывая вышесказанное, единственный верный способ определить поведение для данного домена - это проверить.
Наиболее распространенная реализация, которую я видел на уровне клиента, например у интернет-провайдеров по всему миру, выглядит следующим образом:
- Кто-то (например, абонент широкополосного доступа) просит DNS-серверы интернет-провайдера разрешить запись A для foo.example.com.
- Интернет-провайдер проверяет свой собственный кеш, и если эта запись кэшируется и все еще считается «свежей», она немедленно возвращается через кеш. (Так работают все кэши DNS, чтобы они не перегружали DNS-серверы соответствующего сайта.)
- Если у них не было этой записи в кеше или если кеш считается «устаревшим / устаревшим», интернет-провайдер знает, что ему необходимо снова разрешить последнюю запись.
- Теперь провайдеру нужно знать, какие серверы имен запрашивать о последней записи.
- Интернет-провайдер начинает с проверки кэшированного списка авторитетных серверов имен для домена (это ns1.example.com, ns2.example.com и т. Д., А также их IP-адреса). Если эти записи все еще считаются свежими, переход к шагу 8.
- Если кешированные записи сервера имен считались просроченными или у них не было кэшированных записей для этого домена, интернет-провайдер запрашивает корневые серверы имен TLD (например, реестр .com, если это домен .com), чтобы получить самые свежие пары имя / IP-адрес сервера имен для example.com. (Вы можете попробовать это самостоятельно через «dig @ b.gtld-servers.net example.com», чтобы узнать, что корневые серверы имен для вашего TLD знают о вашем домене - если ваш домен принадлежит к обычным TLD com / net / etc. Другие TLD должны будут запросить соответствующие корневые серверы.)
- Корневые серверы имен для TLD всегда вернуть серверы имен в точный порядок они были указаны вами; никакой рандомизации не происходит. Они также возвращают IP-адреса для каждого сервера имен; это известно как «КЛЕЙ», и это то, что позволяет Интернету решить проблему «курицы и яйца» о том, как преобразовать имя хоста сервера имен в IP-адрес до того, как что-либо узнает о домене. Более того, большинство из них (например, крупнейшие реестры com / net / etc) используют время кеширования в 2 дня, чтобы их не забивали постоянно вопросом «каков список серверов имен для домена X?» Запросы. Это источник общеизвестной информации о том, что вы ДОЛЖНЫ подождать 2 дня, пока вы не сможете с уверенностью сказать, что ваши новые серверы имен известны во всем мире, после того, как вы отредактировали список серверов имен.
- Когда интернет-провайдер знает серверы имен example.com и их IP-адреса, такие как ns1.example.com, ns2.example.com, ns3.example.com, он теперь выбирает случайный сервер из этого списка и отправляет запрос. (Это хорошо с их стороны, они не бесполезно забивают все DNS-серверы рассматриваемого сайта и дополнительно помогают с балансировкой нагрузки, не всегда запрашивая первый указанный сервер имен.)
- Если интернет-провайдер не получает ответа от этого сервера имен в течение указанного периода ожидания, он запрашивает другой сервер в списке.
- Получив ответ, провайдер теперь сохраняет его в своем локальном кэше. Что касается того, как долго он будет оставаться в кеше; каждая запись, возвращаемая любым DNS-сервером, также имеет связанное с ней время «мягкого истечения» (в секундах), то есть как долго запрашивающий клиент (например, DNS-сервер интернет-провайдера) может кэшировать эту запись, прежде чем она будет рассмотрена » все еще можно использовать, но, возможно, он устарел, теперь должен выполняться новый запрос, ЕСЛИ ВОЗМОЖНО, просто чтобы убедиться, что он не изменился. " Также существует время "окончательного истечения", которое указывается в записи "SOA" (начало полномочий) каждого отдельного сервера имен (вы можете увидеть свой через "dig @ ns1.example.com example.com -t soa"), который задает глобальный «жесткий предел» для всех записей, возвращаемых этим сервером, после чего любой кеш ДОЛЖЕН УДАЛИТЬ свою кэшированную запись ДАЖЕ, ЕСЛИ серверы имен не работают и невозможно снова найти записи. Обычно мягкий срок годности составляет от 30 минут до 5 часов, а жесткий срок годности составляет 1-3 недели.
- После этой кропотливой работы у интернет-провайдера наконец-то есть последняя запись DNS, и он может вернуть ее запрашивающему широкополосному абоненту, который не понимает, какая огромная работа была проделана за кулисами!
Этот процесс повторяется для КАЖДОГО поиска записи. Однако только первый запрос выполняет всю работу; IP-адреса серверов имен будут кэшированы после этого, и последующие запросы к кэширующему DNS-серверу интернет-провайдера смогут быстро перейти к шагу 8.
Теперь, что касается рандомизации шага 8, он работает на рекордном уровне. Допустим, абонент широкополосного доступа этого интернет-провайдера спросил о следующих записях:
- Foo.example.com
- Example.com
- Www.example.com
- MX example.com (клиент ISP не должен запрашивать эту запись, это просто пример)
Каждая запись будет обрабатываться как отдельный "объект", независимо кэшируемый и просматриваемый. Итак, предположим, что подписчик и интернет-провайдер никогда раньше не сталкивались с доменом, и у обоих полностью отсутствуют кэшированные записи. Поиск может быть следующим:
- Foo.example.com через ns1.example.com, затем сохраняется в кеше интернет-провайдера.
- Example.com через ns3.example.com, затем сохраняется в кеше интернет-провайдера.
- Www.example.com через ns2.example.com, затем сохраняется в кеше интернет-провайдера.
- MX example.com через ns3.example.com, затем сохраняется в кеше интернет-провайдера.
Всякий раз, когда срок действия кэшированных записей истекает, процесс повторяется, поэтому вы даже не знаете, что последующие запросы для этой записи снова будут использовать тот же сервер.
Поэтому ваша самая главная цель - убедиться, что все ваших DNS-серверов полностью синхронизированы друг с другом, идеально зеркалируя каждый Запись DNS на каждом сервере. Вы никогда знать, к какому серверу будет обращаться DNS-клиент, и вы не можете полагаться ни на какой порядок. Нет такого.
Кроме того, как упоминал Адам C, серверы DNS уровня сервера (example.com) сами могут возвращать записи NS и рандомизировать их порядок. Обычные DNS-серверы очень часто рандомизируют свои NS-записи с небольшой вероятностью, что плохая реализация DNS всегда выбирает первый возвращенный namserver. Однако серверы имен ROOT TLD (упомянутые ранее) никогда не будут рандомизировать список, и их список - это то, что действительно важно, когда дело доходит до разрешения домена. Поэтому большинство реализации выбирают случайный сервер из списков серверов имен, чтобы всегда не попадать на один и тот же сервер и не перегружать его.
Хорошо, это ваше руководство по работе DNS и о том, что вам следует помнить.
- Вкратце: относитесь ко всем своим DNS-серверам так, как если бы они были одним сервером, и сделайте своей высшей целью в жизни убедиться, что все они одинаково способны отвечать. любой запрос, который может быть им брошен.
Отказ от ответственности: более высокие цели в жизни, чем управление DNS, могут быть доступны, но продаются отдельно, используйте свое воображение. ;-)