Установка пакета

Пакет bind9 входит в стандартные дистрибутивы ОС Astra Linux. Установку службы DNS bind9 можно выполнить из графического менеджера пакетов, или из командной строки:

При установке пакета bind9 будет автоматически уставновлен пакет инструментов командной строки bind9utils. Из этих инструментов следует отметить:

• named-checkconf  — инструмент проверки синтаксиса файлов конфигурации;
• named-checkzone — инструмент проверки файлов зон DNS;
• rndc                             — инструмент управления службой DNS.

В дополнение к пакетам bind9 и bind9utils, рекомендуем сразу установить пакет инструментов командной строки dnsutils, предназначенных для работы с DNS:

В составе пакета dnsutils будут установлены следующие инструменты:

• dig              - инструмент для опроса DNS-серверов и проверки их реакции
• nslookup - инструмент для проверки преобразования имен в IP-адреса
                        (далее в тексте используется термин "разрешение имён")
• nsupdate - инструмент для динамического обновления записей DNS

Настройка службы

Конфигурационные файлы BIND9 находятся в каталоге /etc/bind.
При установке BIND9 автоматически создаются следующие конфигурационные файлы:

Подробности о конфигурационных параметрах см. в руководстве man named.conf (5).

Настройка BIND9 для работы с Samba AD

Параметры настройки BIND9 и BIND9_DLZ для использования в качестве DNS-сервера домена см. BIND9 как DNS-сервер для Samba AD

Вариант простейшей настройки "Кеширующий сервер DNS"

Если у вас уже есть настроенный и доступный DNS-сервер (собственный, или сервер провайдера), создание в локальной сети дополнительного кеширующего DNS-сервера позволит без особых затрат ускорить работу с Интернет за счет ускорения разрешения имен по запросам различных сетевых служб и/или пользовательскими программами.

Установленная по умолчанию служба bind9 сразу настроена на выполнение роли кеширующего сервера, однако при этом запросы будут направляться к внешним серверам, входящим в т.н. список корневых DNS-серверов, что может быть не всегда оптимальным вариантом.

Для примера предположим, что у нас в сети уже есть настроенный сервер DNS с  IP-адресом 192.168.32.1, а новый сервер DNS установлен на сервере с IP-адресом 192.168.32.100. Для перенаправления запросов на ранее настроенный сервер (и, для примера, на серверы Google 8.8.8.8 и 4.4.4.4) следует раскомментировать в файле конфигурации  /etc/bind/named.conf.options внутри секции options строки

//  forwarders {
//      0.0.0.0;
//  };

forwarders {
	192.168.32.1;
	8.8.8.8;
	8.8.4.4;
};

Можно , но не обязательно, ещё добавить список интерфейсов компьютера, через которые сервис DNS должен принимать запросы, а также запретить работу по IPv6:

listen-on {
	127.0.0.1;
	192.168.32.100;
};
listen-on-v6 {
    none;
};

• сохраняем файл конфигурации
• проверяем правильность конфигурации командой (если команда не выдаёт никаких сообщений - значит ошибок нет)

• и перезапускаем сервис

Проверить работоспособность и эффективность кеширующего DNS-сервера можно с помощью инструмента dig:

Посылаем первый запрос:

В ответе на запрос видно, что время ответа составило 15 msec. Посылаем второй запрос например через через 5 секунд:

  ;; Query time: 0 msec

Время ответа на запрос при работающем кешировании должно существенно сократиться.

Вариант простой настройки "Локальный сервер DNS"

Это вариант настройки собственного полноценного DNS-сервера,

обслуживающего собственную локальную сеть (собственный DNS-домен). 
Создание DNS-сервера в локальной сети позволяет организовать единое пространство имён для всех сетевых служб и пользователей.
В отличие от кеширующего сервера из предыдущего примера, этот сервер самостоятельно обрабатывает запросы, относящиеся к его зоне ответственности.

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

• домен localnet.example.ru
• сервер DNS в этом домене с именем dns.localnet.example.ru и адресом 192.168.32.211
• компьютер host в этом домене с именем host.localnet.example.ru и адресом 192.168.32.96

Настройка конфигурации bind:

• на сервере DNS файл конфигурации /etc/bind/named.conf.options используем из предыдущего примера:

	192.168.32.211;
};

dnssec-validation False;

• внесём информацию о домене в файл конфигурации /etc/bind/named.conf.local. Исходно в этом файле содержатся только комментарии. Добавляем следующие строки:

    file "/etc/bind/zones/db.32.168.192";           # подсеть 192.168.32.0/24, путь к файлу данных
};

