Локальная система разрешения имен

На начальных этапах процесса в программе на локальном компьютере используется доменное имя DNS. Затем запрос передается в службу «DNS - клиент» для сопоставления с помощью локальной кэшированной информации. Если удается разрешить запрошенное имя, поступает ответ на запрос и процесс завершается. Кэш локального сопоставления имен может включать информацию об именах из двух возможных источников.

1. Если имеется локальный файл Hosts, все сопоставления имен и адресов из этого файла предварительно загружаются в кэш при запуске службы «DNS-клиент».

2. Записи ресурсов, полученные в ответах на запросы из предыдущих запросов DNS, добавляются в кэш и сохраняются в нем в течение определенного периода времени.

Если клиент не находит сопоставления в кэше, процесс продолжается с помощью запроса на разрешение имени от клиента к DNS-серверу.

Запрос к DNS-серверу

Клиент запрашивает основной DNS-сервер. Из глобального списка выбирается сервер, используемый на начальной стадии запроса от клиента к серверу. Когда DNS-сервер принимает запрос, он сначала проверяет, можно ли дать удостоверяющий ответ на базе записей ресурсов, содержащихся в локальной зоне в конфигурации сервера. Если запрошенное имя соответствует информации в записи ресурса в локальной зоне, сервер дает удостоверяющий ответ, используя эту информацию для разрешения имени.

Если в зоне нет информации для запрошенного имени, сервер проверяет, можно ли разрешить имя, используя информацию предыдущих запросов в локальном кэше. Если здесь обнаруживается совпадение, сервер отвечает с использованием этой информации. И в этом случае, если основной сервер может дать запрашивающему клиенту утвердительный ответ на сопоставление из собственного кэша, запрос завершается. Если на основном сервере не удается найти запрошенное имя — ни в кэше, ни в зонах — процесс выполнения запроса может продолжаться с использованием рекурсии для полного разрешения имени. При этом другие DNS-серверы помогают разрешить имя.

Служба «DNS-клиент» по умолчанию указывает серверу использовать процесс рекурсии для полного разрешения имен в интересах клиентов перед возвращением ответа. В большинстве случаев DNS-серверы по умолчанию настраиваются на поддержку процесса рекурсии, как показано на Рисунке 2.

Рисунок 2 - Процесс рекурсии при разрешении имени

Для правильного выполнения рекурсии DNS-сервером ему необходимы сведения о контактах с другими DNS-серверами в пространстве доменных имен DNS. Такая информация обеспечивается в виде корневых ссылок, списка предварительных записей ресурсов, которые могут использоваться службой DNS для обнаружения других DNS-серверов, которые являются удостоверяющими для корня дерева пространства доменных имен DNS . Корневые серверы являются удостоверяющими для корня доменов и доменов верхнего уровня в дереве пространства доменных имен DNS.

Ранее отмечалось, что процесс заканчивается возвращением клиенту утвердительного ответа. Однако запросы могут возвращать и другие ответы. Приведем наиболее общие типы таких ответов:

1. удостоверяющий ответ;

2. утвердительный ответ;

3. ссылочный ответ;

4. отрицательный ответ.

Удостоверяющий ответ представляет утвердительный ответ, возвращенный клиенту и доставленный с установленным битом полномочий в сообщении DNS, указывающим, что ответ получен от сервера, имеющего прямые полномочия для запрашиваемого имени.

Утвердительный ответ может содержать запрошенную запись ресурса или список записей ресурсов (который также называют набором записей), соответствующих запрошенному доменному имени DNS и типу записи, указанному в сообщении запроса.

Ссылочный ответ содержит дополнительные записи ресурсов, не указанные по имени или типу в запросе. Ответ этого типа возвращается клиенту, если процесс рекурсии не поддерживается. Эти записи должны рассматриваться как справочные, которые могут использоваться клиентом для продолжения запроса с помощью итераций. Если клиент способен использовать итерации, он может выполнить дополнительные запросы в попытке полностью разрешить имя самостоятельно.

