Библиотека Интернет Индустрии I2R.ru

BIND или Berkeley Internet Name Domain - это сервер доменных имен реализованный в университете Беркли, который широко применяется на Intenet'е. Он обеспечивает поиск доменных имен и IP-адресов для любого узла Сети. BIND обеспечивает рассылку сообщений электронной почты через узлы Internet. Если говорить более точно BIND обеспечивает поиск доменного адреса машины пользователя, которому адресована почта, и определение IP-адреса доменному адресу. Эта информация используется программой рассылки почтовых сообщений sendmail, которая выступает в качестве почтового сервера.

BIND реализован по схеме "клиент/сервер". Собственно BIND - это сервер, а функции клиента выполняет name resolver или просто resolver. Обычно, модули resolver'а находятся в библиотеке libc.a, если речь идет о системе UNIX, и редактируются вместе с программой, использующей вызовы gethostbyname и gethostbyaddr. Как уже отмечалось, базовым понятием для BIND является "домен". На рисунке 3.3 представлена схема описания системы доменов.

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

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

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

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

Resolver, собственно, не является какой-либо программой. Это набор процедур из системной библиотеки (libс.a), которые позволяют прикладной программе, отредактированной с ними, получать по доменному имени IP-адрес компьютера или по IP-адресу доменное имя. Сами эти процедуры обращаются к системной компоненте resolver, которая ведет диалог с сервером доменных имен и таким образом обслуживает запросы прикладных программ пользователя.

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

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

Опираясь на схему нерекурсивной процедуры разрешения имени (рисунок 3.5) рассмотрим два способа разрешения запроса на получение 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. Например, при обращении к финскому архиву ftp.funet.fi, после ввода команды:

/usr/paul>ftp ftp.funet.fi

система долго не отвечает, но затем начинает быстро "сглатывать" и идентификатор и почтовый адрес, если входят как анонимный пользователь, и другие FTP-команды.

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

Если в примере с telnet и ftp мы рассматривали, только "прямые" запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули "обратные" запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

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

Процедура разрешения "обратных" запросов точно такая же, как и процедура разрешения "прямых" запросов, описанная выше.

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

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

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

1. поиск ответа в локальном кэше;
2. поиск ответа на локальном сервере;
3. поиск информации в сети.

При чем кэш может быть как у resolver'а, так и у сервера, но чаще всего эти временные хранилища информации о системе DNS объединяют.

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

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

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.com.

Кроме нерекурсивной процедуры разрешения имен возможна еще и рекурсивная процедура разрешения имен. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим эти два случая более подробно.

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

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

Нерекурсивная обработка запроса на получение IP-адреса

Рекурсивная и нерекурсивная процедуры разрешения адреса по IP-имени

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