Как определяется порядок поиска DNS?

Например: мы зарегистрировали доменное имя domain.com и добавили записи сервера имен на сервере регистраторов:
ns1.domain.com.
ns2.domain.com.
ns3.domain.com.

Чем мы смотрим на domain.com . Мы получаем все 3 адреса серверов имен.
1. Какой из этих серверов будет запрошен в дальнейшем и почему?
2. Имеет ли значение порядок записей NS в файле зоны?
3. Определяется ли это в каком-либо RFC ?

К сожалению, ответ здесь "это зависит". Факторы, от которых это зависит, будут зависеть от домена и от того, как настроены серверы-владельцы, а также от того, как настроен ваш собственный локальный DNS.

Во-первых, например, в отношении возвращаемых записей NS: совершенно возможно рандомизировать порядок, в котором эти записи возвращаются, поэтому порядок может отличаться при каждом запросе. С другой стороны, это делается не всеми реализациями DNS, поэтому вы вполне можете получить статически упорядоченный список. Дело в том, что вы не можете быть уверены.

Затем, некоторые реализации DNS будут запрашивать каждый NS параллельно и использовать тот, который ответит первым. Другие поразят каждый, определят самый быстрый за некоторое количество запросов и используют тот. Или это может быть просто круговой.

Есть несколько RFC для DNS, два из наиболее полезных, которые я нашел:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Я понимаю, что это что-то вроде отсутствия ответа, без какой-либо определенной цели, которую вы можете отнять, но, учитывая вышесказанное, единственный верный способ определить поведение для данного домена - это проверить.

Наиболее распространенная реализация, которую я видел на уровне клиентов, таких как интернет-провайдеры по всему миру, выглядит следующим образом:

1. Кто-то (например, широкополосный абонент) просит DNS-серверы интернет-провайдера разрешить запись A для foo.example.com.
2. Интернет-провайдер проверяет свой собственный кэш, и если эта запись кэшируется и все еще считается «свежей», она немедленно возвращается через кэш. ( Так работают все кеши DNS, чтобы они не напрасно напрягали DNS-серверы рассматриваемого сайта. )
3. Если у них не было этой записи в кеше, или если кеш считается устаревшим / устаревшим, интернет-провайдер знает, что ему нужно снова разрешить последнюю запись.
4. Теперь провайдеру нужно знать, какие серверы имен запрашивать о последней записи.
5. Интернет-провайдер начинает с проверки своего кэшированного списка надежных серверов имен для домена (это ns1.example.com, ns2.example.com и т. Д. Вместе с их IP-адресами). Если эти записи все еще считаются свежими, процесс переходит к шагу 8.
6. Если кешированные записи сервера имен были сочтены просроченными, или если у него не было кешированных записей для этого домена, провайдер запрашивает корневые серверы имен TLD (например, реестр .com, если это домен .com), чтобы получить большинство современных пар имя / IP-адрес сервера имен для example.com. ( Вы можете попробовать это самостоятельно через "dig @ b.gtld-servers.net example.com", чтобы узнать, что корневые серверы имен вашего TLD знают о вашем домене - если ваш домен принадлежит обычным TLD com / net / etc. Другое ДВУ должны будут запросить свои соответствующие корневые серверы. )
7. Корневые серверы имен для TLD всегда возвращают серверы имен в том порядке, в котором они были указаны вами; рандомизация не происходит. Они также возвращают IP-адреса для каждого сервера имен; это называется «КЛЕЙ» и позволяет Интернету решить проблему «курицы и яйца», заключающуюся в том, как преобразовать имя хоста сервера имен в IP, прежде чем что-либо узнавать о домене. Более того, большинство из них (например, реестры com / net / etc, которые являются самыми крупными) используют время кэширования в 2 дня, чтобы они не сталкивались постоянно с «что такое список серверов имен для домена X?» Запросы. Это источник общего знания, что вы ДОЛЖНЫ подождать 2 дня, пока вы не сможете смело сказать, что ваши новые серверы имен известны во всем мире после того, как вы
8. Когда провайдеру известны серверы имен example.com и их IP-адреса, такие как ns1.example.com, ns2.example.com, ns3.example.com, провайдер теперь выбирает случайный сервер из этого списка и отправляет запрос. ( Это мило с их стороны, они не бесполезно забивают все DNS-серверы рассматриваемого сайта, и они помогают дополнительно с балансировкой нагрузки, не всегда запрашивая первый перечисленный сервер имен. )
9. Если провайдер не получает ответ от этого сервера имен в течение указанного периода времени, он запрашивает еще один в списке.
10. Когда у него есть ответ, интернет-провайдер теперь сохраняет его в своем локальном кэше. Как долго он будет храниться в кэше; каждая запись, возвращаемая любым DNS-сервером, также имеет время «мягкого истечения» (в секундах), связанное с ним, то есть сколько времени запрашивающему клиенту (например, DNS-серверу интернет-провайдера) разрешено кэшировать эту запись, прежде чем она будет рассмотрена » все еще пригодный для использования, но, возможно, устаревший, новый запрос должен теперь выполняться, ЕСЛИ ВОЗМОЖНО, просто чтобы убедиться, что он не изменился ». Существует также время «жесткого истечения», которое указывается в записи «SOA» («Начало полномочий») каждого отдельного сервера имен (вы можете увидеть свой через «dig @ ns1.example.com example.com -t soa»), которое задает глобальное «жесткое ограничение» для всех записей, возвращаемых этим сервером, после чего любой кеш ДОЛЖЕН УДАЛИТЬ свою кэшированную запись, ДАЖЕ ЕСЛИ серверы имен не работают, и невозможно снова просмотреть записи. Обычно срок мягкого истечения составляет от 30 минут до 5 часов, а срок истечения обычно составляет 1-3 недели.
11. После этой исчерпывающей работы интернет-провайдер, наконец, получил последнюю запись DNS и может вернуть ее запрашивающему широкополосному абоненту, который не знает, какая огромная работа была проделана за кулисами!

