Меню

Bind настройка собственной зоны



Создание и настройка первичной зоны в BIND

Прежде, чем приступить к настройке зоны, необходимо установить и предварительно настроить bind (инструкции для CentOS или Ubuntu).

Создание и настройка локальной зоны

Открываем конфигурационный файл bind.

В CentOS / Red Hat:

В Ubuntu / Debian:

И добавляем следующее:

zone «test.local» <
type master;
file «master/test.local»;
allow-transfer < 192.168.0.15; >;
allow-update < none; >;
>;

* где test.local — имя зоны, которую будет обслуживать наш DNS-сервер. Это и есть домен, для которого bind будет хранить записи;

Описание опций настройки зоны:

Опция Описание
type тип зоны (в нашем случае первичная — значит master). Другие варианты — slave, stub, forward.
file Путь к файлу с записями зоны. В данном примере указан относительный путь — то есть файл находится по пути master/test.local, который начинается относительно рабочей директории (по умолчанию — /var/named/). Таким образом, полный путь до файла — /var/named/master/test.local.
allow-transfer Список других DNS-серверов (вторичных) для передачи им зоны. В нашем случае, зонные передачи разрешены серверу 192.168.0.15. Можно указывать подсети.
allow-update Список хостов, с которых разрешено обновление записей в зоне (для DDNS). Можно указать подсети.

Чтобы настройки применились, необходимо перезапустить службу.

В CentOS / Red Hat:

systemctl reload named

В Ubuntu / Debian:

systemctl reload bind9

Создание файла зоны и настройка записей

Создаем каталог master (если он отсутствует).

В CentOS / Red Hat:

В Ubuntu / Debian:

И создаем файл зоны (в нашем примере test.local).

CentOS / Red Hat:

Приводим его к следующему виду:

test.local. IN SOA ns1.test.local. admin.test.local. (
2017082401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)

IN NS ns1.test.local.
IN NS ns2.test.local.

IN MX 10 mx.test.local.
IN MX 20 mx2.test.local.

@ IN A 192.168.1.1
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5

www IN CNAME test.local.

Основные типы записей, использующиеся в DNS:

  1. A — сопоставляет имени узла соответствующий IP-адрес.
  2. NS — указатель на DNS-сервера, которые обслуживают данную зону.
  3. MX — почтовая запись. Указывает на почтовые сервера, которые обслуживают домен. Поддерживает приоритизацию — при указании нескольких записей, клиент будет ориентироваться на значение той, для которой указано меньшее число.
  4. CNAME — aliase или псевдоним. Перенаправляет запрос на другую запись.
  5. TXT — произвольная запись. Чаще всего используется для настройки средств повышения качества отправки почтовых сообщений.
Параметр Описание
$TTL Время актуальности записей в секундах. Необходим, чтобы указать другим DNS-серверам, как долго стоит хранить запись у себя в кэше. Слишком малое значение увеличит нагрузку на сервер, а большое приведет к слишком длительному процессу изменения записи.
SOA-запись В данном примере эта запись идет сразу после параметра TTL. Ее стоит описать отдельно. Она хранит общие настройки для зоны.

  • Serial — порядковый номер изменения. Его необходимо каждый раз менять вручную при редактировании файла. С помощью него вторичный сервер (если такой есть), может определить, что были изменения и начать процесс копирования настроек.
  • Refresh указывает вторичным серверам, через какой промежуток времени они должны сделать запрос на обновление зоны.
  • Retry говорит вторичным серверам, как часто повторять попытки на обновление зоны, если первичный сервер не смог дать ответ (сервис был недоступен).
  • Expire — время в секундах, которое может работать вторичный сервер, если недоступен первичный. Если данный период истечет, а вторичный сервер так и не смог обновить зону, он должен прекратить отвечать на запросы.
Собственно доменное имя хоста. Может записываться без домена (как в данном примере) — он будет дописан автоматически. Также может быть записан полностью с доменом — в таком случае необходимо поставить точку на конце, например, mail.test.local. Если не указывается или обозначается знаком собаки (@), запись создается для имени зоны (в данном случае, test.local).
Всегда используется IN (Internet). Указывает на тип сети.
Используется IP-адрес, имя узла, текстовая запись.

Чтобы зона начала работать, перечитываем ее:

Проверка

С другого компьютера вводим команду:

nslookup mail.test.local 192.168.0.15

* где 192.168.0.15 — наш настроенный DNS-сервер.
** сервер должен вернуть IP-адрес для запрошенного узла — а именно 192.168.1.5

Источник

Ubuntu → Настройка DNS-сервера BIND Master & Slave, с автоматической репликацией данных между серверами

