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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако, некоторым сервисам недостаточно прописывания машины в DNS - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения (очевидно, это связано с тем, что E-mail может работать по протоколам, не нуждающимся не только в DNS, но даже в IP - например, UUCP). Протокол HTTP 1.1 в обязательном порядке (а 1.0 - в качестве дополнительной опции) требует, чтобы в HTTP-запросе указывался не только путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0. Это позволяет организовать несколько "виртуальных серверов" на машине, имеющей единственный IP-адрес. Подробности этого я рекомендую посмотреть в документации к WWW-серверу Apache, а также в книгах по администрированию 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" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей. В частности, в зоне ru функционируют следующие домены:

com - COMmercial (коммерческие) mil - MILitary (военные) net - NETwork (организации, обеспечивающие работу сети) org - ORGanisation (некоммерческие организации) pp - Personal (частные лица)	Поддерживаются организацией RIPN
ac - ACademy (образовательные и научные организации)	Поддерживаются организацией FREEnet

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

Постарайтесь обеспечить однозначное написание доменного имени и его очевидность. Помните, что многие люди путают буквы "c" и "k", а также "v" и "w".

Обратите внимание на благозвучность домена. Имя домена не должно вызывать нежелательных (прежде всего непристойных) ассоциаций на русском и английском языках; если вы собираетесь активно общаться с носителями какого-либо третьего языка, проверьте пристойность звучания вашего домена на нем. В качестве атнипримера приведу "Непристойные шутки про DNS-имена".

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

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

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