Отрицательный ответ от сервера может указывать на один из двух возможных результатов попытки сервера обработать и рекурсивно полностью и удостоверяющим образом сопоставить имя в запросе:

ü Удостоверяющий сервер ответил, что запрошенное имя не существует в пространстве имен DNS.

ü Удостоверяющий сервер ответил, что запрошенное имя существует, но для этого имени отсутствуют записи указанного типа.

Система сопоставления имен передает результаты запроса в виде утвердительного или отрицательного ответа в запрашивающую программу и кэширует ответ. Итерации представляют тип сопоставления имен, используемый DNS-клиентами и серверами при выполнении следующих условий.

ü Клиент запрашивает использование рекурсии, но рекурсия отключена на DNS-сервере.

ü Клиент не запрашивает использование рекурсии при запросе к DNS-серверу.

Итерационный запрос от клиента сообщает DNS-серверу, что клиент ожидает от DNS-сервера наиболее точный ответ немедленно без обращения к другим DNS-серверам. Когда используются итерации, DNS-сервер отвечает клиенту о запрошенных именах на основании собственной информации о пространстве имен. Например, если DNS-сервер в интрасети получает запрос от локального клиента для имени «www.edu.ru», он может возвратить ответ из кэша имен. Если в данный момент запрошенное имя не сохраняется в кэше сервера, то сервер может ответить предоставлением ссылки — т.е. списка записей ресурсов других DNS -серверов, которые ближе к имени, запрошенному клиентом. Когда предоставляется ссылка, DNS-клиент принимает на себя ответственность за продолжение итерационных запросов на сопоставление имени к другим указанным в конфигурации DNS-серверам.

Например, в наиболее общем случае DNS-клиент может расширить область поиска до серверов корневого домена в Интернете в попытках обнаружить удостоверяющие DNS-серверы для домена «ru». После установления контакта с корневыми серверами Интернета клиент может получить от них дальнейшие итерационные ответы, указывающие на фактические DNS-серверы Интернета для домена «edu.ru». Когда клиенту предоставляются записи для этих DNS-серверов, он может отправить дальнейший итерационный запрос внешним DNS -серверам edu в Интернете, которые могут дать определенный и удостоверяющий ответ. При использовании итераций DNS-сервер может также содействовать в запросе на сопоставление имени, предоставив клиенту собственный наиболее точный ответ. Для большинства итерационных запросов клиент использует локальный список DNS-серверов для обращения к другим серверам имен в пространстве имен DNS, если его собственный основной DNS-сервер не может сопоставить имя в запросе.

По мере того как DNS-серверы обрабатывают запросы клиентов с помощью рекурсии или итераций, они находят и накапливают значительный объем информации о пространстве имен DNS. Эта информация кэшируется сервером. Кэширование дает возможность ускорить сопоставление часто используемых имен DNS в последующих запросах и существенно снижает трафик запросов DNS в сети. При выполнении рекурсивных запросов DNS-серверами для клиентов они временно кэшируют записи ресурсов. Кэшированные записи ресурсов содержат информацию, полученную от DNS-серверов, которые являются удостоверяющими для доменных имен DNS. Эта информация накапливается при выполнении итерационных запросов в процессе поиска и полного ответа на рекурсивный запрос, выполняемый в интересах клиента. Когда затем другие клиенты размещают новые запросы на информацию, отвечающую кэшированным записям ресурсов, DNS-сервер может использовать данные из кэшированных записей ресурсов для ответа. При кэшировании информации значение срока жизни применяется ко всем кэшированным записям ресурсов. Пока не истек срок жизни кэшированной записи ресурса, DNS-сервер может продолжать кэшировать и снова использовать запись ресурса при ответах на соответствующие запросы клиентов. Значения срока жизни кэширования, используемые записями ресурсов в большинстве конфигураций зон, назначаются в параметре Мин. срок жизни TTL (по умолчанию), который задается в начальной записи зоны. По умолчанию задается значение минимального срока жизни 3600 секунд (1 час), но это значение может быть изменено; могут также задаваться отдельные значения срока жизни для каждой записи ресурса.

Обратный просмотр

