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

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

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

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

Тем не менее, я этого не понимаю.

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

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

Оглядываясь назад на свой первоначальный вопрос, я мог бы сказать «нет», предполагая, что обе записи A находятся на одном сервере имен. Это точно?


dns nameservers subdomain resolve
person cantlin    schedule 09.08.2012    source источник

Ответы (1)


arrow_upward
22
arrow_downward

Во-первых, заблуждения:

  • Корневые подсказки (имена и IP-адреса 13 корневых серверов) вряд ли когда-либо жестко запрограммированы на сетевом оборудовании. Сетевое оборудование, такое как маршрутизатор, иногда может иметь встроенный DNS-преобразователь, если у него также есть DHCP-сервер, но если он есть, обычно это просто преобразователь переадресации, который передает запрос на вышестоящий сервер имен (полученный от ISP. ), если он не знает ответа.
  • серверы имен, предоставляемые интернет-провайдерами, обычно не действуют как «промежуточные DNS-серверы». Либо вы используете свои собственные серверы имен (например, корпоративные серверы имен, либо вы установили BIND на свой компьютер), либо вы используете серверы, предоставленные вашим интернет-провайдером. В любом случае, какой бы сервер имен вы ни выбрали, он позаботится о рекурсивном процессе разрешения от начала до конца. Исключение составляют вышеупомянутые перенаправляющие серверы имен.
  • Если com сервер имен TLD не знает, как разрешить example, он не сможет решить, какие другие серверы имен проверить. Он сам является сервером имен, который нужно проверить. Он либо знает о example, либо example не существует.

Ответ на ваш вопрос - да. Если сервер имен уже разрешил example.com (и этот результат все еще действителен в его кэше), то он сможет разрешить assets.example.com быстрее.

Процесс рекурсивного разрешения во многом такой, как вы его описали: сначала найдите серверы имен для . (корень), затем найдите серверы имен для com и т. Д. Только рекурсивный преобразователь фактически не запрашивает серверы имен для . и com и example.com. На самом деле он каждый раз запрашивает assets.example.com. Корневые серверы не дадут ответа на этот вопрос (они ничего не знают о assets.example.com), но они могут, по крайней мере, предложить ссылку на серверы имен для com. Точно так же серверы имен для com не ответят на вопрос (они тоже не знают), но они могут предложить ссылку на серверы имен для example.com. Серверы имен для example.com могут знать или не знать ответ на вопрос в зависимости от того, будет ли assets.example.com делегирован дальше другим серверам имен или предоставлен в той же зоне, что и example.com. Соответственно, рекурсивный преобразователь получит либо окончательный ответ, либо другое направление.

person Celada    schedule 09.08.2012
comment
Таким образом, повышение производительности связано с тем, что клиент уже знает о сервере имен, который знает, как разрешить example.com, поэтому он может обратиться напрямую и запросить assets.example.com? - person Michael Crenshaw; 08.11.2018