• создаём каталог для хранения файлов данных, и копируем в созданный каталог образцы файлов данных:

• вносим изменения в файл прямой зоны /etc/bind/zones/db.localnet.example.

• ru:

host.localnet.example.ru.          IN      A      192.168.32.96

• вносим измения в файл /etc/bind/zones/db.32.168.192 реверсивной зоны:

• проверяем созданную конфигурацию с помощью соответствующих инструментов :

• и перезапускаем службу:

Проверить работу сервера можно выполнив на сервере команду:

Добавляем резервный сервер.

Как и в примере ранее, предположим, что у нас есть

• домен localnet.example.ru
• сервер DNS в этом домене с именем dns.localnet.example.ru и адресом 192.168.32.211
• компьютер host в этом домене с именем host.localnet.example.ru и адресом 192.168.32.96
• и добавляется резервный сервер DNS dns2.localnet.example.ru и адресом 192.168.32.212

Для добавления резервного сервера

• на основном сервере DNS внесём информацию о резервном сервере в файл конфигурации /etc/bind/named.conf.local, и перезапустим сервис.  Добавляемые строки выделены:

вторичного сервера
};

• на резервном сервере DNS файл конфигурации /etc/bind/named.conf.options используем из предыдущего примера, но с одним отличием - резервный сервер слушает адрес 192.168.32.212:

forwarders {
	8.8.8.8;
	8.8.4.4;
};

listen-on {
	127.0.0.1;
	

• вносим изменения в файл конфигурации /etc/bind

• /named.conf.local.

zone "localnet.example.ru" {
    type slave;
    file "slaves/db.nyc3.example.ru";
    masters { 

};

• проверяем корректность конфигурации и перезапускаем сервис

Добавляем служебные записи (SRV-записи).

Служебная запись (SRV-запись) — стандарт в DNS, определяющий имя хоста и номер порта серверов для определённых служб. Определяется в RFC 2782.
Могут использоваться в различных протоколах, например, в Kerberos.

SRV-записи располагаются в файлах зоны (в примере выше - это файл  /etc/bind/zones/db.localnet.example.ru).

Формат записи: 

_service._proto.name TTL class SRV priority weight port target

Где:

• service - символьное имя сервиса;
• proto - транспортный протокол используемый сервисом, как правило _tcp или _udp;
• name - доменное имя, для которого эта запись действует;
• TTL - стандарт DNS, время жизни;
• class- стандарт DNS, поле класса (это всегда IN);
• priority - приоритет целевого хоста, более низкое значение означает более предпочтительный;
• weight - относительный вес для записей с одинаковым приоритетом;
• port - Порт TCP или UDP, на котором работает сервис;.
• target - канонические имя машины, предоставляющей сервис.

Примеры служебных записей (Kerberos и NTP)

$ORIGIN samdom.example.ru.
$TTL 1h
@ IN SOA dns.samdom.example.ru. root.samdom.example.ru. (

	2 ; Serial
	604800 ; Refresh
	86400 ; Retry
	2419200 ; Expire
	604800 ) ; Negative Cache TTL
;
	IN NS dns.samdom.example.ru.
@ IN AAAA ::1
dns.samdom.example.ru. IN A 10.0.2.254
dhcp.samdom.example.ru. IN A 10.0.2.254
kdc.samdom.example.ru. IN A 10.0.2.253
ntp.samdom.example.ru. IN A 10.0.2.253
;kerberos
_kerberos TXT "SAMDOM.EXAMPLE.RU"
kerberos CNAME kdc
_kerberos._udp SRV 0 0 88 kdc
			SRV 0 0 88 kdc
			SRV 0 0 88 kdc
_kerberos-master._udp SRV 0 0 88 kdc
_kerberos-adm._tcp SRV 0 0 749 kdc
_kpasswd._udp SRV 0 0 464 kdc
;ntp server
_ntp._udp IN SRV 0 100 123 ntp.samdom.example.ru.

Запрет опроса IPv6-cерверов

Для того, чтобы сервер не тратил ресурсы на попытки опроса недоступных корневых серверов, работающих по протоколу IPv6 (например, когда протокол IPv6 не поддерживается сетью), в файл парамеров сервера можно добавить секцию:

server ::/0 {
        bogus yes;
};

Включение аутентификации по ключам.

В работе

Настройка клиентов

Клиентским компьютерам после стандартной установки ОС настройка не требуется.