Настройка DNS сервера (BIND9)

Что такое BIND9?

BIND (Berkeley Internet Name Domain) - это реализация протокола DNS. В BIND 9 было сделано несколько серьезных усовершенствований, включая поддержку IPv6, более гибкую конфигурацию и управление, улучшенную производительность кэширования, поддержку EDNS0 для больших ответов UDP и улучшенное управление динамически назначаемыми IP-адресами.

BIND является наиболее широко используемым программным обеспечением сервера имен в Интернете. Он поддерживает ряд различных протоколов службы доменных имен, включая BIND4 (оригинальный Berkeley Internet Name Domain, версия 4), BIND8 (исторический преемник BIND4), а также службы DNS для IPv6 посредством двух отдельных реализаций: одна основана на демоне, а другая называется lwres (light-weight resolver).

Установка DNS сервера BIND9 для Ubuntu/Debian

Обновление вашей системы

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

sudo apt-get update && sudo apt-get upgrade -y

Флаг -y будет автоматически отвечать "да" на все подтверждения, которые могут быть заданы.

Команда apt-get update обновит списки пакетов сервера. При использовании команды apt-get upgrade все установленные на сервере пакеты будут обновлены.

Это займет некоторое время в зависимости от скорости вашего сетевого соединения и количества устанавливаемых обновлений.

Установка BIND9

Теперь, когда ваша система обновлена, вы можете приступить к установке DNS-сервера - BIND. Это будет сделано путем установки нескольких новых пакетов:

sudo apt install bind9 bind9utils bind9-doc

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

BIND9 - это программное обеспечение DNS-сервера.

bind9utils - это утилиты для управления конфигурацией BIND, а также название команды, используемой для управления BIND из командной строки.

bind9-doc - это пакет документации для программного обеспечения BIND.

Проверка установки сервера DNS

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

sudo named -v

Приведенная выше команда покажет установленную версию BIND и его зависимостей.

BIND запускается автоматически при установке. Вы можете проверить его состояние с помощью команды systemctl, как показано ниже:

sudo systemctl status bind9

Команда выше даст вам более подробное представление о функциях BIND на вашем сервере, таких как активное время, количество зон и т.д.

Если вы захотите запустить, остановить или перезапустить BIND, просто выполните приведенные ниже команды:

sudo service bind9 start

sudo service bind9 stop

sudo service bind9 restart

По умолчанию сервер BIND будет работать от имени пользователя и группы bind. Это делает его достаточно безопасным, поскольку любые изменения в файлах зон разрешены только для этого пользователя. По умолчанию сервер BIND слушает DNS-запросы на порту 53. При желании вы можете изменить этот порт в файле named.conf. Выполните следующую команду, чтобы узнать, какой порт прослушивает ваш сервер BIND:

sudo netstat -lnptu | grep named

Приведенная выше команда показывает, что названный демон в настоящее время запущен и прослушивает порт 53 UDP. Используйте эту информацию, чтобы проверить, правильно ли вы используете номер порта.

Если ваш сервер не использует порт 53, вы можете исправить это, отредактировав /etc/bind/ named.conf.local и изменив номер порта на любой другой. Вы также можете изменить имя файла журнала сервера, отредактировав /etc/bind/ named.conf.default-zones и добавив утверждения логирования в директиве options.

Настройка BIND9

Теперь, когда BIND9 установлен на вашем сервере, пришло время приступить к его настройке.

Каталог конфигурации для BIND находится в каталоге /etc/bind. В этом каталоге есть несколько важных файлов:

Файл с именем 'named.conf' - это основной конфигурационный файл, который содержит множество комментариев для пояснения каждого раздела.

Следующий конфигурационный файл, который мы будем редактировать, находится по адресу /etc/bind/named.conf.local. Этот файл содержит всю вашу сетевую информацию о сервере и зонах, которые вы хотите разрешать локально (с серверов имен).

Файл named.conf.default-zones находится по адресу /etc/bind/named.conf.default-zones. Этот файл содержит информацию о сервере для зон, используемых BIND, когда ему явно не указано использовать другую зону. Другими словами, зоны, которые включены.

Итак, давайте начнем с базовой конфигурации.

Настройка просушиваемых интерфейсов (IP-адресов)

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

Изменим это, отредактировав файл конфигурации named.conf.options

sudo nano /etc/bind/named.conf.options

Установим прослушивание только конкретного сетевого интерфейса, задокументировав не нужные нам опции

Сохраните и закройте файл, когда закончите. Затем перезапустите демон BIND9 командой ниже:

sudo service bind9 restart

Теперь мы разрешили BIND9 прослушивать только определенный интерфейс.

Создание зон прямого просмотра (домен -> IP)

Зоны прямого просмотра являются наиболее распространенным видом файлов зон. Они сопоставляют доменное имя с IP-адресом и используются при преобразовании доменных имен в IP-адреса для электронной почты, веб-страниц и т.д. Следующим шагом будет создание файла зоны прямого просмотра.

