Если ваш настроенный сервер имен не имеет кэшированных результатов, сколько серверов имен должен запросить ваш сервер имен для разрешения maps.google.com? Какие команды вы бы использовали, чтобы найти все эти серверы имен? Перечислите по одному на каждом уровне и объясните, почему этот уровень необходим.
Хорошо, давайте выберем это.
«Предполагая, что у настроенного сервера имен нет кэшированных результатов» - во-первых, если у него вообще нет кэшированных данных, то он ничего не может разрешить. Чтобы заполнить кэш резолвера, вам нужно иметь записи NS и адреса (A, AAAA) для зоны .(AKA root). Это корневые серверы имен, которые находятся в root-servers.net.зоне. В этой зоне или этих DNS-серверах нет ничего волшебного. Тем не менее, эти данные часто предоставляются «вне диапазона» для распознавателя DNS, именно для заполнения кеша преобразователя. Только для авторитетных серверов имен эти данные не нужны, а для разрешения серверов имен.
Также «разрешить» на что? Любой тип RR на это имя? ARR? Или что-то другое? Какой класс ( CH/ Chaosnet, IN/ Интернет, ...)? Точный процесс будет другим, но общая идея останется прежней.
Если мы можем предположить, что мы знаем, как найти корневые серверы имен, но не более того, и что под «разрешением» мы подразумеваем получение содержимого любых IN ARR, связанных с именем, это становится намного более практичным.
Чтобы разрешить DNS-имя, вы в основном делите имя на метки, а затем идете справа налево. Не забывайте .в конце; вы бы действительно решили, maps.google.com.а не maps.google.com. Это оставляет нас с необходимостью разрешения (мы знаем это, но реализация DNS-преобразователя, вероятно, не будет):
.com.google.com.maps.google.com.
Начните с выяснения, где спросить содержание .. Это легко; у нас уже есть эта информация: имена корневых серверов имен и IP-адреса . Итак, у нас есть корневой сервер имен. Допустим, мы решили использовать 198.41.0.4 ( a.root-servers.netтакже 2001: 503: ba3e :: 2: 30) для продолжения разрешения имени. На практике одно из первых действий, выполняемых распознавателем, вероятно, будет заключаться в том, чтобы использовать предоставленные данные корневого сервера, чтобы запросить у одного из серверов корневой зоны точный список серверов имен для корневой зоны, таким образом гарантируя, что если какой-либо из имена и IP-адреса действительны и доступны, у них будет полный и полный набор данных для корневой зоны, когда начнется разрешение.
maps.google.com. IN AОтстрелить DNS-запрос на 198.41.0.4. В ответ он скажет: «Нет, не собираюсь этого делать, но вот кто-то, кто может знать»; это реферал. Он содержит NSзаписи для ближайшей зоны, о которой знает рассматриваемый сервер, а также любые склеенные записи, которые сервер имеет в наличии. Если склеенные данные недоступны, вам сначала нужно разрешить хост, названный в выбранной вами записи NS, поэтому создайте отдельное разрешение имен, чтобы получить IP-адрес; если доступны клейкие данные, у вас будет IP-адрес сервера имен, который как минимум «ближе» к ответу. В этом случае это будет набор серверов для com.зоны, а также предоставляются склеенные данные.
Повторите процесс, задав один из com.серверов имен тот же вопрос. Они тоже не знают, но направят вас к авторитетным серверам имен Google. На этом этапе в общем случае будет удар или пропуск, независимо от того, предоставлены ли данные склеивания или нет; ничто не мешает comдомену иметь серверы имен только nl, например, в этом случае склеенные данные вряд ли будут доступны с серверов рДВУ. Предоставленные данные клея также могут быть неполными, или, если вам действительно не повезло, это может быть даже неверно! Вы всегда должны быть готовы к появлению той отдельной резолюции имен, которую я упоминал выше.
По сути, вы продолжаете, пока не получите ответ с установленным aaфлагом (достоверный ответ). Этот ответ будет сказать вам , что вы просите, или что RR вы просили не существует (или NXDOMAIN, или NOERRORс нулевыми записями данных ответа). Продолжайте искать ответы типа SERVFAIL(и отступите на один шаг и попробуйте другой сервер, если он у вас есть; если все именованные серверы вернутся SERVFAIL, не пройдут процедуру разрешения имен и вернутся SERVFAILк клиенту).
Альтернативой запросу полного имени RR с каждого сервера (что может считаться плохой практикой) является использование разделенного списка меток, который мы определили ранее, запросить серверы имен, заданные сервером, дальше к корню для IN NSи IN A/ IN AAAARR. для этой метки, и используйте их для дальнейшего процесса разрешения имен. Это лишь незначительно отличается на практике, и тот же процесс все еще применяется.
Вы можете смоделировать весь этот процесс, используя +traceопцию digутилиты, которая входит в состав BIND или set debugв nslookup.
Стоит также помнить, что некоторые типы RR (в частности NS, MXи некоторые другие; также A6некоторое время довольно разумно использовались, но устарели) могут ссылаться и на другие RR. В этом случае вам может понадобиться запустить еще один процесс разрешения имен, чтобы дать полный и полезный ответ вашему клиенту.
dig +trace, но я не уверен, что подразумевается под уровнями. Это может быть вопрос для сбоя сервера.