В этот раз, я вам расскажу как настроить собственные DNS сервера, с автоматическим переносом зон на подчиненные сервера.
Идея следующая, т.к. для полноценной работы доменного имени требуется как минимум 2 DNS сервера, то один сервер у нас получается главным (Master), а второй, подчиненным (Slave), то принцип работы будет следующий, изменения внесенные на Master сервере, будут автоматический перенесены на Slave сервера.
Для чего это может понадобиться-например для поддержки работы своего доменного имени, или целой кучи сайтов. В принципе, держать, ради одного домена, собственную инфраструктуру NS серверов, наверное не стоит, но если у вас пара десятков сайтов, то повозиться имеет смысл…
Ну а чтобы не создавать «тепличных условий», мы настроим сразу 3 сервера 1-Master и 2 -Salave, как указанно на схеме ниже.

Думаю что из изображенного на схеме понятно что изменения внесенные на главном сервере, будут автоматически переданы на подчерненные сервера, чтобы, в случае выхода из строя одного из серверов, все продолжало работать как надо.
А теперь практика.

Настраиваем Master сервер

Для начала сделаем основные настройки сервера:
Поднимаем права до root

редактируем параметры options:

Сразу под строкой directory «/var/cache/bind»; добавляем

Находим и закомменитуем строку

Рассмотрим подробнее, то что мы написали:
allow-query < any; >; -параметр отвечающий за то- от кого принимать запросы, мы их принимаем от всех.
version «Super DNS server»; -Уровень болтливости сервера, вместо названия сервера выдаст Super DNS server (можно написать что-то свое).
allow-recursion < none; >; — Отключаем использование рекурсивных запросов т.к. это сильно снижает скорость работы, да и нее имеет смысла опрашивать вышестоящие DNS сервера по поводу зоны которую сами же и обслуживаем. Можете ради эксперимента закомментировать эту функцию, и выполнить запрос, разрешение имени идет почти 4 сек, что не позволительно много…

Создадим нашу первую доменную зону.

И добавляем туда:

Сохраняем изменения и выходим.
Давайте разберемся, что мы туда добавили
zone «example.org» IN — собственно, название DNS зоны, которую мы будем обслуживать, тут вы указываете название своего домена (который нужно купить заранее. )
type master; — Тип данного сервера, не буду играть в К.О. это мастер сервер.
file «/var/lib/bind/example.org.db»; -путь к файлу с настройками данной зоны
allow-transfer <192.168.10.60; 192.168.10.70;>; -разрешаем передачу данной зоны на остальные наши DNS сервера.
allow-update <192.168.10.60; 192.168.10.70;>; — разрешаем обновление.
notify yes; -включаем автоматическое уведомление подчиненных серверов об обновлении файла настроек DNS зоны.

Создаем файл с настройками для созданной нами DNS зоны.
как мы определились ранее, файл с настройкам будет у нас находиться в /var/lib/bind/example.org.db вот его мы и создадим:

Со следующим содержимым:

Рассмотрим подробнее написанное:
$TTL 3600 — Time to live время жизни, по умолчанию ставим 1 час
example.org IN SOA ns01.example.org. root.example.org. сама зона, которая обслуживается данным сервером.
1; Serial -ее серийный номер DNS записи.
600; Refresh-указывает подчиненным DNS серверам как часто им обращаться, для поиска изменений к master серверу.
3600; Retry — говорит о том, сколько Slave сервер должен подождать, прежде чем повторить попытку.
1w; Expire — Максимальный срок жизни записей, после которой они потеряют актуальность (1 неделя)
300; Minimum TTL -минимальный срок жизни записи 5 мин.
NS ns01.example.org.-NS сервер который обслуживает эту зону
NS ns02.example.org.-NS сервер который обслуживает эту зону
NS ns03.example.org.-NS сервер который обслуживает эту зону
A 192.168.10.20 -если требуется попасть по адресу example.org, то клиенту будет выдан этот IP
ns01 A 192.168.10.50 — Записи для поиска наших NS серверов
ns02 A 192.168.10.60
ns03 A 192.168.10.70
www A 192.168.10.20 -Если клиент запросит адрес www.example.org, то ему будет выдан IP 192.168.10.20
test A 192.168.10.12 -Если клиент запрашивает адрес test.example.org, какой будет выдан ему IP?

Если все поднялось нормально, то переходим к настройке Slave сервера, если по каким-то причинам «не взлетело» идем смотреть логи, которые находятся /var/log/syslog и устраняем указанные в них ошибки.

Настраиваем Slave сервер

Я расскажу как настроить 1 подчиненный сервер, второй настраивается аналогично.
Редактируем options

Добавим в него, тоже что и к первому серверу

Находим и закомменитуем строку

Думаю что останавливаться на этом, во второй раз, не имеет смысла, ну а если память «девичья» возвращающемся в начало, повторение оно мать, сами знаете чего…

Создадим доменную зону.
Открываем файл

И добавляем туда запись, только на этот раз она будет немного отличаться:

