Принципы работы DNS

Сегодня мы рассмотрим основные понятия и принципы построения и реализации DNS.

В качестве основного механизма адресации в Internet используются IP-адреса. Однако запоминать эти комбинации из четырех цифр не очень удобно. Пока Internet был маленьким, обходились простым назначением каждому IP-адресу текстового имени и хранили это соответствие в файлах с именем hosts. Архив internic поддерживал такой файл централизованно, и каждый администратор машины, включенной в Сеть, мог его скопировать.

Но Internet рос, и размеры файла соответствий росли вместе с сетью. Появилась потребность в создании информационной службы, которая поддерживала бы соответствия между IP-адресами и именами. В настоящее время таким единым средством именования ресурсов сети стала Berkeley Internet Name Domain, или просто BIND. В большинстве Unix-систем в качестве реализации BIND используется программа named.

Как и любой другой сервис прикладного уровня, а система доменных имен - это сервис прикладного уровня, named использует транспорт TCP и UDP (порты 53). Очень часто пользователи сообщают администратору системы, что та или иная машина системе неизвестна, хотя вчера с ней можно было работать. При этом, как правило, называют доменные имена компьютеров.

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

Сервис BIND строится в соответствии с архитектурой клиент-сервер. В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера, в нашем случае, программа named.

Resolver, собственно, не является какой-либо программой. Это набор процедур из системной библиотеки (libc.a), которые позволяют прикладной программе, "собранной" с ними, получать по доменному имени IP-адрес компьютера или по IP-адресу доменное имя. Сами эти процедуры обращаются к системному компоненту resolver, который ведет диалог с сервером доменных имен и таким образом обслуживает запросы прикладных программ пользователя. На запросы описанных выше функций в системах Unix отвечает программа named. Идея этой программы проста - обеспечить разрешение как "прямых" запросов, когда по имени ищут адрес, так и "обратных", когда по адресу ищут имя. Управляется named специальной базой данных, которая состоит из нескольких файлов, и содержит соответствия между адресами и именами, а также адреса других серверов BIND, к которым данный сервер может обращаться в процессе поиска имени или адреса.

Общую схему взаимодействия различных компонентов BIND можно изобразить так, как это представлено на рисунке 1.

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

Шаг 1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера.

Шаг 2. Местный сервер сообщает прикладной программе IP-адрес запрошенного имени.

Для того чтобы более четко прояснить данную схему взаимодействия, рассмотрим несколько примеров, когда появляется запрос на получение IP-адреса по доменному имени. При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:

/usr/paul>telnet polyn.net.kiae.su 

получаем в ответ:

/usr/paul>telnet polyn.net.kiae.su 

trying 144.206.130.137 ... 

login: 

..... 

Строчка, в которой указан IP-адрес компьютера polyn.net. kiae.su, показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен, и прикладная программа, в данном случае telnet, получила на свой запрос IP-адрес. Таким образом, после ввода команды с консоли и до появления IP-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него. Довольно часто бывает, что после ввода команды приходится долго ждать ответа удаленной машины, но зато после первого ответа удаленный компьютер начинает реагировать на команды с такой же скоростью, как и ваш собственный. В данном случае в задержке скорее всего виновата служба доменных имен. Ярче всего такой эффект проявляется при использовании программы ftp. Например, после ввода команды:

/usr/paul>ftp ftp.funet.fi 

система долго не отвечает, но затем начинает быстро "сглатывать" и идентификатор ftp, и почтовый адрес пользователя (анонимный пользователь), и другие ftp-команды. Аналогичный пример - программа traceroute. Здесь задержка на запросы к серверу доменных имен проявляется в том, что указанное в отчете время ответов со шлюзов, на которых "умирают" ICMP-пакеты, маленькое, а задержки с отображением каждой строчки отчета довольно большие. В системе Windows 3.1 некоторые программы трассировки показывают сначала IP-адрес шлюза, а только потом, после разрешения "обратного" запроса, заменяют его на доменное имя шлюза.