Мы отредактируем файл "/etc/bind/named.conf.local", чтобы объявить зону прямого поиска. Для единственной цели этого руководства мы объявим домен под названием "test.local" и укажем его IP-адрес сервера.

Если вы планируете разрешать внешние домены из своей сети, на вашем сервере должен быть установлен действительный IP-адрес с доступом в интернет.

Теперь мы отредактируем файл "/etc/bind/named.conf.local", чтобы объявить зону прямого поиска:

sudo nano /etc/bind/named.conf.local

Добавьте следующее в конец файла:

zone "test.local" {
  type master;
  file "/etc/bind/db.test.local";
//allow-transfer {xxx.xxx.xxx.xxx;}; // Secondary DNS server of the hoster
};

Тип "master". Это файл зоны ведущего домена. Параметр типа может быть установлен в "slave", если вы размещаете прямую или обратную зону только для авторизации и не хотите разрешать динамические обновления.

"/etc/bind/db.domaine.com" - это файл, содержащий записи для домена "test.local" с полным путем.

allow-transfer {xxx.xxx.xxx.xxx;}. Это необходимо, чтобы разрешить передачу зоны на вторичный DNS-сервер хостера, потому что если ваш хостинг-провайдер не разрешит вам это сделать, вы не сможете обновить ее онлайн с помощью команды "rndc reload" на localhost. xxx.xxx.xxx.xxx.xxx; IP-адрес вторичного DNS-сервера (Name Servers), который находится у вашего хостинг-провайдера.

Сохраните и закройте файл, когда закончите.

Теперь мы создадим файл для каждой зоны, объявленной выше:

sudo nano /etc/bind/db.test.local

Заполните файл следующим образом

;
; BIND data file for local loopback interface
;
$TTL 604800

@ IN SOA ns1.test.local. root.test.local. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Commentout below three lines
;@ IN NS localhost.
;@ IN A 127.0.0.1
;@ IN AAAA ::1

;Name Server Information
@ IN NS ns1.test.local.
;IP address of Name Server
ns1 IN A 192.168.0.10
;Mail Exchanger
test.local. IN MX 10 mail.test.local.
;A – Record HostName To IP Address
www IN A 192.168.0.100
mail IN A 192.168.0.150

В этом файле замените значения test.local на ваше доменное имя, за которым следует точка (.) Это необходимо, и это НЕ является ошибкой.

Замените "192.168.0" на ваш публичный IP-адрес, за которым следует точка (.) Это необходимо для того, чтобы сервер был доступен из интернета.

Не забудьте сохранить и закрыть файл после завершения работы.

Создание зон обратного поиска (IP -> домен)

Зоны обратного поиска используются для сопоставления IP-адреса с доменным именем и обычно требуются для отправки электронной почты. Следующим шагом будет создание файла обратной зоны.

Имя обратной зоны состоит из идентификатора сети (обратного), за которым следует ".in-addr.arpa".

Например:

Если сервер имеет IP-адрес "10.20.30.40", его сетевой ID будет "10.20.30", а имя обратной зоны будет "40.20.10.in-addr.arpa".

Теперь отредактируем файл "/etc/bind/named.conf.local", чтобы объявить обратную зону:

sudo nano /etc/bind/named.conf.local

Затем добавьте в файл следующее:

zone "30.20.10.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.10";
};

Затем создадим файл для объявленной выше зоны:

sudo nano /etc/bind/db.10

Затем заполним файл следующим образом:

;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA test.local. root.test.local. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
;@ IN NS localhost.
;1.0.0 IN PTR localhost.
;Name Server Information
@ IN NS ns1.test.local.
;Reverse lookup for Name Server
10 IN PTR ns1.test.local.
;PTR Record IP address to HostName
100 IN PTR www.test.local.
150 IN PTR mail.test.local.

Проверка синтаксиса конфигурации BIND

Теперь мы проверим синтаксис конфигурации в каждом файле на наличие ошибок. Для этого у нас будет запрос named со следующей командой:

sudo named-checkconf

Если ошибок нет, эта команда вернется в пустую оболочку:

Применение настроек и проверка

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

sudo service bind9 restart

для проверки работы, введите команду nslookup со следующим синтаксисом

nslookup [домен] [ip-dns-сервера]

к примеру

nslookup www.test.local 192.168.153.129

Для обратной зоны (PTR) синтаксис аналогичный

nslookup 10.20.30.100 192.168.153.129

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

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

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

# rpm -qa bind*
 bind-libs-lite-9.9.4-14.el7.x86_64
 bind-license-9.9.4-14.el7.noarch

Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

# yum -y install bind bind-utils bind-chroot

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

# systemctl start named-chroot
# systemctl enable named-chroot
ln -s '/usr/lib/systemd/system/named-chroot.service' '/etc/systemd/system/multi-user.target.wants/named-chroot.service'

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

