Меню Рубрики

Установка bind9 dns на centos

Установка Bind 9 (named) в CentOS 7

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.

Что такое DNS сервер BIND

Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.

Устанавливаем Bind 9 (named) в CentOS 7

Первым делом проверим, установлен ли у нас днс сервер в системе:

У меня не установлен, так как во время инсталляции centos выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind :

Проверяем содержимое chroot каталога:

Все в порядке, сервер запустился, необходимые файлы созданы, все готово для настройки. Займемся ей.

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf . Открываем его и приводим к следующему виду:

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

listen-on-v6 port 53 < none; >; Отключили работу на интерфейсе ipv6.
allow-query < 127.0.0.1; 192.168.7.0/24; >; Разрешаем обычные запросы только из локальной сети.
allow-recursion < 127.0.0.1; 192.168.7.0/24; >; Разрешаем рекурсивные запросы только из локальной сети.
forwarders < 8.8.8.8; >; Перенаправляем запросы, которые сами не резолвим, на днс сервер гугла. У меня указан он просто для примера. Тут лучше всего указать сначала ДНС серверы провайдера.
version «DNS Server»; Скрываем версию бинда, вместо этого выводим указанную строку.

Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

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

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

Дальше подключаем файл зоны в конфигурационном файле bind — /var/named/chroot/etc/named.conf :

Перечитываем конфигурацию named с помощью rndc:

Добавление в bind slave zone

Если вы хотите на своем сервере держать копию какой-то зоны, взятой с другого dns сервера, то добавьте следующие настройки в конфиг.

10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер.

Чтобы сервер смог корректно сохранить файл со slave зоной, необходимо добавить разрешение на запись bind для директории /var/named/chroot/var/named. По-умолчанию она имеет следующие права:

Нужно добавить группе named разрешение на запись, чтобы стало вот так:

После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone. Если у bind не будет прав для создания файла, в логе вы получите ошибку:

Настройка логов в bind (named)

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

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

Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала:

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Читайте также:  Установка временных коронок на вкладки
Описание параметров severity

critical Только критические ошибки.
error Обычные ошибки и все что выше.
warning Предупреждения и все, что выше.
notice Уведомления и все, что выше.
info Информационные сообщения и все что выше.
debug Сообщения уровня debug и все, что выше. Уровни debug регулируются значениями 0, 1, 2, 3.
dynamic То же, что и debug, только его уровень регулируется глобальной настройкой сервера.

Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:

  • print-severity yes | no — указывает, писать или нет параметр severity в лог
  • print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no, которое лично меня устраивает.

Дальше необходимо указать категорию логов и в какой канал мы будем ее записывать:

Категорий у днс сервера bind достаточно много. Вот мой перевод полного списка с описаниями:

Описание категорий логов в bind (named)

default Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий.
general Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий.
database Сообщения, относящиеся к хранению зон и кэшированию.
security Подтверждение и отказ в выполнении запросов.
config Все, что относится к чтению и выполнению файла конфигурация.
resolver Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером.
xfer-in Информация о получении зон.
xfer-out Информация о передаче зон.
notify Логирование операций протокола NOTIFY.
client Выполнение клиентских запросов.
unmatched Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение.
network Логирование сетевых операций.
update Динамические апдейты.
update-security Подтверждение или отклонение запросов на апдейт.
queries Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера.
query-errors Ошибки запросов к серверу.
dispatch Перенаправление входящих пакетов модулям сервера на обработку.
dnssec Работа протоколов DNSSEC и TSIG.
lame-servers Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени.
delegation-only Логирование запросов, вернувших NXDOMAIN.
edns-disabled Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts.
RPZ Все операции, связанные с выполнение Response Policy Zone (RPZ).
rate-limit Операции связанные с одним или несколькими rate-limit statements в options или view.

Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:

Если мы хотим собирать все логи запросов из категории queries, то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, настроить запрет сайтов на микротике.

Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.

источник

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

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

Читайте также:  Установка appfabric для sharepoint 2013

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> nslookup dmosk.ru 192.168.166.155

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

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

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

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

Опции Описания
directory Указывает рабочий каталог сервера bind. Если не указан, /var/named
forwarders Перечисляет серверы, на которые будет переведен запрос, в случае, если наш сервер не сможет его обработать (нет соответствующей зоны.)
forward Переопределяет способ обработки запроса. Принимает два значения — ONLY или FIRST. Первое указывает на то, что сервер не будет пытаться искать совпадения среди локальных зон. Второе — сервер сначала будет перенаправлять запрос и если он не будет успешно обработан, искать соответствия во внутренней базе.
listen-on На каких интерфейсах будет слушать bind
allow-transfer Указание на список серверов на которые будут разрешены зонные передачи (репликация на вторичные NS)
allow-query Список узлов, с которых разрешено обращаться к серверу. Если не задана, разрешено всем.
allow-notify Перечисленным серверам разрешает отправку уведомлений об изменениях в настройках зоны.
allow-recursion Задает список хостов, для которых разрешены рекурсивные запросы, остальным — будут разрешены итеративные. Если не задана, для всех рекурсивно.

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

Зоны bind

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

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

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

По умолчанию, сервер Bind хранит логи в файле
/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.

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

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

источник

Установка BIND9 DNS на CentOS

Заходим на сервер (для примера Master DNS будет ставиться на сервер с IP 10.10.10.10, Slave DNS — IP 20.20.20.20)
В начале проверим что система имеет все последние обновления.

Если не указать «-y» ключ, то придется отвечать на все вопросы установщика, а с ним все ответы ставятся автоматически по умолчанию.

Установить bind и bind-utils.

На примере моего домена «sibway.pro», для своего поменяйте все вхождения в примерах. Будем считать что master имеет IP 10.10.10.10, slave 20.20.20.20. Master и slave насколько я понимаю деление условное, так как и тот и другой сервер будет выполнять одни и те же функции, различие только в том что slave берет все данные с мастера.

Теперь отредактируем конфигурационный файл любым текстовым редактором, я использую vi так как он есть всегда в любой системе.

При установке bind, файл конфигурации ставится автоматически и нам надо только его отредактировать.

Комментируем строку, чтобы сервер мог слушать эфир со всех адресов и портов (наверное можно указать просто IP 10.10.10.10, но руки не дошли поэкспериментировать. Извне все равно все закрывает firewall).

Позволяем запрашивать сервер с любого адреса.

Позволяем брать информацию о доменах slave серверам.
Добавляем доменную зону, в тот же конфигурационный файл прописываем.

Конфигурирование доменных зон

В файле конфигурации мы указали файл sibway.pro.zone как файл конфигурации доменой зоны sibway.pro.
Проще всего взять какой-либо существующий и отредактировать до нужной конфигурации. Файлы можно разместить в поддиректории.

Вот простой пример того что необходимо прописать в доменной зоне.

Делаем рестар name сервера

Определяем чтобы name сервер стартовал при загрузки системы.

Теперь проверим как работает наш name сервер.

В ответе должен быть указан правильный IP запрошенного домена. Теперь сконфигурируем slave сервер.

Конфигурация slave name сервера

Конфигурирование slave name сервера проходит так же как и master за исключением двух моментов:

  1. При редактировании файла конфигурации named.conf надо указать какие доменные зоны slave
  2. Не надо добавлять доменные зоны, так как они обновятся с master сервера автоматически

В конфигурационном файле необходимо указать type slave и указать IP мастер сервера.

Не забываем стартовать сервер и включить его в автоматический старт при запуске системы.

Теперь у нас есть два сконфигуренных name сервера.
Осталось открыть порт в firewall
Отредактируем файл /etc/sysconfig/iptables:

Добавим следующие правила для 53 порта.

Не забудьте обновить этот файл на обоих серверах.
Теперь у нас есть два работающих name сервера.

источник

Установка и настройка 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»

источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *