Учебно-методическии комплекс дисциплины «Компьютерные сети» для специальности 6М011100 — «Информатика» (стр. 20 )

□ Полномочный сервер имен — это сервер, на котором зарегистрирован данный хост. Обычно хосты регистрируются на локальных серверах имен Интернет-провайдеров (на самом деле в целях обеспечения надежности хосты регистрируются не менее чем на двух полномочных серверах). Полномочный сервер содержит информацию о связи имени хоста с его IP-адресом. Когда корневой сервер посылает запрос полномочному серверу, последний отсылает ответ, содержащий требуемый IP-адрес. Далее корневой сервер отсылает полученный ответ локальному серверу, а локальный сервер — хосту пользователя. Таким образом, многие серверы имен одновременно являются локальными и полномочными.

Рассмотрим простой пример. Предположим, что хост surf. eurecom. fr создал запрос IP-адреса gaia. cs. umass. edu. Пусть локальный сервер имен института Eurecom имеет имя dns. eurecom. fr, а полномочный сервер имен хоста gaia. cs. umass. edu — имя dns. umass. edu. Как показано на рис. 5.2, хост surf. eurecom. fr сначала отправляет запрос своему локальному серверу имен dns. eurecom. fr, в котором содержится имя для преобразования в IP-адрес (gaia. cs. umass. edu). Локальный сервер имен передает запрос корневому серверу, который, в свою очередь, перенаправляет его серверу, являющемуся полномочным для всех хостов домена umass. edu, например dns. umass. edu. Сервер обрабатывает запрос, создает ответ с IP-адресом хоста gaia. cs. umass. edu и отсылает его хосту surf. eurecom. fr через корневой и локальный серверы имен. Обратите внимание на то, что в этом примере процедура получения IP-адреса требует передачи шести DNS-сообщений: трех запросов и трех ответов.

Рис. 5.2 Рекурсивные запросы при получении IP-адресаgaia. cs. umass. edu

Выше было сделано допущение о том, что корневой сервер имен располагает IP-адресами полномочных серверов для любого хоста. На самом деле это допущение неверно. Корневой сервер «знает» адрес лишь промежуточного сервера имен, который содержит IP-адрес полномочного сервера хоста. Для того чтобы проиллюстрировать это, снова обратимся к примеру с хостом surf. eurecom. fr, желающим получить IP-адрес хоста gaia. cs. umass. edu. Предположим, что локальный сервер имен университета Массачусетс имеет имя dns. umass. edu. Допустим также, что каждое подразделение университета располагает собственным локальным сервером имен, являющимся полномочным для всех хостов соответствующего подразделения. Как показано на рис. 5.3, когда корневой сервер имен получает запрос с именем, оканчивающимся на umass. edu, он перенаправляет запрос серверу имен dns. umass. edu. Далее сервер dns. umass. edu перенаправляет все запросы с именами, оканчивающимися на cs. umass. edu, локальному серверу имен dns. cs. umass. edu, являющемуся полномочным для всех хостов cs. umass. edu. Искомый IP-адрес передается сервером dns. cs. umass. edu хосту surf. eurecom. fr последовательно через серверы dns. umass. edu, корневой сервер имен и локальный сервер имен dns. eurecom. fr. Таким образом, получение IP-адреса в этом примере потребовало посылки восьми DNS-сообщений. На практике встречаются ситуации, когда между корневым и полномочным серверами имен находятся два или более промежуточных сервера, что еще увеличивает количество DNS-сообщений в цикле получения IP-адреса.

Рис. 5.3 Рекурсивные запросы к промежуточному серверу имен, расположенному между корневым и полномочным серверами

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

Последовательность запросов, необходимых для получения IP-адреса хоста, может содержать одновременно и рекурсивные, и итеративные запросы. Пример такой смешанной цепи представлен на рис. 5.4. На практике часто встречаются ситуации, когда все запросы являются рекурсивными за исключением единственного итеративного запроса локального сервера имен к корневому. Это объясняется тем, что корневые серверы вынуждены обрабатывать значительное число запросов, а итеративный механизм снижает трудоемкость обработки запроса сервером. На сайте http://www. /kurose-ross вы можете найти Java-апплет, позволяющий экспериментировать с различными комбинациями рекурсивных и итеративных запросов.

Рис. 5.4 Цепочка, включающая рекурсивные и итеративные запросы