В большинстве операций просмотра DNS-клиенты обычно выполняют прямой просмотр, т. е. поиск, основанный на имени DNS другого компьютера, сохраненного в записи ресурса адреса (A). В этом типе запроса в качестве данных для ответа на запрос ожидается IP-адрес. DNS также обеспечивает возможность обратного просмотра, в котором клиенты используют известный IP-адрес для поиска имени компьютера по этому адресу. Обратный просмотр фактически является формой вопроса типа «Можете ли вы сказать мне имя DNS компьютера, который использует IP-адрес 192.168.1.20?».

Система DNS не разрабатывалась изначально для поддержки запросов этого типа. Одной из проблем при поддержке запросов обратного просмотра является различие в способах организации и индексации пространства имен DNS и способов назначения IP-адресов. Если бы единственным таким способом был бы поиск во всех доменах пространства имен DNS, то для обработки обратного запроса потребовалось бы слишком много времени и такой запрос оказался бы бесполезным.

Чтобы разрешить эту проблему, в стандартах DNS был определен и зарезервирован специальный домен в пространстве имен DNS Интернета, in-addr.arpa, обеспечивающий практичный и надежный способ выполнения обратных запросов. Чтобы создать обратное пространство имен, поддомены в домене in-addr.arpa формируются с помощью обратного упорядочения чисел в точечно-десятичной нотации IP-адресов. Такое обратное упорядочение доменов для каждого октета необходимо, поскольку в отличие от имен DNS, для которых IP-адреса читаются слева направо, здесь интерпретация выполняется в обратном порядке. Когда IP-адрес читается слева направо, информация анализируется от наиболее общей (IP-адрес сети в левой части адреса) до наиболее конкретной (IP-адрес узла в последнем октете). По этой причине порядок октетов IP-адреса должен быть обращен при построении дерева домена in-addr.arpa. IP-адреса дерева DNS in-addr.arpa могут делегироваться организациям, которым назначается ограниченный набор IP-адресов в границах определенных для Интернета классов адресов. И, наконец, для дерева домена in-addr.arpa, встроенного в DNS, требуется определение дополнительного типа записей ресурсов — запись ресурса указателя (PTR). Такая запись ресурса используется для сопоставления в зоне обратного просмотра, обычно соответствующего записи ресурса именованного узла (A) для имени DNS компьютера в зоне прямого просмотра.

Следующий Рисунок 3 иллюстрирует обратный запрос, инициируемый DNS-клиентом (host-b), которому требуется узнать имя другого узла (host-a) по его IP-адресу 192.168.1.20.

Рисунок 3 - Обратный запрос

Как показано на Рисунке 3, обратный запрос включает следующие этапы:

1. Клиент «host-b» запрашивает DNS-сервер о записи ресурса указателя (PTR), сопоставляющей IP-адрес 192.168.1.20 для имени «host-a».
Поскольку запрос относится к записям PTR, система сопоставления имен обращает адрес и добавляет имя домена «in-addr.arpa» в конец обращенного адреса. В результате образуется полное доменное имя узла («20.1.168.192.in-addr.arpa.»), для которого будет проводиться поиск в зоне обратного просмотра.

1. После обнаружения имени удостоверяющий DNS-сервер для имени «20.1.168.192.in-addr.arpa» может возвратить ответ с информацией записи PTR. В этой информации содержится доменное имя DNS узла «host-a», что приводит к завершению процесса обратного просмотра. Необходимо помнить, что если запрошенное обратное имя не может быть возвращено DNS-сервером, можно использовать сопоставление имен DNS (либо рекурсию, либо итерации) для обнаружения DNS-сервера, который является удостоверяющим для зоны обратного просмотра и содержит запрашиваемое имя. В этом смысле процесс сопоставления имен при обратном просмотре аналогичен процессу прямого просмотра

Инвертированные запросы

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

Служба DNS распознает и принимает сообщения инвертированных запросов и отвечает на них с имитацией ответа на инвертированный запрос.

Динамическое обновление