# ls -l /var/named/chroot/etc

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

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

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

# mcedit /var/named/chroot/etc/named.conf

options {
listen-on port 53 { any; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
allow-query { 127.0.0.1; 192.168.7.0/24; };
recursion yes;
allow-recursion { 127.0.0.1; 192.168.7.0/24; };
forwarders { 8.8.8.8; };
version "DNS Server";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
dnssec-enable no;
dnssec-validation no;
};

zone "." IN {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

logging {
channel default_file {
file "/var/log/named/default.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
category default { default_file; };
};

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

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";	Скрываем версию бинда, вместо этого выводим указанную строку.

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";

Скрываем версию бинда, вместо этого выводим указанную строку.

Не забудьте отредактировать правила фаервола для корректной работы DNS сервера - открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше

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

# cd /var/named/chroot/var/log && mkdir named && chown named. named

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

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

# mcedit /var/named/chroot/var/named/site1.ru.zone

$TTL 86400
@        IN     SOA     site1.ru. site1.ru.local. (
                        2015092502
                        43200
                        3600
                        3600000
                        2592000 )

        IN NS ns1.site1.ru.
        IN NS ns2.site1.ru.
        IN A 192.168.7.254
        IN MX 10 mx.site1.ru.

gate    IN A 192.168.7.254
mx      IN A 192.168.7.250
ns1     IN A 192.168.7.235
ns2     IN A 192.168.7.231

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

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

# chown root:named /var/named/chroot/var/named/site1.ru.zone
# chmod 0640 /var/named/chroot/var/named/site1.ru.zone

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

zone "site1.ru" {
 type master;
 file "site1.ru.zone";
};

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

# rndc reconfig

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

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

zone "site.ru" IN {
 type slave;
 masters { 10.1.3.4; };
 file "site.ru.zone";
};

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

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

drwxrx--- 6 root named 164 Jan 6 06:06 named

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

drwxrwx--- 6 root named 164 Jan 6 06:06 named

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

dumping master file: tmp-7Swr6EZpcd: open: permission denied

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

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

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

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

channel general {
file "/var/log/named/general.log" versions 3 size 5m;
severity dynamic;
print-time yes;

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

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

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, которое лично меня устраивает.

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

category general { general; };

Категорий у днс сервера 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.

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 добавить следующую конструкцию:

logging {

channel default {
file "/var/log/named/default.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel general {
file "/var/log/named/general.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel database {
file "/var/log/named/database.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel security {
file "/var/log/named/security.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel config {
file "/var/log/named/config.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel resolver {
file "/var/log/named/resolver.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel xfer-in {
file "/var/log/named/xfer-in.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel xfer-out {
file "/var/log/named/xfer-out.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel notify {
file "/var/log/named/notify.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel client {
file "/var/log/named/client.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel unmatched {
file "/var/log/named/unmatched.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel network {
file "/var/log/named/network.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel update {
file "/var/log/named/update.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel update-security {
file "/var/log/named/update-security.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel queries {
file "/var/log/named/queries.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel query-errors {
file "/var/log/named/query-errors.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel dispatch {
file "/var/log/named/dispatch.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel dnssec {
file "/var/log/named/dnssec.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel lame-servers {
file "/var/log/named/lame-servers.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel delegation-only {
file "/var/log/named/delegation-only.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel edns-disabled {
file "/var/log/named/edns-disabled.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel rpz {
file "/var/log/named/rpz.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

channel rate-limit {
file "/var/log/named/rate-limit.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};

category default { default; };
category general { general; };
category database { database; };
category security { security; };
category config { config; };
category resolver { resolver; };
category xfer-in { xfer-in; };
category xfer-out { xfer-out; };
category notify { notify; };
category client { client; };
category unmatched { unmatched; };
category network { network; };
category update { update; };
category update-security { update-security; };
category queries { queries; };
category query-errors { query-errors; };
category dispatch { dispatch; };
category dnssec { dnssec; };
category lame-servers { lame-servers; };
category delegation-only { delegation-only; };
category edns-disabled { edns-disabled; };
category rpz { rpz; };
category rate-limit { rate-limit; };
};

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

querylog yes;

Перезапускаем bind:

# systemctl restart named-chroot.service

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

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

# cd /var/named/chroot/var/log/named
# ls -l

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

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246)
26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

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

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

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

Заключение

DNS - одна из самых важных служб на сервере. Все ее используют. Она нужна всем, и, в конце концов, вы же не хотите, чтобы ваши машины потерялись в сети, потому что не могут найти друг друга. Эта статья содержит руководство по настройке внутреннего DNS-сервера на Debian с использованием программного обеспечения сервера имён BIND (BIND9).

Что такое DNS-записи домена? Типы ресурсных записей 🌐Eternalhost

PreviousПротокол DNS NextПротокол NTP

Last updated 1 year ago