DNS (Domain Name System — система доменных имён) — используется для получения IP-адреса по имени хоста или по URL. Например, если мы введём www.unixmen.com в браузере, DNS-сервер преобразует доменное имя в связанный с ним IP-адрес. Поскольку IP-адрес запомнить трудно, DNS-серверы используются для перевода имён хостов, таких как www.unixmen.com, в 173.xxx.xx.xx. Таким образом, доменное имя запомнить намного легче, чем IP-адрес.
Данное руководство поможет вам настроить локальный DNS-сервер на вашей системе CentOS 7 (также применимо для RHEL и Scientific Linux 7).
Установка DNS-сервера
План действий
В этом уроке мы будем использовать три узла. Один будет действовать как основной DNS-сервер, другой как дополнительный, а последний будет нашим DNS-клиентом. Все они приведены ниже.
Основной (главный) DNS-сервер:
Дополнительный (вторичный) DNS-сервер:
Клиент:
Настройка основного (главного) DNS-сервера
Установите на ваш сервер пакеты bind9.
1. Настройка DNS-сервера
Отредактируйте файл ‘/etc/named.conf’.
Теперь добавьте следующие, выделенные жирным шрифтом, строчки:
2. Создание файлов зон
Создайте файлы прямой и обратной зоны, которые мы упоминали в файле ‘/etc/named.conf’.
2.1 Создание прямой зоны
В директории /var/named создайте файл forward.unixmen.
Допишите следующие строчки:
На этом создание прямой зоны завершено, переходим далее.
2.2 Создание обратной зоны
В директории /var/named создайте файл reverse.unixmen.
Добавьте следующие строчки:
3. Запуск DNS-сервера
Включите и запустите службу DNS:
4. Настройка файрвола
Нужно при помощи файрвола разрешить DNS-серверу использование порта 53.
5. Перезапуск файрвола
6. Настройка разрешений, прав доступа и SELinux
Пропишите следующие команды одну за другой:
7. Проверка на ошибки
Теперь нужно убедиться в корректности выполнения проделанных нами пунктов.
Проверьте стандартный файл конфигурации DNS:
Если ничего не возвращается, ваш файл конфигурации настроен корректно.
Далее, проверьте прямую зону:
Затем, проверьте обратную зону:
Добавьте данные DNS-сервера в файл конфигурации сетевого интерфейса.
Отредактируйте файл ‘/etc/resolv.conf’,
Добавьте имя сервера и IP-адрес:
Сохраните и закройте файл.
Перезагрузите сетевую службу:
8. Тестирование основного DNS-сервера
Теперь основной DNS-сервер готов к использованию.
Настало время настройки дополнительного DNS-сервера.
Установка дополнительного DNS-сервера
Установите пакеты bind при помощи следующей команды:
1. Настройка вторичного DNS-сервера
Отредактируйте файл /etc/named.conf:
Добавьте следующие, выделенные жирным шрифтом, строчки:
2. Запуск DNS-службы
Теперь прямая и обратная зоны автоматически копируются с главного DNS-сервера на дополнительный DNS-сервер (расположенный в директории: ‘/var/named/slaves/’).
3. Заполнение данных DNS-сервера
Добавьте данные DNS-сервера в файл конфигурации сетевого интерфейса.
Отредактируйте файл ‘/etc/resolv.conf’,
Добавьте имя сервера и IP-адрес:
Сохраните и закройте файл.
Перезапустите сетевую службу:
4. Настройка файрвола
Нам нужно при помощи файрвола разрешить DNS-серверу использовать порт 53.
5. Перезапуск файрвола
Перезапустить файрвол можно при помощи следующей команды:
6. Настройка разрешений, прав доступа и SELinux
Пропишите следующие команды одну за другой:
7. Тестирование вторичного DNS-сервера
Настройка клиентской составляющей
Добавьте сведения о DNS-сервере в файл ‘/etc/resolv.conf’ во всех клиентских системах.
Перезапустите сетевую службу или перезагрузите систему.
Тестирование DNS-сервера
И теперь, наконец-таки, вы можете протестировать ваш DNS-сервер, используя любую из следующих команд:
На этом всё. Основной и дополнительный DNS-серверы готовы к использованию.
Спасибо за внимание! Надеемся, что данная статья помогла вам.
Что такое 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 <>.
| Опции | Описания |
|---|---|
| directory | Указывает рабочий каталог сервера bind. Если не указан, /var/named |
| forwarders | Перечисляет серверы, на которые будет переведен запрос, в случае, если наш сервер не сможет его обработать (нет соответствующей зоны.) |
| forward | Переопределяет способ обработки запроса. Принимает два значения — ONLY или FIRST. Первое указывает на то, что сервер не будет пытаться искать совпадения среди локальных зон. Второе — сервер сначала будет перенаправлять запрос и если он не будет успешно обработан, искать соответствия во внутренней базе. |
| listen-on | На каких интерфейсах будет слушать bind |
| allow-transfer | Указание на список серверов на которые будут разрешены зонные передачи (репликация на вторичные NS) |
| allow-query | Список узлов, с которых разрешено обращаться к серверу. Если не задана, разрешено всем. |
| allow-notify | Перечисленным серверам разрешает отправку уведомлений об изменениях в настройках зоны. |
| allow-recursion | Задает список хостов, для которых разрешены рекурсивные запросы, остальным — будут разрешены итеративные. Если не задана, для всех рекурсивно. |
Пример глобальных настроек
Зоны bind
Для возможности искать соответствия в собственной базе доменов, необходимо создать и настроить зоны. Существуют следующие типы зон:
- Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind.
- Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind.
- Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
- Кэширующая или 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.
Напротив, чтобы отключить ведение лога, в конфигурационном файле должна быть настройка:
После изменения конфигурационного файла перезапускаем сервис:
Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в 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 может принимать следующие значения:
| 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 достаточно много. Вот мой перевод полного списка с описаниями:
| 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) достаточно обширная. Возможно я еще вернусь к ней.
