Схема функционирования DNS

Ниже мы опишем основную схему функционирования DNS. Основным предметом рассмотрения для нас будет являться преобразование имени хоста в соответствующий IP-адрес.

Предположим, что некоторому приложению (web-браузеру или программе чтения электронной почты), выполняющемуся на хосте пользователя, необходимо получить IP-адрес удаленного хоста. Приложение вызывает клиентскую сторону DNS и передает ей имя нужного хоста. (Многие UNIX-машины поддерживают функцию gethostbyname(), вызываемую приложениями для получения IP-адреса. В разделе «Программирование UDP-сокетов» этой главы мы покажем, каким образом Java-приложение может обратиться к службе DNS.) Клиентская сторона, в свою очередь, создает запрос, отсылает его DNS-серверу и ждет ответа. Как правило, время ответа DNS-сервера составляет от нескольких миллисекунд до десятков секунд. Ответ представляет собой сообщение, содержащее группу из одного или нескольких IP-адресов, которые передаются DNS-клиентом вызвавшему его приложению. Таким образом, с точки зрения приложения служба DNS является «черным ящиком», на входе которого находится имя удаленного хоста, а на выходе — его IP-адрес. На самом деле этот «черный ящик» представляет собой сложную систему, состоящую из множества серверов имен, распределенных по всему земному шару, и протокола, определяющего взаимодействие между серверами имен и пользовательскими хостами.

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

□ Единственная точка возможного отказа. Сервер имен является «узким местом» с точки зрения надежности — его отказ парализует работу всего Интернета.

□ Объем трафика. Сервер имен является «узким местом» с точки зрения загрузки, поскольку вынужден обрабатывать все запросы, поступающие с сотен миллионов хостов всего мира.

□ Удаленность централизованной базы данных. Единственный сервер невозможно расположить на приемлемом расстоянии от всех клиентов. Например, разместив сервер в Нью-Йорке, мы обеспечим хосты Австралии гарантированными задержками, связанными с передачей сигнала по линиям связи, далеко не всегда высокоскоростным.

□ Обслуживание. База данных сервера должна не только хранить адреса всех существующих хостов, но и постоянно обновляться с появлением новых хостов. Это влечет за собой проблемы, связанные с авторизацией и идентификацией каждого пользователя сети, пытающегося внести данные о своем хосте в центральную базу данных.

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

Для того чтобы решить проблему хранения больших объемов информации, система DNS была спроектирована в виде совокупности многочисленных серверов имен, рассредоточенных по всему миру и организованных в виде иерархической структуры. Ни один сервер имен не содержит информации обо всех IP-адресах хостов; эта информация распределена между множеством серверов. Можно ввести следующую укрупненную классификацию серверов имен: локальные, корневые и полномочные. Ниже описаны механизмы взаимодействия этих серверов друг с другом и с пользовательскими хостами.

□ Локальные серверы имен имеются у каждого Интернет-провайдера (локальные серверы имен также называют серверами имен по умолчанию). Когда пользовательский хост посылает DNS-запрос, этот запрос сначала попадает на локальный сервер имен. Обычно IP-адрес локального сервера имен конфигурируется пользователем вручную, например, в операционной системе Windows для этого необходимо открыть Панель управления (Control Panel), щелкнуть на значке Сеть (Network), в списке установленных компонентов открывшегося окна выделить пункт TCP/IP и, щелкнув на кнопке Свойства (Properties), в появившемся диалоговом окне перейти на вкладку Конфигурация DNS (DNS Configuration). Обычно локальный сервер имен расположен на относительно небольшом расстоянии от пользовательского хоста. В случае, если Интернет-провайдером является государственное или коммерческое учреждение, сервер имен принадлежит локальной сети организации; для резидентных Интернет-провайдеров сервер имен обычно отделен от пользователя не более чем несколькими маршрутизаторами. Если окажется, что удаленный хост принадлежит тому же Интернет-провайдеру, локальный сервер самостоятельно проведет преобразование, и требуемый IP-адрес будет отослан пользовательскому хосту. Подобная ситуация, например, будет иметь место, когда хост _surf.eurecom.fr затребует IP-адрес _baie.eurecom.fr. В этом случае IP-адрес выдается локальным сервером имен института Eurecom.

□ Корневые серверы имен являются следующей ступенью в иерархии серверов DNS. Их число в Интернете составляет немногим более десятка, и большинство из них находится в Северной Америке. Рисунок 2.13 иллюстрирует положение корневых серверов имен на географической карте мира в феврале 2002 года. В случае, если локальный сервер имен не может самостоятельно удовлетворить запрос пользовательского хоста, он берет на себя роль клиента и передает запрос одному из корневых серверов имен. Корневой сервер обрабатывает запрос и при наличии соответствующей записи в базе данных отсылает локальному серверу ответ, содержащий IP-адрес, который, в свою очередь, передается локальным сервером пользовательскому хосту. Тем не менее корневой сервер имен не всегда может выполнить запрос из-за ограниченности своей базы данных. В случае, если хост не найден в базе данных, локальному серверу отсылается IP-адрес полномочного сервера имен, который располагает искомым IP-адресом.

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

Рассмотрим простой пример. Предположим, что хост _surf.eurecom.fr создал запрос IP-адреса _gaia.cs.umass.edu. Пусть локальный сервер имен института Eurecom имеет имя _dns.eurecom.fr, а полномочный сервер имен хоста _gaia.cs.umass.edu — имя _dns.umass.edu. Как показано на рис. 2.14, хост _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-сообщений: трех запросов и трех ответов.
Выше было сделано допущение о том, что корневой сервер имен располагает IP-адресами полномочных серверов для любого хоста. На самом деле это допущение неверно. Корневой сервер «знает» адрес лишь промежуточного сервера имен, который содержит IP-адрес полномочного сервера хоста. Для того чтобы проиллюстрировать это, снова обратимся к примеру с хостом surf.eurecom.fr, желающим получить IP-адрес хоста _gaia.cs.umass.edu. Предположим, что локальный сервер имен университета Массачусетс имеет имя dns.umass.edu. Допустим также, что каждое подразделение университета располагает собственным локальным сервером имен, являющимся полномочным для всех хостов соответствующего подразделения. Как показано на рис. 2.15, когда корневой сервер имен получает запрос с именем, оканчивающимся на 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-адреса.

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

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

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