Этот процесс повторяется для КАЖДОГО поиска записи. Однако только первый запрос выполняет всю работу; IP-адреса сервера имен будут кэшироваться после этого, и последующие запросы к DNS-серверу ISP, которые будут кэшироваться, быстро смогут перейти к шагу 8.

Теперь, что касается рандомизации шага 8, он работает на уровне записи. Допустим, что широкополосный абонент этого провайдера спросил о следующих записях:

• Foo.example.com
• Пример.com
• A www.example.com
• MX example.com (клиент ISP не должен запрашивать эту запись, это всего лишь пример)

Каждая запись будет обрабатываться как отдельная «сущность», независимо кэшироваться и просматриваться. Итак, скажем, подписчик и Интернет-провайдер никогда не сталкивались с доменом раньше, и оба имеют полностью нулевые кэшированные записи. Поиск может быть следующим:

• Foo.example.com через ns1.example.com, затем хранится в кеше ISP
• Пример.com через ns3.example.com, затем хранится в кэше провайдера
• Www.example.com через ns2.example.com, затем хранится в кэше интернет-провайдера.
• MX example.com через ns3.example.com, затем хранится в кеше ISP

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

Поэтому ваша самая большая цель - убедиться, что все ваши DNS-серверы полностью синхронизированы друг с другом, идеально отражая каждую запись DNS на каждом сервере. Вы никогда не знаете, на какой сервер будет работать DNS-клиент, и вы не можете рассчитывать на какой-либо заказ. Там нет такой вещи.

Кроме того, как упомянул Адам С, DNS-серверы серверного уровня (example.com) сами могут возвращать записи NS и рандомизировать их порядок. Обычные DNS-серверы очень часто рандомизируют свои записи NS из-за небольшого несоответствия тому, что плохая реализация DNS всегда выбирает первый возвращаемый namserver. Однако серверы имен ROOT TLD (упомянутые ранее) никогда не будут рандомизировать список, и их список - это то, что действительно имеет значение, когда дело доходит до разрешения домена. Вот почему большинство реализаций выбирают случайный сервер из списков серверов имен, чтобы всегда не попадать на один и тот же сервер и не перегружать его.

Хорошо, это ваш пример того, как работает DNS и что вы должны помнить.

• Вкратце: относитесь ко всем вашим DNS-серверам так, как если бы они были всего лишь одним сервером, поэтому ваша главная цель в жизни - обеспечить одинаковую способность отвечать на любые запросы, которые могут быть им заданы.

Отказ от ответственности: более высокие цели в жизни, чем управление DNS, могут быть доступны, но продаются отдельно, используйте свое воображение. ;-)