Domain Name Service
Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем 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'ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым.
Ссылки:
- WINS - Window Internet Name Service
Отслеживает соответствие имен Windows Network и IP-номеров машин. Аналог DNS, но с динамическим отлеживанием и без какого-либо масштабирования. - NDS - Novell Directory Service
Служит для определения местонахождения сервера, на котором находится данная сетевая директория (аналог ресурса в Windows Network). - Active Directory
Micro$oft'овский аналог NDS. - WindowsNT Domain
Система централизованного хранения базы данных о правах и паролях пользователей. Никакого отношения к службе имен не имеет, здесь приведена для устранения возможной путаницы, вызваной созвучием названий.