Конкретный запрос, который побудил меня попытаться отобрать этот процесс, был:
Будет ли поиск в DNS поддомена, например assets.example.com, будет быстрее, если родительский домен example.com, уже решено?
По моему (наивному) пониманию, основной процесс перевести доменное имя в IP-адрес довольно просто. Адреса тринадцати корневых серверов, которые знают, как разрешать домены верхнего уровня, такие как com и net, фактически жестко запрограммированы в сетевом оборудовании. В случае поиска example.com, наш локальный DNS-сервер, возможно, наш маршрутизатор, запрашивает один из этих корневых серверов для рассматриваемого домена и обращается к серверу имен верхнего уровня для com. Затем он спрашивает этот сервер имен, знает ли он, как разрешить example. Если это так, мы закончили, если нет, нас перенаправят на другой сервер. Некоторые из серверов в этом процессе могут кэшировать, так что какое-то время наш локальный маршрутизатор теперь будет знать, где искать com и example.
Тем не менее, я этого не понимаю.
com Сервер имен TLD, на который мы ссылаемся, не знает, как разрешить example, правильно сказать, что это конец строки: example.com не может быть решен?Википедия объясняет, что некоторые DNS-серверы сочетают кеширование с реализацией рекурсивного запроса, что позволяет им обрабатывать попадания в кеш и надежно устранять промахи кеша. Я не понимаю, как эти серверы запрашиваются или как (даже в широком смысле) работает алгоритм разрешения. Все авторитетные com серверы имен, например, точные зеркала, или резолверу придется пробовать каждый по очереди?
Оглядываясь назад на свой первоначальный вопрос, я мог бы сделать очень спекулятивный удар в ответ «нет», если предположить, что обе записи A находятся на одном сервере имен. Буду очень признателен всем, кто сможет уменьшить мое невежество!
Будет ли DNS-поиск субдомена, такого как assets.example.com, быстрее, если родительский домен example.com уже разрешен?
Если предположить, что в сцене есть кеширующий сервер, да. Это связано с тем, что для того, чтобы найти запись A для чего-либо на example.com., Серверы имен для example.com. должно быть известно. Когда запрос на assets.example.com. сделан серверами имен для example.com. уже должен быть кэширован, поэтому единственный запрос - assets.example.com. сам.
Я знаю, что есть и другие промежуточные DNS-серверы, например, предоставляемые интернет-провайдерами. В какой момент их спрашивают?
Обычно это кэширующие или рекурсивные серверы имен. Они выполняют тяжелую работу от вашего имени (несколько запросов для обхода дерева), а затем кэшируют результат, чтобы ускорить последующие запросы с тем же именем.
Все ли авторитетные серверы имен com, например, являются точными зеркалами, или преобразователь должен будет пробовать каждый по очереди?
Да, они содержат ту же информацию. Решателю просто нужно найти тот, который действительно работает.
Если упоминаемый нами сервер имен TLD com не знает, как разрешить example, можно ли сказать, что это конец строки: example.com не может быть разрешен?
Если домен .com. сервер имен отвечает и говорит example.com. не существует, то в результате имя не существует. Если домен .com. сервер имен не отвечает на запрос, преобразователь должен попробовать другой .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 - это еще один тип, который запускает весь этот процесс заново и в любом случае фактически недоступен для записей вершины (например, example.com).