Функциональность
Рассмотрим алгоритм работы программы разрешения имен (алгоритм 2) со следующими исходными параметрами:
 | SLIST — структура, описывающая серверы имен и зону, которые в данный момент просматривает программа разрешения. Эта структура содержит информацию о серверах имен, которые, предположительно, могут содержать искомые данные. |
| SBELT — структура, схожая с SLIST. Она инициализируется из файла конфигурации и содержит список серверов, которые должны использоваться, когда программа разрешения имен не имеет никакой информации для выбора сервера имен. |
| CACHE — эта структура хранит результаты предыдущих запросов. |
Алгоритм 2. Работа программы разрешения имен
Верхний уровень алгоритма запросов содержит четыре шага:
1. Просмотреть информацию на локальном компьютере (как правило, это содержание кэша) и, если информация найдена, вернуть ответ клиенту.
2. Найти сервер, вероятнее всего содержащий ответ на запрос.
3. Отправлять на него запрос до тех пор, пока не придет первый ответ.
4. Проанализировать ответ:
• если ответ содержит всю запрашиваемую информацию или содержит имя ошибки, поместить эти данные в кэш и вернуть клиенту
• если ответ содержит ссылку на другой сервер, поместить эту информацию в кэш и перейти к шагу 2
• если ответ содержит информацию CNAME и не содержит ответа на запрос, поместить информацию CNAME в кэш, изменить SNAME на каноническое имя ресурса из RR CNAME и перейти к шагу 1
• если ответ содержит информацию о том, что запрашиваемые серверы не работают или произошли еще какие-либо сбои в работе, удалить сервер из SLIST и перейти к шагу 3
Рассмотрим эти шаги алгоритма более подробно:
| На шаге 1 поиск данных производится в кэше компьютера. Если данные находятся в кэше, то считается, что при нормальной работе этого достаточно для формирования ответа. Некоторые программы разрешения можно настроить так, чтобы они не позволяли пользовательским программам использовать кэшированные данные, однако в условиях нормальной работы этого делать не рекомендуется. |
<
/p>
| На шаге 2 программа разрешения ищет сервер имен, которому можно было бы отправить запрос. Стратегия поиска выглядит так: сначала просматриваются записи RR локального сервера, начиная с SNAME, затем просматриваются серверы-родители SNAME, затем родители этих родителей и т. д. до корня. Например, если SNAME = Mockapetris.ISI.EDU, сначала мы ищем NS записи сервера Mockapetris.ISI.EDU, затем ISI.EDU, затем EDU, и наконец "." (корень). Записи NS RR содержат имена хостов зоны, расположенной рядом или выше SNAME. Копируем этот список в SLIST и, используя локальные данные, определяем адреса этих хостов. |
В некоторых случаях информация адреса недоступна, тогда программа может запустить параллельный процесс программы разрешения имен, который будет пытаться определить адреса по уже известным данным и по мере получения требуемой информации передавать ее программе-родителю. Если поиск записей RR NS завершился неудачно, программа разрешения имен инициализирует SLIST из структуры SBELT, т. е. если программа разрешения не знает, к какому серверу имен ей обращаться, она должна использовать информацию из файла настройки, в котором содержится список "пожарных" серверов. Хотя подобная ситуация относится к исключительным ситуациям, из файла конфигурации, как правило, выбираются какие-либо два сервера из корневых серверов и два сервера из серверов домена. Такой алгоритм построен для увеличения производительности работы системы, поскольку корневые серверы предоставляют быстрый доступ ко всему пространству имен, а локальные серверы имеют более быстрый доступ к сети данного домена,
| На шаге 3 запросы будут отправляться до тех пор, пока не будет получен какой-либо ответ (организуется периодический опрос по всем адресам серверов). |
| На шаге 4 производится анализ ответов (синтаксический разбор поступивших данных). Программа должна следить за тем, чтобы ответы содержали метку (идентификатор) сообщения запроса. |
Как правило, на запрос от уполномоченного сервера приходит один ответ, содержащий либо сообщение об ошибке, либо запрашиваемые данные. Данные передаются пользовательской программе и, если поле TTL больше нуля, помещаются в кэш для использования в дальнейшем.
Если ответ содержит сообщение о перенаправлении запроса, программа разрешения должна проверить, что рекомендуемый для обращения сервер "ближе", чем серверы из списка SLIST. Если нет, ответ считается недействительным и отбрасывается. В том случае, если рекомендуемый сервер "ближе", запись RR NS сервера и его адреса кэшируются, записываются в SLIST, и процесс поиска возобновляется.
Если ответ содержит CNAME, а тип запроса не совпадает с CNAME, процесс поиска возобновляется с параметрами ответа (каноническим именем) CNAME.
Содержание раздела
