tankistua
Gold Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
писал статью, но как-то недостает желания довести все до ума, тем более что разбираюсь в днс-е , но не супер-профи. А учить чему-то должен профессионал:
Посему, так как много написано и изложены некоторые мысли и личный опыт, просто выкладываю как есть.
Думаю кому-то будет полезно.
=========================================================================
Чтобы понять DNS, необходимо обратиться к истории сети ARPAnet.
Изначально сеть ARPAnet представляла тесное сообщество из нескольких сотен
узлов. Всю информацию, необходимую для взаимных преобразований имен и узлов
сети ARPAnet, содержал единственный hosts.txt , ответственность за него нес
Network Information Center(NIC). Администраторы ARPAnet просто посылали
изменения электронной почтой в NIC, которые дополняли файл hosts.txt и раз
или два раза в неделю обновляли его на сервере. Администраторы ARPAnet
посредством протокла ftp синхронизировали свои файлы hosts.txt с копией на
сервере NIC.
После перехода сети ARPAnet на протоколs TCP/IP, сеть начала расти
быстро, естественно увеличивался размер файла hosts.txt, вследствие
чего возникало много проблемы:
- информационные потоки и нагрузка
- конфликты имен
- синхронизация
Основной же проблемой было отсутствие масштабируемости.
В 1984 году были изданы RFC 882 и RFC 883, которые описывали
принципы работы системы доменных имен (Domain Name System, DNS),
впоследствии документы были заменены RFC 1034 и RFC 1035, так же были
написаны множественные допосления. Cписок RFC, относящихся к DNS http://www.faqs.org/rfcs/dns-rfcs.html
Если просто , то DNS - это распределенная база данных.
Система DNS подразумевают под собой передачу прав на управление определенной зоной администратору
данной зоны. Процедура передачи прав на управление зоной называется делегированием.
Корневых сервер не имеет RR-записей делигируемой зоны, исключение
составляют специальные RR-записи glue-record, которые необходимы, если
name-сервер находится в делегируемой зоне
Первая версия системы DNS называлась JEEVES и была разработана автором
RFC 882 и RFC 883. Более поздняя реализация носит название BIND (Berkeley
Internet Name Domain) и была разработана для операционной системы BSD Unix.
В настоящее время BIND является самой популярной и распространенной системой
DNS, развитием и сопровождением которого занимается Internet Software Consortium.
Настройка DNS-сиcтемы BIND.
Правила делегирования домена требуют наличия как минимум двух
ответственных за данную зону DNS-серверов. Такие сервера называются
автритативными для конкретной зоны. Один из авторитативных серверов назначается primary,
остальные - secondary. На primary-сервере храниться основной файл зоны, secondary-сервера
получают ( точнее берут ) данные с primary-сервера.
Соответственно и отличаются настройки серверов:
Настройка primary-сервера.
В конфирурационный файл named.conf необходимо добавить запись зоны
zone "имя_домена" {
type master;
file "имя_домена";
};
Настройка secondary-сервера.
В конфирурационный файл named.conf необходимо добавить запись зоны
zone "имя_домена" {
type slave;
file "имя_домена " ;
masters { ip_адрес_ primary-сервера; };
где имя_домена - собственно имя зоны, которую необходимо поддерживать
type master; - запись указывает, что это primary-сервер для данной зоны
type slave; - запись указывает, что это secondary-сервер для данной зоны
file "имя_домена"; - здесь необходимо указать путь к файлу , в котором будут
храниться данные зоны. Для простоты использования
рекомендуется называть файл зоны именем зоны, но имя файла может быть
произвольным. primary-сервер будет данные читать из файла,
который указан, secondary-сервера будет загружать с primary-сервера
данные и хранить эти данные в указанном файле (данный файл создается
secondary-сервером).
ip_адрес_ primary-сервера - указывается ip-адрес primary-сервера, на котором
храниться основной файл зоны
Для того, чтобы все пользователи сети INTERNET могли получать данные зоны,
необходимо на всех днс-серверах разрешить прохождение UDP-пакетов на 53-ий
порт. Так же необходимо на primary-сервере разрешить прохождение TCP-пакетов
на 53-ий порт от всех secondary-серверов. Это необходимо для обновления
файла зоны.
Конфигурация файла зоны
Сначала описываются параметры зоны
$TTL 86400
@ IN SOA primary-сервер. e-mail_администратора_домена. (
2005010700 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL
$TTL 86400- время жизни, директива устанавливает
стандартное время жизни (Time-to-Live - TTL)
для любой записи, в которой значение
времени жизни не задано.
SOA - запись SOA (Start-of-Authority - Начало
полномочий)
primary-сервер.- primary name-сервер
e-mail_администратора_домена.- e-mail лица , ответственно за доменю.
Вместо @ пишется точка
2005010700 ; Serial- Серийный номер. Число, которое необходимо
увеличивать при любом изменении файла зоны. На основе изменений name-сервера
решают, необходимо ли перечитывать конфигурацию зоны. Можно использовать
любое число(главное увеличение этого числа после внесения изменений), но
принято в поле писать текущую дату изменений в формате ГГГГММДДНН
(последние две цифры - порядковый номер изменения за текущие сутки)
3600 ; Refresh- запись предназначена для
secondary-серверов, задает интервал обновлений данных
зоны. Поводом к обновлению служит
изменившийся Serial
600 ; Retry- время повторения попытки обновления (Refresh) после сбоя
3600000 ; Expire- - максимальное время использования данных о
зоне secondary name-серверами при отсутсвии
возможности выполнить Refresh
86400 ) ; Minimum TTL- запись предназначена для кеширующих
серверов, задает минимальное время использования данных зоны
кеширующими серверами
Далее в файле зоны идут записи о ресурсах RR (Resource Record) в формате
<name> [<ttl>] [<class>] <tipe> <data>
<name>- поле имени.
[<ttl>]- время жизни, если необходимо задать
отличное от глобально-заданого
[<class>]- поле класса, задает группу протоколов,
актуальным на данный момент остался один
класс INTERNET (сокращенно IN).
<tipe>- поле типа указывает тип записи RR
Основные типы:
A- IP-адрес, указывает на хост,
которому соотвествует данное имя
MX- почтовый шлюз, обслуживающий
данную зону. После типа необходимо
указать приоритет почтовых шлюзов в
числовом виде, наименьшему значению
соответствует наибольший приоритет.
CNAME- Псевдоним. Удобно использовать при
смене имени хоста.
<data>- поле данных, определяется по-разному в
зависимости от <tipe>
Перейдем к практике, потому как я готов оспорить фразу:
"Знание теории освобождает от знания практики"
Предлагаю выступить в роли администратора домена ru-board.com. :)
Для начала нужно определится, какие сервера будут обслуживать зону, т.е.
являтся авторитативными и выбрать из них primary. primary-сервером определяем
ns1.ru-board.com., и выделяем для secondary еще 2 : ens1.eastera.net. и ns.saturn.tj.
Теперь их нужно соответствующим образом настроить:
В named.conf на ns1.ru-board.com. добавляем следующие данные
named.conf ----------------------------------------------------
zone "ru-board.com" {
type master;
file "ru-board.com";
};
---------------------------------------------------------------
Создаем файл зоны ru-board.com ( обычно создается в том же каталоге, где
расположен named.conf)
ru-board.com --------------------------------------------------
$TTL 86400
@ IN SOA ns1.ru-board.com. admin.ru-board.com. (
2005010600 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL
IN NS ns1.ru-board.com.
IN NS ns.saturn.tj.
IN NS ens1.eastera.net.
IN MX 10 mail.ru-board.com.
mail IN A 65.75.176.221
---------------------------------------------------------------
В named.conf на серверах ens1.eastera.net. и ns.saturn.tj. добавляем следующие данные
named.conf ----------------------------------------------------
zone "ru-board.com" {
type slave;
file "ru-board.com" ;
masters { 65.75.176.228; };
---------------------------------------------------------------
Заставляем BIND перечитать файл конфигурации на name-серверах
# rndc reload ( # ndc reload - для BIND 8-ой версии )
Проверяем
$ dig ru-board.com @65.75.176.228 soa
$ dig ru-board.com @ns.saturn.tj soa
$ dig ru-board.com @ens1.eastera.net soa
Если получаем 3 одинаковых ответа:
; <<>> DiG 9.2.4 <<>> ru-board.com @65.75.176.228 soa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23365
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; QUESTION SECTION:
;ru-board.com. IN SOA
;; ANSWER SECTION:
ru-board.com. 3600 IN SOA ns1.ru-board.com. admin.ru-board.com. 1088096129 5400 600 1814400 3600
;; AUTHORITY SECTION:
ru-board.com. 3600 IN NS ns.saturn.tj.
ru-board.com. 3600 IN NS ns1.ru-board.com.
ru-board.com. 3600 IN NS ens1.eastera.net.
;; ADDITIONAL SECTION:
ns1.ru-board.com. 3600 IN A 65.75.176.228
;; Query time: 203 msec
;; SERVER: 65.75.176.228#53(65.75.176.228)
;; WHEN: Sat Jan 8 02:17:34 2005
;; MSG SIZE rcvd: 162
Значит name-сервера и зона настроены корректно.
И только после того , как убедились , что зона корректно настроена,
отправляем заявку на регистрацию домена.
Данное руководство не охватывает в полной мере всех настроек BIND, кому
интересно, тот может обратиться к RFC или книгам. Книг написано достаточно
много, есть переведенные на русский и достаточно грамотно. Целью же данного
руководства было описание процесса пошаговой настройки BIND-а.
Замечания.
----------------------------------------------------------------------------
Для того, чтобы все пользователи сети INTERNET могли получать данные зоны,
необходимо на всех днс-серверах разрешить прохождение UDP-пакетов на 53-ий
порт. Так же необходимо на primary-сервере разрешить прохождение TCP-пакетов
на 53-ий порт от всех secondary-серверов. Это необходимо для обновления
данных зоны secondary-серверами.
----------------------------------------------------------------------------
Обратите внимание на точки в RR-записях, это не опечатка и не просто так.
Например записи
IN NS ns1.ru-board.com.
ru-board.com. IN NS ns1.ru-board.com.
ru-board.com. IN NS ns1
IN NS ns1
различны в написании, но полностью идентичны по функциональности. Если имя
или данные не заканчиваются на точку, то BIND добавляет к имени индекс зоны.
Если мы не поставим точку в записи
IN NS ns1.ru-board.com
, то окажется, что зону обслуживает сервер ns1.ru-board.com.ru-board.com
----------------------------------------------------------------------------
Что такое glue-record.
Допустим мы делегируем зону users.ru-board.com, а один из name-сервера будет
расположены в делегируемой зоне и иметь имя fire.users.ru-board.com.
Тогда в файл зоны ru-board.com добавим следующие записи
users IN NS ns1.ru-board.com.
IN NS secondary-ns
fire.usersIN A193.193.193.193 (ip-адрес хоста fire.users.ru-board.com)
Запись
fire.users IN A 193.193.193.193
как раз и есть glue-record.
----------------------------------------------------------------------------
Из предыдущего примера.
Запись
users IN NS ns1.ru-board.com.
IN NS secondary-ns
будет равносильна записи:
users IN NS ns1.ru-board.com.
users IN NS secondary-ns
но запись
users IN NS ns1.ru-board.com.
IN NS secondary-ns
будет иметь совсем другое значение.
Данные полей <name> и <class> предыдущей RR-записи имет влияние на следующие за ними RR-записи,
если в следующих не заданы другие параметры. Чтобы следующие RR-записи не
подвергались данному воздействию необходимо записи разделять пустой строкой.
|
