Bind master настройка centos



Установка и настройка DNS-сервера BIND на CentOS в chroot-окружении

В статье рассказывается, как настроить DNS-сервер BIND в CentOS. Сервис будет работать в изолированном chroot-окружении, использовать разные зоны для внутренних и внешних клиентов (view).

• зона example.com (обслуживают два сервера)
• master-сервер: ns1.example.com, внешний ip:62.220.58.71, внутренний ip:172.16.0.1
• slave-сервер: ns2.example.com, внешний ip:62.220.58.72, внутренний ip:172.16.0.2
• локальная сеть: 172.16.0.0/22

Вначале установим сам сервис и необходимые утилиты:

# yum install bind-chroot bind-utils

Подготовим chroot-каталог, запустив специальный скрипт:

# /usr/libexec/setup-named-chroot.sh /var/named/chroot on

Укажем параметр для использования chroot

Редактируем файл конфигурации /etc/named.conf:

Мы описали два «вида» (view) — в internal будут попадать запросы из внутренней сети: match-clients < "local-subnet"; >;

и для них будет подгружаться конфиг /etc/named/named.internal.conf, все остальные попадут в external:

для них отключена рекурсия и добавятся зоны из конфига /etc/named/named.external.conf.

Для удобства создадим символьную ссылку:

# ln -s /etc/named.conf /etc/named/named.conf

Дополнительные файлы конфигурации

Файл /etc/named/named.internal.conf:

Файл /etc/named/named.external.conf:

Описание зоны example.com на дополнительном (slave) сервере будет таким:

Создаем файлы зон на основном сервере

Для начала подготовим папки для храниения зон:

# mkdir /var/named/external && mkdir /var/named/internal # chown named:named /var/named/internal && chown named:named /var/named/external # chmod 770 /var/named/internal && chmod 770 /var/named/external # ln -s /var/named/internal /etc/named/internal && ln -s /var/named/external /etc/named/external

Внутренняя зона example.com

Зона для локальных клиентов храниться в файле /var/named/internal/example.com.zone:

Внешняя зона example.com

Зона example.com для внешних клиентов храниться в файле /var/named/external/example.com.zone:

TXT-запись в нашем случае имеет тип spf и определяет кто, может посылать письма от зоны example.com. Эта запись очень важна, крупные почтовые сервера типа GMail могут посчитать вашу почту спамом, из-за отсутствия данной записи.

Проверяем зоны на ошибки:

# named-checkzone example.com /var/named/external/example.com.zone # named-checkzone example.com /var/named/internal/example.com.zone

Добавляем сервер в автозагрузку и запускаем

# chkconfig named on # service named start

Укажем сервер в качестве основного DNS-сервера в сетевых настройках:

Добавляем правила в iptables

DNS-сервер работает на 53 порту UDP, а для передачи зон использует 53 порт TCP. Отвечать на запросы будет всем, но передавать зону только slave-серверу, по локальной сети.

# iptables -A INPUT -p udp —dport 53 -j ACCEPT -m comment —comment «dns-query» # iptables -A INPUT -s 172.16.0.2 -p tcp —dport 53 -j ACCEPT -m comment —comment «dns-transfer»

Источник

Как установить и настроить DNS-сервер BIND на Linux CentOS

Что такое DNS, BIND, Linux и CentOS простыми словами. Версии используемого ПО — CentOS 7, BINВ 9.

Подготовка сервера

Устанавливаем все обновления:

Устанавливаем утилиту для синхронизации времени:

# yum install ntpdate

Настраиваем временную зону:

# \cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере выбрано московское время.

И синхронизируем время с внешним сервером:

Открываем порт в firewall:

# firewall-cmd —permanent —add-port=53/udp

И перечитываем настройки сетевого экрана:

Установка и запуск BIND

Устанавливаем DNS-сервер следующей командой:

# yum install bind

# systemctl enable named

Запускаем сервис имен:

# systemctl start named

И проверяем, что он работает корректно:

# systemctl status named

Базовая настройка DNS-сервера

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

и редактируем следующее:

* где 192.168.166.155 — IP-адрес нашего NS-сервера, на котором он будет принимать запросы; allow-query разрешает выполнять запросы всем, но из соображений безопасности можно ограничить доступ для конкретной сети, например, вместо any написать 192.168.166.0/24.

Для применения настроек выполните команду:

# systemctl restart named

Для проверки работоспособности сервера с другого компьютера сети (например, на Windows) выполняем команду:

> nslookup dmosk.ru 192.168.166.155

* данной командой мы пытаемся узнать IP-адреса сайта dmosk.ru через сервер 192.168.166.155.

Должно получиться, примерно, следующее:

Описание глобальных опций

Перечисленные ниже параметры являются глобальными по отношению к DNS и всем настроенным зонам. Они задаются в конфигурационном файле named.conf, директиве options <>.

Пример глобальных настроек

Зоны bind

Для возможности искать соответствия в собственной базе доменов, необходимо создать и настроить зоны. Существуют следующие типы зон:

1. Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind.
2. Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind.
3. Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
4. Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.

Решение проблем с помощью log-файлов

По умолчанию, сервер Bind под CentOS хранит логи в файле /var/named/data/named.run.

