Числовая адресация удобна для машинной обработки таблиц маршрутов, но совершенно не приемлема для использования ее человеком. Запомнить наборы цифр гораздо труднее, чем мнемонические осмысленные имена. Для облегчения взаимодействия в Сети сначала стали использовать таблицы соответствия числовых адресов именам машин. Эти таблицы сохранились до сих пор и используются многими прикладными программами. Некоторое время даже существовало центральное хранилище соответствий, которое можно было по FTP скачать на свою машину из ftp.internic.net. Это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид:
| IP-адрес | имя машины | синонимы |
| 127.0.0.1 | localhost | localhost |
| 144.206.160.32 | Polyn | polyn |
| 144.206.160.40 | Apollo | www |
Рис. 3.1. Пример таблицы имен хостов (файл /etc/hosts)
Конечно, в машине этот файл записывается не в виде таблицы, а следующим образом:
Пример 1. Содержание файла /etc/hosts
127.0.0.1 localhost 144.206.130.137 polyn Polyn polyn.net.kiae.su polynm.kiae.su 144.206.160.32 polyn Polyn polyn.net.kiae.su polyn.kiae.su 144.206.160.40 apollo Apollo www.polyn.kiae.su
Последний столбец в этой таблице является необязательным. Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). Как видно из примера, синонимов может быть много, и, кроме того для разных IP-адресов может быть указано одно и то же имя.
Обращения, приведенные ниже, приводят к одному и тому же результату - инициированию сеанса telnet с машиной Apollo:
telnet 144.206.160.40 или telnet Apollo или telnet www
В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы от различных клонов Unix до Windows NT поддерживают эту систему соответствия IP-адресов доменным именам.
Однако такой способ присвоения символьных имен был хорош до тех пор, пока Internet был маленьким. По мере роста сети стало затруднительным держать большие списки имен на каждом компьютере. Для того, что бы решить эту проблему, были придуманы DNS (Domain Name System).
3.1.1. Принципы организации DNS
Любая DNS является прикладным процессом, который работает над стеком TCP/IP. Таким образом, базовым элементом адресации является IP-адрес, а доменная адресация выполняет роль сервиса. Правда о том, что DNS - это прикладная задача в полном смысле этого слова приходится говорить с определенными оговорками. DNS - это информационный сервис Internet, и, следовательно, протоколы его реализующие относятся к протоколам прикладного уровня согласно стандартной модели OSI. Однако с точки зрения операционной системы поддержка DNS может входить в нее как компонента ядра, которая прикладным пользовательским процессом не является. Пользовательские программы общаются с ней при помощи системных вызовов. Такое положение вещей справедливо практически для всех Unix-систем. Другое дело системы на базе MS-DOS и Windows 3.x. В этих системах DNS (точнее ее клиентская часть) реализована как прикладная программа.
Система доменных адресов строится по иерархическому принципу. Однако иерархия эта не строгая. Фактически, нет единого корня всех доменов Internet. Если быть более точным, то такой корень в модели DNS есть. Он так и называется "ROOT". Однако, единого администрирования этого корня нет. Администрирование начинается с доменов верхнего, или первого, уровня. В 80-е годы были определены первые домены этого уровня: gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа: uk, jp, au, ch, и т.п. Для СССР также был выделен домен su. После 1991 года, когда республики союза стали суверенными, многие из них получили свои собственные домены: ua, ru, la, li, и т.п. Однако Internet не СССР, и просто так выбросить домен su из сервера имен нельзя, на основе доменных имен строятся адреса электронной почты и доступ ко многим другим информационным ресурсам Internet. Поэтому гораздо проще оказалось ввести новый домен к существующему, чем заменить его. Таким образом в Москве существуют организации с доменными именами, оканчивающимися на su (например, kiae.su) и оканчивающимися на ru (msk.ru).
Если быть более точным, то новых имен с расширением su в настоящее время ни один провайдер не выделяет. Более того идет планомерная замена имен. Выявляются зарубежные информационные источники, и их администрация оповещается о замене доменных имен, после соответствующего подтверждения происходит удаление имени с расширением su.
Вслед за доменами верхнего уровня следуют домены, определяющие либо регионы (msk), либо организации (kiae). В настоящее время практически любая организация может получить свой собственный домен второго уровня. Для этого только надо направить заявку провайдеру и получить уведомление о регистрации (см. раздел 3.1.3). Далее идут следующие уровни иерархии, которые могут быть закреплены либо за небольшими организациями, либо за подразделениями больших организаций.
Всю систему доменной адресации можно представить следующим образом (рисунок 3.2):
Рис. 3.2. Пример дерева доменной адресации
Наиболее популярной программой поддержки DNS является named, которая реализует Berkeley Internet Name Domain (BIND). Но эта программа не единственная. Так в системе Windows NT 4.0 есть свой сервер доменных имен, который поддерживает спецификацию BIND. Определена в документе RFC 1033-1035.
3.1.2. BIND (Berkeley Internet Name Domain)
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 представлена схема описания системы доменов.
Рис. 3.3. Схема доменной адресации
На рисунке домены изображены в виде кругов. Каждый круг соответствует множеству компьютеров, которые образуют домен. Вложенные круги - это поддомены, которые, в свою очередь тоже могут быть разбиты на поддомены и т.д. При отображении этой структуры в доменные имена получается иерархия имен узлов сети.
Однако разговоры об архитектуре сервиса доменных имен и различных его реализаций совершенно беспочвенны, если только не иметь своего собственного домена. Ведь проблемы с администрированием возникают только в этом случае. В следующем разделе рассказано о том, как его получить.
3.1.3. Регистрация доменных имен
Для того, чтобы получить зону надо отправить заявку в РосНИИРОС, который отвечает за делегирование поддоменов в пределах домена ru. В заявке указывается адрес компьютера-сервера доменных имен, почтовый адрес администратора сервера, адрес организации и ряд другой информации. Разберем эту заявку на примере заявки Международной лаборатории VEGA.
domain: vega.ru descr: International Agency VEGA descr: Kurchatov sq. 1 descr: 115470 Moscow descr: Russian Federation admin-c: Pavel B Khramtsov zone-c: Pavel B Khramtsov tech-c: Pavel B Khramtsov nserver: vega-gw.vega.ru nserver: ns.relarn.ru nserver: polyn.net.kiae.su dom-net: 194.226.43.0 changed: paul@kiae.su 961018 source: RIPN person: Pavel B Khramtsov address: International Agency Vega address: Kurchatov sq. 1 address: 115470 Moscow address: Russian Federation phone: +7 095 1969124 fax-no: +7 095 9393670 e-mail: paul@kiae.su changed: paul@kiae.su 961018 source: RIPN
При заполнении этой заявки следует иметь в виду, что она будет обрабатываться роботом автоматом. Этот автомат проверяет ее на наличие ошибок заполнения и противоречия с существующей базой данных делегированных доменов. Так как робот не терпит неточностей и глух к различного рода просьбам, то заполнять заявку следует аккуратно. Автомат обрабатывает заявку, выделяет в ней записи для базы данных регистрации доменов. Сами эти записи состоят из полей. Каждое поле идентифицируется в заявке именем поля, после которого ставится символ ":".
В строке описания поля "domain:" указывается имя домена, которое вы просите зарегистрировать. РосНИИРОС регистрирует только поддомены домена ru. Регистрировать следует как "прямую" зону, так и "обратную"(см. раздел 3.1.4). В нашем случае это просто зона 43.226.194.inaddr.arpa.
В строке описания поля "descr:" указывают название и адрес организации, которая запрашивает домен. Так как на одной строке эта информация не может разместиться, то команд descr может быть несколько.
В строке описания поля "admin-c:" указывается персона, которая осуществляет администрирование домена. Поле имеет обязательный формат: <имя> <первая буква отчества> <фамилия>. Таких строк может быть несколько, если лиц отвечающих за администрирование домена больше одного. Вместо указанного выше формата можно использовать также и идентификатор персоны, если таковой имеется. Идентификатор называют nichandle, или персональный код.
Поле "zone-c:" заполняется для той персоны, чей почтовый адрес указан в записи SOA в описании зоны. Формат этого поля идентичен формату команды admin-c.
Поле "tech-c:" указывается для технического администратора домена, к которому обращаются в случае экстренных ситуаций. Формат этого поля совпадает с форматом команды admin-c. По моему глубокому убеждению во всех полях (admin-c, zone-c и tech-c) имеет смысл указывать координаты одного и того же человека. Мало кто из российских пользователей Internet может позволить роскошь держать сразу трех разных специалистов на обслуживании сервиса доменных имен. Учитывая отечественные реалии, можно со всей ответственностью утверждать, что кроме неразберихи ни к чему другому большое количество администраторов не приводит.
В строке описания поля "nserver:" указывают доменные имена серверов зоны. Как правило, таких строк в заявке бывает несколько. Первым указывается primary или главный сервер домена. В нашем случае это vega-gw.vega.ru. На этом сервере хранится база данных домена. Вторым указывается secondary или дублирующий сервер домена. В нашем случае это ns.relarn.ru. Дублирующие сервера призваны повысить надежность работы всей системы доменных имен, поэтому дублирующих серверов может быть несколько. Если существуют другие дублирующие сервера, то указываются и они (сервер polyn.net.kiae.su из нашей заявки также является дублирующим для домена vega.ru). При указании дублирующих серверов первым следует указывать тот, который наиболее надежно обслуживает запросы к домену. В нашем примере таким является сервер ns.relarn.ru. Выбран он был по тем соображениям, что регистрация проводилась в РосНИИРОС, специалисты которого администрируют домен relarn.ru. Первоначально, дублирующим сервером был только сервер polyn.net.kiae.su. Однако, медленная скорость разрешения доменных имен в домене kiae.su всем хорошо известна. Это приводит к достаточно большим задержкам при ответах на запросы на расширение имени. Особенно долго обрабатываются обратные запросы. В результате, автомат постоянно выдавал сообщение что сервер polyn.net.kiae.su недоступен, хотя при ручном тестировании все работало нормально. Для того, чтобы решить эту проблему было решено просить разрешения на использование ns.relarn.ru в качестве secondary сервера для домена vega.ru, справедливо полагая, что сервер доменных имен расположенный в том же домене, что и автомат, и сервер установленный на машине, использующий общий коаксиальный кабель с машиной автомата, будет отвечать гораздо оперативнее сервера, расположенного в другом домене, за несколькими репитерами и мостами. При выборе места размещения дублирующих серверов следует иметь в виду, что сначала проверяется возможность взаимодействия именно с этими серверами. Если хотя бы один из них не откликается на запросы автомата, то заявка отклоняется.
Поле "sub-dom:" описывает поддомены домена. В нашей заявке нет поля sub-net, т.к. в домене vega.ru нет поддоменов. Но если бы нам понадобилось изменять структуру домена, а именно, разбить его на зоны, то тогда следовало бы включить в заявку между строками nserver и строкой dom-net строку:
sub-net: zone1 zone2
В этом случае весь домен vega.ru разбит на два поддомена: zone1 и zone2. Например, машина quest из зоны zone1 будет иметь доменное имя quest.zone1.vega.ru, а машина query из зоны zone2 - query.zone2.vega.ru. Поддомены указываются в команде sub-dom через пробел.
Поле "dom-net:" указывает на список IP-сетей данного домена. В нашей заявке указана только одна сеть 194.226.43.0, но если у организации, которая заводит свой собственный домен имеется в наличии несколько сетей, то эти сети можно указать в этом поле, разделяя их пробелами.
Поле "changed:" является обязательным и служит указателем на то лицо, которое последним вносило изменения в заявку. В качестве значения поля после символа ":" указывается почтовый адрес этого лица и, через пробел дата внесения изменения в формате ГГММДД (Г-год, М-месяц, Д-день).
Последняя запись в заявке - это поле source, которое отделяет различные записи во входном потоке данных программы робота. Значение этого поля - RIPN.
Вслед за записью заявки следует запись описания персоны. Именно эта запись позволяет связывать поля admin-c, zone-c, tech-c с информацией о конкретном лице, которая содержится в записи описания персоны.
Запись описания персоны начинается с поля "person:". В данном поле указывается информация о лице (персоне). Обычно, данное поле имеет следующий формат: <имя> <первая буква отчества> <фамилия>.
Поле "address:" вслед за полем "person:". Данное поле состоит из нескольких строк, каждая из которых начинается с имени поля. Первым указывается организация, во второй строке - улица и номер дома, в третьей - почтовый индекс и название города или поселка, в последней строке - название страны. Одним словом - это типичный американский почтовый адрес.
За адресом следует поле "phone:". В нем указывается номер телефона, по которому можно связаться с указанным лицом. Номер задается с указанием номера страны и кода города. Для Москвы - +7 095 ___ __ __. Телефонов можно указать несколько.
Все выше сказанное для поля "phone:" относится и к полю "fax-no:". В этом поле указывается номер телефакса.
Самым важным, на мой взгляд, из всех полей, определяющих координаты персоны, является поле адреса электронной почты - "e-mail:", хотя оно и не является обязательным полем заявки. Адрес электронной почты указывается как адрес электронной почты Internet. Для абонентов других сетей возможны проблемы с регистрацией их адресов, т.к. указание символов "!", "%", "::" нежелательно.
В поле "nic-hdl:" указывается персональный номер пользователя, если он у данного пользователя есть. Поле не является обязательным, но, как подчеркивается в инструкции по заполнению заявок "крайне желательно".
Последним полем в описании персоны, как и в заявке на домен, является поле "source:". В заявке можно указать несколько персон, что породит для каждой из них свою собственную запись в базе данных описания доменов. Информация о зоне и лицах, которые ответственны за ведение зоны (и не только о них) можно найти по команде:
/usr/paul>whois -h whois.ripn.net <имя зоны или персоны>
Теперь после описания самой заявки перейдем к описанию ее регистрации. После того как заявка отправлена, следует настроить и запустить сервер в локальном режиме. Администратор РосНИИРОС обычно извещает о том, что у администрации домена ru нет претензий к вашей заявке и разрешает запустить ваш сервер для тестирования. Если в домене есть уже запрашиваемый вами поддомен или у администрации домена ru есть другие возражения по поводу регистрации вашего домена, то администрация домена ru вас об этом известит.
Если у администратора домена ru нет причин для отказа в регистрации, то он разрешает запуск сервера для тестирования. Если ваш сервер уже запущен, то это сообщение вы просто примете к сведению, если нет, то нужно срочно, обычно в течении 2-х часов настроить и запустить сервер (вообще-то, запускать надо сразу как только решили отправлять заявку).
Еще раз обратите внимание на то, что заявка, отправленная на адрес ru-dns@RIPN.net попадает на автомат обработки заявок, с которым бесполезно вступать в пререкания и прения по поводу различного рода ошибок и неточностей. При этом проблемы с регистрацией могут возникать как по вине заявителя (ошибки в полях заявки, например), так и по вине регистрирующей стороны. Так, например, регистрация домена vega.ru длилась почти два месяца из-за того, что в начале были ошибки в заявке, потом были выявлены несоответствия заявки и описания зоны, затем сломался автомат регистрации и заявка была утеряна. Затем возникли проблемы с дублирующим сервером зоны (слишком большое время отклика, из-за которого автомат отклонял заявку). При этом и сам автомат работал медленно, т.к. проблема скорости разрешения запросов на серверах имен РНЦ "Курчатовский Институт" хорошо всем известна. Поэтому лучше всего сразу узнать телефон администратора и общаться с ним непосредственно.
Именно "телефон", и об этом упоминается не случайно. Общение с администраторами по электронной почте ни к чему хорошему, в большинстве случаев, не приводит. Как правило, вы будете получать назад ваши же письма откомментированные администратором, который в момент отправки этого письма мгновенно забывает о ваших проблемах. Вообще, вся эта переписка напоминает разговор двух склеротиков, когда строк типа: "В письме от такого-то числа пользователь написал..." становится больше, чем содержательной информации. Выискивать в большом письме комментарии, которые могут занимать не больше двух слов трудно и нудно. Особенно глупо это выглядит если вы, того не ведая, вступите в переписку с автоматом. Я никому не хочу навязывать правила поведения в сети, но должны же существовать какие-то нормы, обусловленные здравым смыслом.
При размещении сервера домена следует позаботиться о том, чтобы существовал вторичный (secondary) сервер имен вашего домена. Согласно большинству рекомендаций, следует иметь от 2-х до 4-х серверов на случай отказа основного сервера доменных имен.
Вообще говоря, можно вести переговоры о создании вторичного сервера доменных имен и с самим РосНИИРОС и с любым провайдером. Но за услуги последнего придется заплатить. Можно запустить вторичный сервер и на одном из своих компьютеров, но в этом случае вы просто выполните требования РосНИИРОС формально, так как надежности процедуре разрешения имен вашего домена такое решение не принесет.
Рис.3.4. Схема подключения локальной сети к провайдеру
Действительно, если ваша сеть подключена к провайдеру через один единственный шлюз (рисунок 3.4), то все ваши компьютеры, оказываются за шлюзом. При отказе шлюза все они для внешнего пользователя сети исчезают, а это значит, что если сервер доменных имен расположен на шлюзе или одном из компьютеров вашей сети, то для внешнего пользователя и их имена исчезнут также, в отличии от IP-адресов, которые прописаны в маршрутизаторе провайдера.
На первый взгляд кажется, что если нет доступа, то и трансляция доменных имен в IP-адресе не нужна. Однако, это не совсем так. Если система не может разрешить доменное имя, то она сообщает - "unknown host", т.е. система такого компьютера не знает. Если же доменное имя успешно транслируется в IP-адрес, то, в случае потери связи, система сообщает - "host un-reachable", т.е. система знает о такой машине, но в данный момент достичь эту машину нет никакой возможности.
В критических ситуациях не всегда можно быстро сообразить, что происходит в сети, поэтому разница в сообщениях важна - она позволяет избежать лишних непродуманных действий.
В РосНИИРОС регистрируют не только "прямую" зону, но также и "обратную". Это две самостоятельные заявки. Понятие "прямая" зона - это калька с английского - forward zone, а понятие "обратная" зона - reverse zone. "Прямая" зона определяет соответствие доменного имени IP-адресу, в то время, как "обратная" зона определяет обратное соответствие IP-адреса доменному имени.
В данном разделе речь пойдет о программе, которая называется named. Именно она используется в большинстве Unix-систем в качестве реализации Berkeley Internet Name Domain - BIND.
Как и любой другой сервис прикладного уровня, а система доменных имен - это сервис прикладного уровня, программа named использует транспорт TCP и UDP (порты 53). Очень часто пользователи сообщают администратору системы, что та или иная машина системе не известна, хотя вчера с ней можно было работать. При этом, как правило, называют доменные имена компьютеров. Первое, что следует проверить в этой ситуации - реальную доступность к компьютеру по его IP-адресу. Проблема действительно является серьезной, если и по IP-адресу нельзя "достучаться" до удаленной машины, в противном случае следует искать ошибки или отказы в работе сервиса доменных имен.
Сервис BIND строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера, в нашем случае, программа named.
Resolver, собственно, не является какой-либо программой. Это набор процедур из системной библиотеки (libс.a), которые позволяют прикладной программе, отредактированной с ними, получать по доменному имени IP-адрес компьютера или по IP-адресу доменное имя. Сами эти процедуры обращаются к системной компоненте resolver, которая ведет диалог с сервером доменных имен и таким образом обслуживает запросы прикладных программ пользователя.
На запросы описанных выше функций в системах Unix отвечает программа named. Идея этой программы проста - обеспечить как разрешение, так называемых, "прямых" запросов, когда по имени ищут адрес, так и "обратных", когда по адресу ищут имя. Управляется named специальной базой данных, которая состоит из нескольких фалов, и содержит соответствия между адресами и именами, а также адреса других серверов BIND, к которым данный сервер может обращаться в процессе поиска имени или адреса.
Общую схему взаимодействия различных компонентов BIND можно изобразить так, как это представлено на рисунке 3.5.
Рис. 3.5. Нерекурсивная процедура на разрешение имени
Опираясь на схему нерекурсивной процедуры разрешения имени (рисунок 3.5) рассмотрим два способа разрешения запроса на получение IP-адреса по доменному имени.
В первом случае будем рассматривать запрос на получение IP-адреса в рамках зоны ответственности данного местного сервера имен:
Для того, чтобы еще больше прояснить данную схему взаимодействия рассмотрим несколько примеров, когда появляется запрос на получение IP-адреса по доменному имени.
При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:
/usr/paul>telnet polyn.net.kiae.su
Строчка, в которой указан 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.
Процедура разрешения "обратных" запросов точно такая же, как и процедура разрешения "прямых" запросов, описанная выше.
Рис. 3.6. Нерекурсивный запрос resolver
Собственно нерекурсивным, рассмотренный выше запрос является только с точки зрения сервера, т.е. программы named. С точки зрения resolver процедура разрешения запроса является рекурсивной, так как resolver перепоручил named заниматься поиском нужного сервера доменных имен. Согласно RFC-1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы. Во многих Unix-системах именно так оно и сделано. В этом случае resolver обращается к локальному серверу доменных имен, получает от него адрес одного из серверов домена root, опрашивает сервер домена root, получает от него адрес удаленного сервера нужной зоны, опрашивает этот удаленный сервер и получает IP-адрес если он посылал, так называемый "прямой" запрос.
Как видно из этой схемы resolver сам нашел нужный IP-адрес. Однако чаще всего resolver не порождает нерекурсивных запросов, а переадресовывает их локальному серверу доменных имен. Кроме этого и локальный сервер и resolver не все запросы выполняют по указанной процедуре. Дело в том, что существует кэш, который используется для хранения в нем полученной от удаленного сервера информации (рисунок 3.7).
Рис. 3.7. Схема разрешения запросов с кэшированием ответов
Если пользователь обращается в течении короткого времени к одному и том же ресурсу сети, то запрос на удаленный сервер не отправляется, а информация ищется в кэше. Вообще говоря, прядок обработки запросов можно описать следующим образом:
При чем кэш может быть как у resolver'а, так и у сервера, но чаще всего эти временные хранилища информации о системе DNS объединяют.
Рассмотрим теперь нерекурсивный запрос прикладной программы к серверу доменных имен на получение IP-адреса по доменному имени из домена, который находится в ведении удаленного сервера доменных имен, т.е. сервера отличного от того, домену которого принадлежит компьютер, осуществляющий запрос. При рассмотрении этого запроса также будем опираться на схему с рисунка 3.5.
В общем виде такая схема будет выглядеть следующим образом:
Среди указанных выше примеров, пример обращения к финскому ftp-архиву как раз и является иллюстрацией такой много ступенчатой схемы разрешения "прямого" запроса.
Однако, не всегда при разрешении запросов местный сервер обращается к корневому серверу. Дело в том, что, как указывает Крэг Ричмонд, существует разница между доменом и зоной. Домен - это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Однако, сам домен разбивается на поддомены или, как их еще называют, зоны. У каждой зоны может быть свой собственный сервер доменных имен. Разбиение домена на зоны и организация сервера для каждой из зон называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.
При настройке сервера, в его файлах конфигурации можно непосредственно прописать адреса серверов зон. В этом случае обращения к корневому серверу не производятся, т.к. местный сервер сам знает адреса удаленных серверов зон. Естественно, что все это относится к серверу, который делегирует права.
Существует еще и другой вариант работы сервера, когда он не запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен. Это происходит тогда, когда незадолго до этого сервер уже разрешал задачу получения IP-адреса по данному доменному имени. Если требуется получить IP-адрес, то он будет просто извлечен из буфера сервера, т.к. в течении определенного времени, заданного в конфигурации сервера, этот адрес будет храниться в cache-сервере. Если нужен адрес из того же домена, который был указан в одном из имен, которые разрешались до этого, то сервер не будет обращаться к корневому серверу, т.к. адрес удаленного сервера для этого домена также хранится в кэше местного сервера.
Вообще говоря, понятия "зона" и "домен" носят локальный характер и отражают только тот факт, что при настройках и взаимодействии между собой серверы доменных имен исходят из двухуровневой иерархии. Это значит, что если в зоне необходимо создать разделение на группы, то зону можно назвать доменом, и в нем организовать новые зоны. Например, у компании Sun Microsystems есть зона russia в домене sun.com (russia.sun.com). Так вот, эту зону тоже можно разбить на зоны, например, info.russia.sun.com и market.russia.sun.com.
Кроме нерекурсивной процедуры разрешения имен возможна еще и рекурсивная процедура разрешения имен. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим эти два случая более подробно.
На рисунке 3.8 продемонстрирована нерекурсивная процедура разрешения IP-адреса по доменному имени. Основная нагрузка в этом случае ложится на местный сервер доменных имен, который осуществляет опрос всех остальных серверов. Для того, чтобы сократить число таких обменов, если позволяет объем оперативной памяти, можно разрешить буферизацию (кэширование) адресов. В этом случае число обменов с удаленными серверами сократится.
На рисунке 3.9 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена, используя при этом нерекурсивный опрос своих серверов поддоменов.
Рис. 3.8. Нерекурсивная обработка запроса на получение IP-адреса
Рис. 3.9. Рекурсивная и нерекурсивная процедуры разрешения адреса по IP-имени
При этом локальный сервер сразу получает от удаленного сервера адрес хоста, а не адреса серверов поддоменов. Последний способ получения адреса называют рекурсивным, т.е. локальный и удаленный серверы взаимодействуют по рекурсивной схеме, а удаленный и серверы поддоменов по нерекурсивной.
Теперь от общих рассуждений перейдем к описанию настроек системы разрешения доменных имен в BIND.
3.1.5. Настройка resolver
Как уже говорилось выше, система разрешения доменных имен IP-адресами и обратная процедура построены по схеме "клиент-сервер". Функции из библиотеки libc.a выступают в качестве клиентов и вся их совокупность носит название resolver. Для того, чтобы клиент мог обратиться к серверу, он должен знать следующее:
Вся совокупность этих параметров задается в файле resolv.conf. Приведем пример этого файла и разберем назначение каждой из команд, которая может быть использована в файле настройки resolver.
Пример 2. Содержание файла resolv.conf.
# Resolver config for paul. # #nonameserver domain polyn.kiae.su nameserver 144.206.130.137 nameserver 144.206.136.1
Строки, начинающиеся с символа "#" - это комментарии. Среди них следует выделить строку "nonameserver". В нашем примере она не влияет на работу системы разрешения доменных имен, но если в сети нет сервера доменных имен, то следует с этой строки снять символ комментария, а прочие команды напротив превратить в комментарии. При отсутствии сервера доменных имен система будет использовать файл hosts.
По команде domain система определяет к какому домену она относится. Обычно, именем, которое указано после команды расширяются неполные имена хостов. Например, если обратиться к какой-либо машине только по ее имени:
/usr/paul> telnet radleg
/usr/paul>ping polyn.
В данном случае имя "polyn." завершено точкой.
/usr/paul> ping paul.polyn.kiae
Если в качестве домена в resolv.conf указан домен polyn.kiae.su, то будет проверена следующая последовательность имен: paul.polyn.kiae.polyn.kiae.su; paul.polyn.polyn.kiae.su; paul.polyn.kiae.su. Последнее имя будет разрешено сервером доменных имен.
При указании имени домена следует также учитывать и то, как будет в этом случае работать вес комплекс программного обеспечения, установленный на данном компьютере. Дело в том, что некоторые программы, sendmail, например, способны сами решат проблему определения IP-адресов по именам. В ряде случаев это может привести к противоречиям и ошибкам при функционировании такого сорта программ (о настройках sendmail см. раздел "Электронная почта")
Команда nameserver определяет адрес сервера доменных имен для домена, в котором данная машина состоит. Возможно указание нескольких серверов. Обычно - это не более трех серверов доменных имен. В таких системах как Windows NT, например, администратор просто не в состоянии указать более трех адресов серверов доменных имен.
Порядок в указании серверов в файле resolv.conf определяет порядок опроса серверов. Таким образом первым в нашем случае будет опрашиваться сервер с адресом 144.206.130.137, а затем сервер с адресом 144.206.136.1. Наиболее целесообразно первым указывать основной сервер доменных имен данного домена, а вторым дублирующий сервер доменных имен данного домена .
В качестве сервера доменных имен можно также указать и сервер вышестоящего домена, что позволит подстраховаться на случай отказа основного и вспомогательного серверов. При этом не будут решены проблемы адресации машин данного домена, но зато не пропадет возможность обращаться по имени к машинам, расположенным за пределами домена.
В настройках resolver надо также учитывать возможность запуска программы named, которая будет работать как кэш-сервер, что на машинах с "интеллектуальным" resolver'ом, что позволяет обеспечить более эффективную процедуру разрешения запросов к системе DNS.
Назад | Содержание | Вперед