Динамическое обновление позволяет компьютерам DNS-клиентов регистрировать и динамически обновлять собственные записи ресурсов с помощью DNS-сервера при каждом возникновении изменений. Это снижает необходимость администрирования записей зон вручную, в особенности для клиентов, которые путешествуют или часто меняют расположение и получают IP-адреса через DHCP.

Клиентские и серверные службы DNS поддерживают использование динамических обновлений, как описано в документе RFC 2136, «Dynamic Updates in the Domain Name System». Служба DNS-сервер поддерживает включение и отключение динамических обновлений отдельно для каждой зоны на каждом сервере, настроенном для загрузки либо стандартной основной зоны, либо зоны, интегрированной в каталоги. Служба DNS-клиент будет по умолчанию динамически обновлять свои записи ресурсов узла (A) в DNS, когда была выполнена настройка для TCP/IP.

Динамические обновления обычно запрашиваются, когда изменяется имя DNS или IP-адрес компьютера. Например, предположим, что для клиента с именем «oldhost» в окне Свойства системы заданы следующие имена (Таблица 2):

Таблица 2 - Старые имена компьютера

Имя компьютера	oldhost
Доменное DNS-имя компьютера	mspu.edu.ru.
Полное имя компьютера	oldhost. mspu.edu.ru

В этом примере в конфигурации компьютера нет доменных имен DNS, специфических для подключения. В дальнейшем компьютер переименовывается из «oldhost» в «newhost», в результате чего имена изменяются следующим образом (Таблица 3).

Таблица 3 - Новые имена компьютера

Имя компьютера	newhost
Доменное DNS-имя компьютера	mspu.edu.ru.
Полное имя компьютера	newhost.mspu.edu.ru

После изменения имени в окне Свойства системы отображается приглашение перезагрузить компьютер. Когда при перезагрузке компьютер запускает ОС, служба DHCP-клиент выполняет следующие действия для обновления DNS.

1. Служба DHCP-клиент отправляет запрос для типа начальной записи зоны (SOA) с использованием доменного имени DNS компьютера. Клиентский компьютер использует текущее полное доменное имя узла компьютера (в данном случае «newhost. mspu.edu.ru») как имя, указанное в этом запросе.
2. Удостоверяющий DNS-сервер зоны, содержащей полное доменное имя узла клиента, отвечает на запрос типа SOA.
3. После этого служба DHCP-клиент пытается установить контакт с основным DNS-сервером.
   Клиент обрабатывает ответ на запрос SOA для его имени, чтобы определить IP-адрес DNS-сервера, удостоверенного как основной сервер, для принятия его имени. Далее он выполняет такую последовательность шагов, необходимых, чтобы установить контакт и динамически обновить его основной сервер.
1. Клиент отправляет запрос на динамическое обновление основному серверу, определенному в ответе на запрос SOA.
   Если обновление выполняется успешно, другие действия не предпринимаются.
2. При отказе на обновление клиент отправляет запрос типа NS (о серверах имен) для зоны, имя которой указано в записи SOA.
3. Когда клиент получает ответ на этот запрос, он отправляет запрос SOA на первый DNS-сервер, перечисленный в ответе.
4. После разрешения имен в запросе SOA клиент отправляет динамическое обновление серверу, указанному в возвращенной записи SOA. Если обновление выполняется успешно, другие действия не предпринимаются.
5. При отказе на обновление клиент повторяет запрос SOA, отправляя его к следующему DNS-серверу, перечисленному в ответе.
4. Как только находится основной сервер, который может выполнить обновление, клиент отправляет запрос на обновление, который обрабатывается сервером.

Содержимое запроса на обновление включает инструкции добавить записи ресурсов A (и возможно PTR) для имени «newhost.mspu.edu.ru» и записи этих типов для ранее зарегистрированного имени «oldhost.mspu.edu.ru».

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

Динамические обновления отправляются или выполняются периодически. По умолчанию компьютер отправляет обновления каждые 7 дней. Если в результате обновления данные в зоне не изменяются, зона остается в текущей версии и никакие изменения не записываются. Обновления выполняются только при фактических изменениях имен и адресов в зоне или в результате добавочной зонной передачи.