Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

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

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

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

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

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

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

Однако, некоторым сервисам этого недостаточно - так 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 - Microsoft'овский аналог NDS.
  • WindowsNT Domain - Система централизованного хранения базы данных о правах и паролях пользователей. Никакого отношения к службе имен не имеет, здесь приведена для устранения возможной путаницы, вызваной созвучием названий.

Оставить комментарий

Комментарий:
можно использовать BB-коды
Максимальная длина комментария - 4000 символов.
 

Комментарии

1.
Аноним
+1 / -0
Мне нравитсяМне не нравится
29 апреля 2006, 22:36:13
Согласен с большинством - написано очень не профессионально. Зачем, например писать о том, о чем нет "достоверной информации". Непонятны многие термины, хотелось бы побольше определений (как, например, в первом предложении). А так, вообще, тема хорошая.
2.
Аноним
Мне нравитсяМне не нравится
23 апреля 2006, 17:28:55
Статья написана ужасно, хотя и говорятся в ней правильые вещи
3.
Аноним
Мне нравитсяМне не нравится
13 апреля 2006, 13:31:20
нормально написано
надо чуть-чуть внимательней читать
4.
Аноним
Мне нравитсяМне не нравится
12 апреля 2006, 21:40:08
А меня вот интресует описание самого zone файла. То есть сколько где табов должно быть. Что означает А что означает CNAME Можно догадаться и так что MX это почта. Но все-таки Такую инфу бы почитать. А не в общем смысле
5.
Аноним
Мне нравитсяМне не нравится
9 апреля 2006, 13:04:51
Хорошая статья, хотя есть кое-какие вещи непонятные, но ничего дойдем своим умом
6.
Аноним
Мне нравитсяМне не нравится
8 апреля 2006, 14:24:29
А вот для чего существует домен .eo ?Объясните пожалуйста. Для кого он зарегистрирован? Уж не для страны Эсперантида? :) (только не ищите её на политических картах мира -- в жисть не найдёте)
7.
Аноним
Мне нравитсяМне не нравится
1 марта 2006, 16:32:45
Очень-очень интересная статья и совсем-совсем непонятная. Кто понят что-нибудь - тех поздравляю!
8.
Аноним
Мне нравитсяМне не нравится
3 февраля 2006, 09:43:47
Статья написана очень коряво. Складывается ощущение что после написания статьи половина предложений была выкинута.

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

Между первыми двумя и последними двумя предложениями в этой цитате отсутствует текст. Только что речь шла о серверах(видимо каких-то абстрактных сервисах в сети) и вдруг начинается обсуждение работы какой-то программы Name-сервер. Причем похоже это предложение выдернуто из середины мануала к этой программе.
9.
Аноним
Мне нравитсяМне не нравится
23 января 2006, 13:45:38
Прочитал и толком ничего не понял.. Наверное надо еще раз перечитать..
10.
Аноним
Мне нравитсяМне не нравится
6 января 2006, 12:31:50
2 Kai78

Я тоже непонял...
Но по всей видимости под доменным именем из трех сегментов автор понимает -> протокол.имя.домен ))) и т.д.
Довольно естественно что имя типа -> "сегмент"
без протокола и домена встречаются ну оочень крайне редко))))))

шучу конечно.

Не, про работу днс я знал но статья нужная.
11.
Аноним
Мне нравитсяМне не нравится
14 октября 2005, 16:08:43
Нет объяснения, что такое это загадочное ...in-addr.arpa. Остально вроде правильно себе представлял.
12.
Аноним
Мне нравитсяМне не нравится
27 августа 2005, 10:18:14
Объясните люди добрые зачем DNS в мобильных телефонах.
13.
Аноним
Мне нравитсяМне не нравится
19 мая 2005, 12:16:48
Вообщем то статья ничего.Но для тех кто нифига не разбирается в службе доменных имён.Я сейчас занимаюсь сбором информации по DNS - серверу, т.к. в организации он резко понадобился. В статье можно было привести пример хотя бы одной реализации DNS - сервера (например BIND).
14.
Аноним
Мне нравитсяМне не нравится
2 мая 2005, 08:30:47
Я тоже прочитал эту статью. Мне работа ДНС не знакома. Только известно что это такое и что делает.

Лично в этой статье многое для меня было непонятно. Написано в основе техничным языком. А так, тому кто поймет, думаю пригодится эта статья.
15.
Аноним
Мне нравитсяМне не нравится
29 декабря 2004, 15:43:29
Прочитал статью чисто из любопытствия, система днс мне известна. Но вот совсем не понятен следующий абзац:

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

Слово "сегмент" не встречается ни до, ни после этого абзаца и не совсем понятно о чем речь.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог