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

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

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

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

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

Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен 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-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.

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

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

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

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

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

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

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

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

• com - commercial (коммерческие)
• edu - educational (образовательные)
• gov - goverment (правительственные)
• mil - military (военные)
• net - network (организации, обеспечивающие работу сети)
• org - organization (некоммерческие организации)

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

Каждая страна (государство) имеет свой географический домен из двух букв:

• ae - United Arab Emirates (Объединенные Арабские Эмираты)
• au - Australia (Австралия)
• be - Belgium (Бельгия)
• br - Brazil (Бразилия)
• by - Belarus (Белоруссия)
• ca - Canada (Канада)
• ch - Switzerland (Швейцария)
• cz - Czech Republic (Чехия)
• de - Germany (Германия)
• dk - Denmark
• do - Dominican Republic (Доминиканская республика)
• ee - Estonia (Эстония)
• eo - ???
• es - Spain (Испания)
• fi - Finland (Финляндия)
• fr - France (Франция)
• hu - Hungary (Венгрия)
• il - Israel (Израиль)
• in - India (Индия)
• iz - ???
• jp - Japan (Япония)
• kg - Kyrgyzstan (Кыргызстан)
• kr - South Korea (Южная Корея)
• kz - Kazakhstan (Казахстан)
• lt - Lithuania (Литва)
• lv - Latvia (Латвия)
• mx - Mexico (Мексика)
• nl - Netherlands (Нидерланды)
• no - Norway (Норвегия)
• nz - New Zealand (Новая Зеландия)
• pl - Poland (Польша)
• ro - Romania (Румыния)
• ru - Russia (Россия)
• si - Slovenia (Словения)
• sk - Slovak Republic (Словакия)
• su - Soviet Union (Советский Союз - поддерживается, но не распределяется)
• ua - Ukraine (Украина)
• uk - United Kingdom (Соединенное Королевство ВеликоБритания / Англия)
• yu - Yugoslavia (Югославия)
• za - South Africa (Южная Африка)

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

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

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

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

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

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