Меню Рубрики

Установка bind сервера centos

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

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

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

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

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

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

# \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.

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

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

источник

Установка 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) достаточно обширная. Возможно я еще вернусь к ней.

источник

Установка BIND сервера на CentOS

В данной статье мы рассмотрим простой пример установки BIND на CentOS 6-версии. BIND – одна из популярных реализаций DNS-сервера, с открытым исходным кодом. DNS – сервера выполняют преобразование DNS-имени в IP-адрес и наоборот.
Перед началом установки хотелось бы отметить, что рекомендуется иметь хотя бы два сервера в облаке, чтобы обеспечить лучшую работоспособность в случае отказа работы одного из серверов. В нашем примере мы предполагаем настройку как первичного, так и вторичного сервера DNS.

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

Первое что следует сделать, проверить актуальность системы, и обновить в случае необходимости. Проверить наличие обновлений вы можете посредством команды yum.

После этого можно приступить в первичной установке BIND на сервер.

Первичная установка BIND на сервер

После установки сервера необходимо открыть конфигурационный файл для настройки конфигурации.

В конфигурации «options» вместо IP адреса 2.2.2.2 следует прописать адрес вашего второго сервера.

Из соображений безопасности мы закомментировали значение директивы «listen-on». Параметр обозначает, что сервер будет принимать обращения со всех доступных интерфейсов. Так же выставляем директиву в «recursion» в «no», так как это может послужить уязвимостью для DDOS-атак на сервер. В директиве «allow-transfer» указываем сервера, которым мы «доверяем», это наш второй сервер. Выставляем для директивы «allow-query» значение «any», это позволит получать надлежащий доступ к размещаемым доменным зонам.

Следующим шагом мы добавим запись для первого домена, в файле конфигурации named.conf

После сохранения файла, мы можем приступить к созданию первого файла доменной зоны. Создаем файл, используя доменное имя использованное выше, т.е. mydomain.com.zone:

Файл мы создаем, поэтому нам в нем следует указать кое-какие параметры. Подобно примеру, показанному ниже, вы должны заменить адреса 1.1.1.1 – это адрес вашего первого сервера (NS1), 2.2.2.2 – это адрес вашего второго сервера (NS2), и 3.3.3.3 – адрес, на котором находится веб-сервер. Дополнительные записи доменных имен вы можете добавлять в том же формате.

Теперь мы первично запускаем сервер named. Это может занять некоторое время, пока named сгенерирует файл rndc.key, создаваемый только при первом запуске.

Выключать DNS сервер при работе не рекомендуется, но бывает случаи, когда без этого не обойтись. Поэтому добавляем сервер в автозагрузку.

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

Если вы увидите характерную запись, с обозначением полномочий, то ваш сервер имен настроен правильно.

Конфигурация вторичного DNS сервера
После того как первичный сервер был настроен, приступим к настройке вторичного сервера. Как уже мы делали ранее, обновляем систему, до актуальной версии.

После этого устанавливаем BIND сервер, а так же его компоненты на вторичный сервер, аналогичным образом, как это делали ранее.

Далее, так же как и на первом сервере имен, создаем файл named.conf и прописываем в нем всё то же, за исключением директивы «allow transfer». Эта директива не нужна, т.к. это вторичный сервер.

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

После конфигурирования вторичной зоны, следует перезапустить сервер named. Как и говорилось ранее, на этом сервере так же будет создан файл rndc.key, это займет немного времени.

Добавляем файл сервер в автозагрузку:

Проверяем, что всё работает, заменяем 2.2.2.2 на адрес вашего вторичного сервера.

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

источник

Читайте также:  Установка гбц приора 21126