Понимание механизма поиска домена DNS

Конкретный запрос, который побудил меня попробовать и снять этот процесс, был:

Будет ли поиск DNS для поддоменов, таких как assets.example.comБыстрее, если родительский домен, example.comуже решена?

По моему (наивному) пониманию, базовый процесс перевода доменного имени в IP-адрес довольно прост. Адреса тринадцати корневых серверов, которые знают, как разрешать домены верхнего уровня, такие как com а также netэффективно закодированы в сетевом оборудовании. В случае поиска для example.com, наш локальный DNS-сервер, возможно, наш маршрутизатор, запрашивает один из этих корневых серверов для рассматриваемого домена и обращается к серверу имен верхнего уровня для com, Затем он спрашивает этот сервер имен, если он знает, как решить example, Если это так, мы закончили, если нет, мы перешли на другой сервер. Некоторые серверы в этом процессе могут кэшироваться, поэтому на некоторое время наш локальный маршрутизатор будет знать, где искать com а также example,

Тем не менее, я действительно не понимаю.

  • Я знаю, что существуют другие промежуточные DNS-серверы, например, предоставляемые интернет-провайдерами. В какой момент их спрашивают?
  • Если com Сервер имен TLD, на который мы ссылаемся, не знает, как решить exampleПравильно ли сказать, что это конец строки: example.com не может быть решен?
  • Когда я регистрирую домен и настраиваю серверы имен, действительно ли я редактирую группу записей NS для моего субдомена в базе данных, используемой серверами имен для этого TLD? Поддерживает ли сам регистратор прокси-серверы имен?

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

Оглядываясь назад на мой первоначальный вопрос, я мог бы сделать очень умозрительный удар по "нет", предполагая, что записи A находятся на одном и том же сервере имен. Я был бы очень благодарен любому, кто мог бы уменьшить мое невежество!

Источник

2 ответа

Решение

Будет ли поиск DNS для субдомена, такого как assets.example.com, быстрее, если родительский домен, example.com, уже разрешен?

Предполагая, что на сцене есть сервер кэширования, да. Это потому, что для того, чтобы найти запись A для чего-либо в example.com., Сервера имен для example.com. должен быть известен. Когда запрос на assets.example.com. сделан серверами имен для example.com. должен быть уже кэширован, и поэтому единственный запрос для assets.example.com. сам.

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

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

Являются ли все авторитетные серверы имен com, например точными зеркалами, или распознаватель должен пробовать каждый по очереди?

Да, они содержат одинаковую информацию. Решатель просто должен найти тот, который действительно работает.

Если сервер имен TLD com, на который мы ссылаемся, не знает, как решить пример, правильно ли говорить, что это конец строки: example.com не может быть решен?

Если.com. nameserver отвечает и говорит example.com. не существует, то в результате имя не существует. Если.com. nameserver не отвечает на запрос, распознаватель должен попробовать другой.com. сервер имен.

Когда я регистрирую домен и настраиваю серверы имен, действительно ли я редактирую группу записей NS для моего субдомена в базе данных, используемой серверами имен для этого TLD? Поддерживает ли сам регистратор прокси-серверы имен?

Правильный. Когда вы регистрируете домен, вы предоставляете записи NS (и некоторые записи A, если вам нужен клей) для вставки в родительский домен. Регистратор не обязательно сам запускает эти серверы имен, но имеет механизм для изменения базы данных этих серверов имен.

Источник

Скорее всего, ваш компьютер настроен на использование DNS-сервера у вашего интернет-провайдера. Вероятно, это кеширующий сервер имен. Это означает, что он будет кэшировать попадания (а в некоторых случаях и пропуски) в течение некоторого периода времени (обычно TTL). Если вы запросите у этого сервера имен что-то в его кэше, все готово. Это скажет вам IP.

Если это не так, он запросит у сервера имен верхнего уровня (com, net, org и т. Д.) Домен. В этом примере он спросит COM, где найти EXAMPLE.COM, и COM ответит официальным адресом сервера имен (ip) для домена EXAMPLE.COM. Затем он запросит у сервера имен IP-адрес для EXAMPLE.COM и сообщит серверу имен кэширования, который сообщит вам (это A-запись). Кроме того, он будет кешировать его в случае, если кто-то еще спросит позже.

Если вы ищете ASSETS.EXAMPLE.COM, происходит то же самое, но когда вы находите официальный сервер имен для EXAMPLE.COM, вы можете запросить его непосредственно для ASSETS.EXAMPLE.COM, и он ответит либо записью A (ip), CNAME или NS запись (есть и другие типы, такие как AAAA для ipv6, MX для почты... но этого будет достаточно для этого примера). Если он дает вам запись A, все готово. У вас есть IP. Если он дает вам NS, это означает, что этот другой сервер является полномочным для ASSETS.EXAMPLE.COM, и вы должны спросить этого парня, каков IP.

CNAME - это еще один тип, который запускает весь этот процесс заново и на самом деле недоступен в записях Apex (например, example.com).

Источник
Другие вопросы по тегам