Для его непрерывного просмотра вводим следующую команду:

tail -f /var/named/data/named.run

Степень детализации логов можно настроить в конфигурационном файле:

logging <
channel default_debug <
file «data/named.run»;
severity dynamic;
>;
>;

* где file — путь к log-файлу; severity — уровень чувствительности к возникающим событиям. Возможны следующие варианты для severity:

• critical — критические ошибки.
• error — ошибки и выше (critical).
• warning — предупреждения и выше. Предупреждения не говорят о наличии проблем в работе сервиса, однако это такие событтия, которые могут привести с ошибкам, поэтому не стоит их игнорировать.
• notice — уведомления и выше.
• info — информация.
• debug — отладка (подробный лог).
• dynamic — тот же debug.

Напротив, чтобы отключить ведение лога, в конфигурационном файле должна быть настройка:

После изменения конфигурационного файла перезапускаем сервис:

systemctl restart named

Лог запросов

Если мы хотим также видеть в логе все запросы, которые приходят на bind, в командной строке вводим:

Источник

Настройка DNS-сервера (bind) в CentOS/RHEL 7

20.11.2014 / Wakko / 5 комментариев

BIND (Berkeley Internet Name Daemon) так же известен как named – это самый известный и самый используемый DNS-сервер в интернете. Я постараюсь описать процесс установки и настройки этого сервиса в chroot-окружении (chroot – операция изменения корневого каталога в Unix-подобных операционных системах. Программа, запущенная с изменённым корневым каталогом, будет иметь доступ только к файлам, содержащимся в данном каталоге. Поэтому, если нужно обеспечить программе доступ к другим каталогам или файловым системам (например, /proc ), нужно заранее примонтировать в целевом каталоге необходимые каталоги или устройства.).

Сначала установим сам сервис и сопутствующие утилиты:

Теперь подготовим chroot-каталог, подмонтировав необходимые файлы и папки, и проведём первоначальную настройку DNS-сервера:

Note: в acl «xfer» я добавил IP-адреса серверов, которые будут secondary-серверами для моих зон. Если вы на своём DNS-сервере никакие зоны хостить не собираетесь – этот блок можно оставить пустым, иначе впишите туда IP-адреса secondary-серверов для ваших зон.

Настраиваем firewall для работы DNS-сервера:

Включаем автозапуск DNS-сервера и запускаем сервис:

Note: в качестве 2-го и 3-го DNS-сервера лучше вписать IP-адрес DNS-серверов вашего провайдера, так резолвинг будет проходить чуть быстрее.

Если в предыдущем пункте никаких ошибок не возникло – добавим функционала, настроим сервер как master для нескольких зон (если сервер нужно настроить как slave для зон, этот пункт пропускаем и читаем следущий):

Если сервер нужно настроить как slave, делаем следующее:

Вот и всё, DNS-сервер настроен и готов к работе!

Поделиться ссылкой:

Comments

Бегло пробежав по инструкции, оставлю немного критики:
1) Пакет named-chroot подразумевает что chroot окружение со всем необходимым будет создаваться и монтироваться само в директории /var/named/chroot
Следовательно все остальные манипуляции излишни. И редактировать файлы рекомендуется так же в /var/named, а не в /var/named/chroot. Главное — включать и запускать только лишь сервис named-chroot, но не named.
Плюс рекомендуется (и я не вникал почему, полагаю из соображений безопасности) редактировать зоны в chroot окружении используя копии, например
# vim -c «set backupcopy=yes» /etc/named.conf
Подробности о named-chroot в rhel 7 здесь https://access.redhat.com/articles/770133

2) setsebool -P named_write_master_zones=1 рекомендуется использовать только в случае динамических зон. Для slave зон у named разрешения и так есть, а это правило для перезаписи bind’ом мастер зон.
Часть с chcon вообще бессмысленна, так как если класть конфиги туда куда полагается — проблем и не будет, плюс chcon делает смену контекста временно, и если сделать restorecon то метка слетит на дефолтную (и это может случится без вашего участия, если системе, например, после восстановления ошибок фс понадобится переразметить контексты). В данном случае это вообще ну нужно, но контекст менять нужно через semanage.

3) Файлы включенные в основную конфигурацию named.conf рекомендуется помещать в директорию /etc/named/. В вашем случае будет /etc/named/named.zones. Подробности тут https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html

4) Рекомендуется использовать утилиту rndc для всего что она поддерживает, в том числе
rndc reconfig
rndc reload
rndc reload zone
и тд. Смысл в том что дёргать каждый раз systemctl reload named не стоит, плохая практика. Плюс в rhel\centos о конфигурации этого самого rndc позаботились до нас и настраивать для использования на этом хосте не нужно. И создать заготовок зоны так же можно через rndc
И кстати для удобства можно значения в SOA записи делать не в секундах, а в более понятных величинах — 1d 1h 1w и тд. Передаваться оно будет всё равно в секундах, но конфигурировать легче.

За исключением этих мелочей — это прекрасная статья, спасибо. И меня впечатлило следование RFC 4408 с TXT и SPF записями.

Источник

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 закончили… Спасибо тем кто дочитал до конца.

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

Источник