Если сервис доменных имен работает быстро, то эта подмена практически незаметна, если же он работает медленно, то промежутки бывают довольно значительными. В примере с telnet и ftp мы рассматривали только "прямые" запросы к серверу доменных имен, а в примере с traceroute впервые упомянули "обратные" запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес. Следует заметить, что скорость разрешения "прямых" и "обратных" запросов, вообще говоря, разная. Все зависит от того, как описаны "прямые" и "обратные" зоны в базах данных серверов доменных имен, обслуживающих домен. Часто прямая зона бывает одна, а вот обратных зон может быть несколько в силу того, что домен расположен на физически разных сетях или подсетях. В этом случае время разрешения "обратных" запросов будет больше времени разрешения "прямых" запросов. Более подробно этого вопроса мы коснемся при обсуждении файлов конфигурации программы named. Процедура разрешения "обратных" запросов точно такая же, как процедура разрешения "прямых" запросов, описанная выше. Собственно нерекурсивным рассмотренный выше запрос можно назвать только с точки зрения сервера, т.е. программы named. С точки зрения resolver, процедура разрешения запроса является рекурсивной, так как resolver перепоручил named заниматься поиском нужного сервера доменных имен. Согласно RFC-1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы. Во многих Unix-системах именно так и происходит. В этом случае resolver обращается к локальному серверу доменных имен, получает от него адрес одного из серверов домена root, опрашивает сервер домена root, получает от него адрес удаленного сервера нужной зоны, опрашивает этот удаленный сервер и получает IP-адрес, если он посылал так называемый "прямой" запрос.

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

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

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

В общем виде такая схема будет выглядеть следующим образом:

Шаг 1. Прикладная программа обращается к местному серверу доменных имен за IP- адресом, сообщая ему доменное имя.

Шаг 2. Сервер определяет, что адрес не входит в данный домен и обращается за адресом сервера запрашиваемого домена к корневому серверу доменных имен.

Шаг 3. Корневой сервер доменных имен сообщает местному серверу доменных имен адрес сервера доменных имен требуемого домена.

Шаг 4. Местный сервер доменных имен запрашивает удаленный сервер на предмет разрешения запроса своего клиента (прикладной программы)

Шаг 5. Удаленный сервер сообщает IP-адрес местному серверу.

Шаг 6. Местный сервер сообщает IP-адрес прикладной программе.

Среди приведенных примеров случай обращения к финскому ftp-архиву как раз и является иллюстрацией такой многоступенчатой схемы разрешения "прямого" запроса.

Однако не всегда при разрешении запросов местный сервер обращается к корневому серверу. Дело в том, что, как указывает Крег Ричмонд, существует разница между доменом и зоной. Домен - это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su, относятся к домену kiae.su. Сам домен разбивается на поддомены или, как их еще называют, зоны. У каждой зоны может быть свой собственный сервер доменных имен. Разбиение домена на зоны и организация сервера для каждой из зон называется делегированием прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

При настройке сервера в его файлах конфигурации можно непосредственно указав адреса серверов зон. В этом случае обращения к корневому серверу не производятся, так как местный сервер сам "знает" адреса удаленных серверов зон. Естественно, что все это относится к серверу, который делегирует права. Существует еще и другой вариант работы сервера, когда он не запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен. Это происходит, когда незадолго до того сервер уже разрешал задачу получения IP-адреса по данному доменному имени. Если требуется получить IP-адрес, то он будет просто извлечен из буфера сервера, так как в течение определенного времени, заданного в конфигурации сервера, этот адрес будет храниться в кэш-памяти сервера. Если нужен адрес из того же домена, который был указан в одном из имен, которые разрешались раньше, то сервер не будет обращаться к корневому серверу, поскольку адрес удаленного сервера для этого домена также хранится в cache местного сервера.

В сущности, понятия "зона" и "домен" носят локальный характер и отражают только тот факт, что при настройках и взаимодействии между собой серверы доменных имен исходят из двухуровневой иерархии. Это значит, что если в зоне необходимо создать разделение на группы, то зону можно назвать доменом, и в нем организовать новые зоны. Например, у компании Sun Microsystems есть зона russia в домене sun.com (russia.sun. com). Так вот эту зону тоже можно разбить на зоны, например info.russia.sun.com и market.russia.sun.com1.

Кроме нерекурсивной процедуры разрешения имен, возможна еще и рекурсивная процедура. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим эти два случая более подробно. На рисунке 4 продемонстрирована нерекурсивная процедура разрешения IP-адреса по доменном имени. Основная нагрузка в этом случае ложится на местный сервер доменных имен, который осуществляет опрос всех остальных серверов. Для того чтобы сократить число таких обменов, можно разрешить кэширование адресов (если, конечно, позволяет объем оперативной памяти). В этом случае число обменов с удаленными серверами сократится. На рисунке 5 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена, используя при этом нерекурсивный опрос своих серверов поддоменов.

При этом локальный сервер сразу получает от удаленного адрес хоста, а не адреса серверов поддоменов. Последний способ получения адреса называют рекурсивным, т.е. локальный и удаленный серверы взаимодействуют по рекурсивной схеме, а удаленный сервер и серверы поддоменов по нерекурсивной.

Таковы в общем виде принципы работы системы доменных имен в Internet. Совершенно очевидно, что от того, насколько быстро работает эта система, зависят многие другие информационные услуги сети, например, World Wide Web. Если ответ от сервера не приходит за отведенное клиентом Web время, то пользователь получит отказ при доступе к серверу по доменному имени.