Теперь настало время рассмотреть такую важную составляющую DNS, как кэширование. Механизм кэширования активно используется DNS для того, чтобы сократить число запросов и время получения IP-адресов хостами. Идея кэширования проста: когда сервер имен получает ответ, содержащий IP-адрес хоста, он сохраняет пару «имя/IР-адрес хоста» в специально отведенной области памяти (дисковой или оперативной). В случае, если этот сервер имен вновь получит запрос с тем же именем хоста, он сможет извлечь соответствующую пару из кэшпамяти и сгенерировать ответ, даже не являясь полномочным сервером хоста. Чтобы не хранить большие объемы невостребованной информации, записи остаются в кэш-памяти некоторый ограниченный промежуток времени (обычно 48 часов). Рассмотрим следующий пример. Пусть хост surf. eurecom. fr создал запрос на получение IP-адреса хоста . Несколько часов спустя другой хост института Eurecom, например baie. eurecom. fr, также создал DNS-запрос хосту . Механизм кэширования обеспечивает появление IP-адреса на локальном сервере имен Eurecom после выполнения запроса хоста surf. eurecom. fr; таким образом, запрос хоста baie. eurecom. fr будет удовлетворен локальным сервером без дальнейшей передачи. Кэширование поддерживается всеми серверами имен.

3. DNS-записи

Серверы имен, в совокупности образующие базу данных DNS, хранят ресурсные записи (Resource Records, RR), связывающие имена хостов с их IP-адресами. Каждый DNS-ответ содержит одну или более ресурсных записей. Ниже мы рассмотрим несколько вопросов, касающихся записей и сообщений DNS.

RR-запись состоит из четырех полей:

(Name. Value, Type, TTL)

Поле TTL определяет время жизни записи в кэш-памяти; говоря точнее, оно содержит время удаления записи из кэш-памяти. В примерах, приводимых ниже, мы будем опускать поле TTL. Значения полей Name и Value зависят от поля Туре.

□ Если Туре = А, то поле Name содержит имя хоста, a Value — IP-адрес. Таким образом, тип А в дополнение к IP-адресу включает стандартное имя хоста. Примером записи типа А является (relayl. bar. , 145.37.93.126, А).

□ Если Туре = NS, то поле Name содержит домен (например, ), a Value — имя хоста или полномочного сервера, располагающего информацией о том, на каком сервере имен хранятся IP-адреса хостов домена. Эта запись используется для дальнейшей передачи запроса по цепочке серверов имен. Примером записи типа NS является (, dns. , NS).

□ Если Туре = CNAME, то Value является каноническим именем хоста, a Name — псевдонимом хоста. Этот тип записи позволяет получить каноническое имя хоста по известному псевдониму. Примером записи типа CNAME является (, relayl. bar. , CNAME).

□ Если Туре = MX, то Value является каноническим именем почтового сервера с псевдонимом Name. Примером записи типа MX является (, mai4.bar. , MX). Записи типа MX позволяют использовать простые псевдонимы вместо длинных имен хостов почтовых серверов. Обратите внимание на то, что при помощи записей типа MX компании могут задействовать один и тот же псевдоним для своего почтового сервера и других серверов (например, web-сервера). Для получения канонического имени почтового сервера DNS-клиент создает запрос на запись типа MX, а для получения канонического имени web-серверов и прочих серверов — запрос на запись типа CNAME.

Если сервер имен является полномочным для хоста, то для этого хоста он будет содержать запись типа А (тем не менее, если сервер имен не является полномочным, он может содержать запись типа А для данного хоста в кэш-памяти); в противном случае сервер имен содержит запись типа NS с информацией о домене, включающем имя хоста, а также запись типа А с IP-адресом сервера имен, указанного в поле Value записи типа NS. Предположим, к примеру, что корневой сервер имен не является полномочным для хоста gaia. cs. umass. edu. В этом случае корневой сервер будет содержать запись о домене, включающем хост cs. umass. edu (umass. edu. dns, umass. edu, NS), и запись, связывающую имя сервера имен dns. umass. edu с его IP-адресом (dns. umass. edu, 128.119.40.111, А).

4. DNS – сообщения

В этом разделе мы столкнулись с понятиями DNS-запроса и DNS-ответа. Запрос и ответ представляют собой единственные два типа сообщений, используемые протоколом DNS. Форматы этих сообщений совпадают и представлены на рис. 5.5. Ниже приведено описание структуры DNS-сообщения.

Рис. 5.5 Формат DNS-сообщения

□ Первые 12 байт составляют заголовочную секцию, состоящую из нескольких полей. Первое поле представляет собой 16-разрядное число, идентифицирующее запрос. Идентификатор запроса копируется в ответное сообщение, что позволяет клиенту сопоставлять ответы с запросами. Поле флагов включает одноразрядный флаг «запрос/ответ» и определяет, является ли сообщение запросом (0) или ответом (1). Одноразрядный флаг полномочности устанавливается для ответного сообщения в случае, если сервер имен является полномочным для запрашиваемого имени.

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