Domain Name Service
Служба Доменных Имен

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

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

Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".

Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.

Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов (такие как www.ru и ftp.ru; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.

Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:

• Клиент спрашивает своего сервера.
  • Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
• Сервер спрашивает корневой сервер.
• Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
• Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
• Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.

Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.

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

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

Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org (это домен организации, занимающейся распространением операционной системы FreeBSD Unix). FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:

• ftp.freebsd.org - первичный сервер в США
• ftp.страна.freebsd.org - основной сервер в стране
• ftpчисло.страна.freebsd.org - дополнительный сервер в стране

Так например на 11 февраля 1998 года

• ftp.ru.freebsd.org соответствует ftp.ru
• ftp2.ru.freebsd.org соответствует ftp.gamma.ru
• ftp3.ru.freebsd.org соответствует ftp.chg.ru

Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.

Однако, некоторым сервисам недостаточно прописывания машыны в DNS - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения (очевидно, это связано с тем, что E-mail может работать по протоколам, не нуждающимся не только в DNS, но даже в IP - например, UUCP). Протокол HTTP 1.1 в обязательном порядке (а 1.0 - в качестве дополнительной опции) требует, чтобы в HTTP-запросе указывался не только путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0. Это позволяет организовать несколько "виртуальных серверов" на машине, имеющей единственный IP-адрес. Подробности этого я рекомендую посмотреть в документации к WWW-серверу

, а также в книгах по администрированию WWW-серверов. Что же касается DNS, то ее роль в этом ограничивается указанием правильных IP-адресов (а для почты - еще и MX-записей) для данных имен.

Делегирование зоны ...in-addr.arpa дается только от провайдера вместе с пулом IP-адресов. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd.org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все зеркала, о которых говорилось выше (кроме расположенных в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.

Одна из проблем состит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить правА на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов! При невозможности делегирования "частичной" зоны, можно воспользоваться псевдонимом (alias'ом) CHNAME, перенаправив каждый IP-номер на DNS-сервер клиента.

DNS-услуги Internet-провайдера

Вообще говоря, комплекс услуг, предоставляемый провайдером, определяется договором, заключенным между ним и клиентом. Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:

• делегирование зоны ...in-addr.arpa клиентам, имеющим пул адресов, кратный 256;
• регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегестрироваться;
• поддержание вторичного сервера прямой и обратной DNS-зон клиента;
• поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);

Если провайдер будет отказываться - сошлитесь на меня. :-)

Политика и стратегия назначения имен

Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегестрированы следующие "организационные" зоны:

• com - COMmercial (коммерческие)
• edu - EDUcational (образовательные)
• gov - GOVermrnt (правительственные)
• int - INTernational (международные)
• mil - MILitary (военные)
• net - NETwork (организации, обеспечивающие работу сети)
• org - ORGanisation (некоммерческие организации)

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

Каждая страна (государство) имеет свой географический домен из двух букв (интересующиесь могут посмотреть список). В зонах государств опять же имеются "организационные" и "географические" зоны. "Организационные" в большинстве своем повторяют структуру "организационных" зон верхнего уровня, разве что вместо "com" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей. В частности, в зоне ru функционируют следующие домены:

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

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

Имена "функциональные" вытекают из функций, выполняемых машиной:

• www - HTTP(WWW)-сервер
• ftp - FTP-сервер
• gopher - Gopher-сервер
• ns, nss, dns - DNS(Name)-сервер
• mail - Mail-сервер
• relay - Mail Exchanger
• *proxy - соответствующий Proxy-сервер

Я считаю нежелательным присваивать какой-либо машине функциональное имя - в любой момент может потребоваться перенести соответствующую функцию на другую машину. Для этого лучше всего использовать псевдонимы, которые перенаправляют запросы к данному имени на записи, относящиеся к другому имени. Но вот ссылаться на псевдонимы при обьявлении Mail Exchanger'ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым.

Ссылки:

• Пример настройки Name-сервера
• WINS - Window Internet Name Service
  Динамически отслеживает соответствие имен Windows Network и IP-номеров машин. Аналог DNS, но составляется автоматически и без какого-либо масштабирования. Может интегрироваться с DNS, но не годится для использования в глобальной сети хотя бы потому, что при современном развитии Internet информация в DNS полностью обновляется в течении нескольких дней, а машина с динамически выделяемым номером не м.б. сервером Internet.
• NDS - NovellDirectory Service
  Весьма мощная база данных; содержит в себе сведения о структуре сетИ, в т.ч.:
  • учетные записи пользователей сетИ;
  • привязку сетевых директорий (аналог ресурса в Windows Network) к серверу, на котором она находится.
• Active Directory
  Micro$oft'овский аналог NDS; на начало 1999 года находится в стадии разработки, видимо, будет включен в Windows'NT 5.0.
• Windows'NT Domain
  Система централизованного хранения базы данных о правах и паролях пользователей. Никакого отношения к службе имен не имеет, здесь приведена только для устранения возможной путаницы, вызваной созвучием названий.