Рассмотрим подробнее изменения:
type slave;-тип зоны подчиненная
file «/var/lib/bind/slave.example.org.db»; -путь к файлу с настройками, в этот раз в имени файла указано slave.example.org.db чтобы было понятно на каком сервере вы находитесь.
masters < 192.168.10.50; >; — IP адрес Мастер сервера, откуда будет производиться запрос файлов с настройками DNS зон.
allow-transfer <«none»;>; — Отключаем передачу зоны другим серверам, чтобы нельзя было получить все записи в домене
Сохраняем изменения и перезапускаем Bind:

Больше ничего создавать не нужно!
теперь открываем файл с настройками DNS зоны и обнаруживаем что в нем появилось содержимое

Bind кое что туда добавил сам(Смотрим скриншот):

А именно-расставил комментарии о сроках жизни различных параметров.
Третий сервер настраивается аналогично этому, все 1 в 1…
На подчиненных серверах все файлы создаются автоматически

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

Теперь возвращающемся к нашему мастер серверу, в файле /var/lib/bind/example.org.db добавляем запись вида

и увеличиваем серийный номер DNS зоны на единицу
После этого на мастер сервере перезапускаем Bind

Возвращаемся к нашему подчиненному серверу, на котором мы открыли просмотр отображения изменений в syslog и замечаем что там появились новые записи вида:

Jul 15 16:32:50 ns03 named[1346]: client 192.168.10.50#22434: received notify for zone ‘example.org’
Jul 15 16:32:50 ns03 named[1346]: zone example.org/IN: Transfer started.
Jul 15 16:32:50 ns03 named[1346]: transfer of ‘example.org/IN’ from 192.168.10.50#53: connected using 192.168.10.60#56299
Jul 15 16:32:50 ns03 named[1346]: zone example.org/IN: transferred serial 2
Jul 15 16:32:50 ns03 named[1346]: transfer of ‘example.org/IN’ from 192.168.10.50#53: Transfer completed: 1 messages, 11 records, 271 bytes, 0.001 secs (271000 bytes/sec)
Jul 15 16:32:50 ns03 named[1346]: zone example.org/IN: sending notifies (serial 2)

Это говорит о том что Master сервер уведомил Slave сервера об изменениях, а Salve сервер их принял и примерил.

Теперь нам нужно уточнить что DNS записи пока НЕ идентичны на всех серверах, т.к. изменения могут еще «не доехать» до подчиненных серверов.
Чтобы в этом убедиться давайте сначала опросим Master сервер, чтобы послать ему запрос, в Windows это делается из командной строки, почти всем, знакомой командой nslookup, нас интересует новая запись test123.example.org

Где:
Nslookup-думаю что все знают что это за команда…
test123.example.org -запрос записи
192.168.10.50 -IP адрес DNS сервера от которого мы хотим получить ответ
В ответ нам выдаст, то что изображено на скриншоте

Таким же способом мы опросим Slave сервер

В ответ мы получим:

Это произошло по тому что изменения до него еще «не доехали» с мастера, таке иногда бывает, нужно просто немного подождать, пока в логах не появляться запись вида

Это говорит о том что данные приехали нормально.
Отлично данные реплицируются, на подчиненные сервера.

Теперь важный момент, для тех кто дочитал до конца.
Как со всем этим теперь работать, чтобы гарантировать что данные будут переноситься автоматически и без сбоев.
Вернемся к нашему файлу зоны

У нас есть такой параметр как серийный номер зоны, который в данный момент равен единице,

ВНИМАНИЕ.

Каждый раз, когда в настройки вносятся изменения, к серийному номеру прибавляется единица, это делается для того чтобы подчиненные сервера увидели изменения в записях и приняли обновленный файл зоны, если после внесения изменений в файл, серийный номер остался прежним или уменьшился, то подчиненные DNS сервера НЕ станут подтягивать обновления считая что на мастер сервере изменений небыло!
За более подробной информацие обратитесь к RFC1982
Это важный и тонкий момент, внесли изменения +1 к серийному номеру.

Теперь, чтобы делегировать доменное имя в настройках домена вам нужно указать:
ns01.example.org
ns02.example.org
ns03.example.org

После завершения тестирования, домен будет делегирован, с указанным вами списком NS серверов.
И все будет работать как часы.

По такой схеме можно строить довольно крупные узлы NS серверов, тут в качестве тестирования все DNS сервера находятся в одной подсети, но в боевых условиях, такого быть не должно иначе вы в один момент вы можете потерять все DNS сервера, по этому необходимо разнести сервера в разные подсети / дата-центы / континенты, в общем, не складываем все яйца в одну корзину.

Уф все, с DNS закончили… Спасибо тем кто дочитал до конца.

Возникли вопросы, прошу в комментарии, нашли ошибку, пишите в личку, ну или на мыло, которое указано в нижнем левом углу страницы.

Источник

Читайте также:  Где искать настройки в мазил
Adblock
detector