Установка пакета
Пакет bind9
входит в стандартный дистрибутив ОСОН Смоленск и доступен через репозиторий ОСОН Орёл.
Установку службы DNS BIND9 можно выполнить из графического менеджера пакетов, или из командной строки:
apt install bind9
При установке пакета bind9
будет автоматически уставновлен пакет инструментов командной строки bind9utils
. Из этих инструментов следует отметить:
- named-checkconf — инструмент проверки синтаксиса файлов конфигурации
- named-checkzone — инструмент проверки файлов зон DNS
- rndc — инструмент управления службой DNS
В дополнение к пакетам bind9
и bind9utils
, рекомендуем сразу установить пакет инструментов командной строки dnsutils
, предназначенных для работы с DNS:
В составе пакета dnsutils
будут установлены следующие инструменты:
- dig - инструмент для опроса DNS-серверов и проверки их реакции
- nslookup - инструмент для проверки преобразования имен в IP-адреса
(далее в тексте используется термин "разрешение имён") - nsupdate - инструмент для динамического обновления записей DNS
Многие материалы в сети Интернет рекомендуют для работы bind создать учётную запись и группу named.
Этого делать не следует, при установке пакета будут автоматически созданы учётная запись пользователя bind и группа bind.
И сервис будет работать от имени bind:bind, а не от имени named:named, о чем следует помнить при работе с примерами из Интернет.
Настройка службы
После настройки службы DNS не забудьте перенастроить службу DHCP,
чтобы клиентам автоматически выдавались правильные адреса серверов DNS.
Вариант простейшей настройки "Кеширующий сервер DNS"
Если у вас уже есть настроенный и доступный DNS-сервер (собственный, или сервер провайдера), создание в локальной сети кеширующего DNS-сервера позволит без особых затрат ускорить работу с Интернет за счет ускорения разрешения имен по запросам различных сетевых служб и/или пользовательскими программами.
Для примера предположим, что у нас есть:
- сервер DNS с адресом
192.168.32.211
Для создания кеширующего dns-сервера
- раскомментируем в файле конфигурации
/etc/bind/named.conf.options
строки
// forwarders { // 0.0.0.0; // };
- указываем адреса используемых DNS-серверов, которым нужно передавать запросы (для примера взяты адреса DNS-серверов Google)
- и, в этом примере, отключаем авторизацию dnssec (использование dnssec будет рассмотрено позже)
forwarders { 8.8.8.8;
8.8.4.4;
};dnssec-validation False;
Можно , но не обязательно, ещё добавить список интерфейсов компьютера, через которые которые служба DNS должна принимать запросы:
listen-on {
127.0.0.1;
192.168.1.1;
};
- сохраняем файл конфигурации
- проверяем правильность конфигурации командой (если команда не выдаёт никаких сообщений - значит ошибок нет)
- и перезапускаем сервис
service bind9 restart
Проверить работоспособность и эффективность кеширующего DNS-сервера можно с помощью инструмента dig
:
dig @localhost www.astralinux.ru | grep msec # посылаем первый запрос
;; Query time: 15 msec
dig @localhost www.astralinux.ru | grep msec # посылаем второй запрос например через через 5 сек
;; Query time: 0 msec
Вариант простой настройки "Локальный сервер DNS"
Это вариант настройки собственного полноценного DNS-сервера, обеслуживающего собственную локальную сеть (собственный DNS-домен).
Создание DNS-сервера в локальной сети позволяет организовать единое пространство имён для всех сетевых служб и пользователей.
В отличие от кеширующего сервера из предыдущего примера, этот сервер самостоятельно обрабатывает запросы, относящиеся к его зоне ответственности.
Для примера, предположим, что у нас есть
- домен l
ocalnet.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
используем из предыдущего примера:
forwarders { 8.8.8.8;
8.8.4.4; };
listen-on { 127.0.0.1;
192.168.32.211; };
dnssec-validation False;
- внесём информацию о домене в файл конфигурации
/etc/bind/named.conf.loca
l. Исходно в этом файле содержатся только комментарии. Добавляем следующие строки:
zone "localnet.example.com" { # имя прямой зоны
type master; # тип master указывает, что запросы относительно этой зоны будут обрабатываться этим сервером, и перенаправляться не будут
file "/etc/bind/zones/db.localnet.example.ru"; # путь к файлу данных прямой зоны
};
zone "32.168.192.in-addr.arpa" { # имя реверсивной зоны. Имя реверсивной зоны формируется из адреса сети, с обратным порядком чисел.
type master;
# тип master указывает, что запросы, относящиеся к этой зоне, будут обрабатываться этим сервером, и перенаправляться не будут
file "/etc/bind/zones/db.32.168.192"; # подсеть 192.168.32.0/24, путь к файлу данных
};
- создаём каталог для хранения файлов данных, и копируем в созданный каталог образцы файлов данных:
mkdir /etc/bind/zones
cp /etc/bind/db.local /etc/bind/zones/db.localnet.example.ru
cp /etc/bind/db.127 /etc/bind/zones/db.32.168.192
- вносим изменения в файл прямой зоны /etc/bind/zones/db.localnet.example.com:
$TTL 604800
@ IN SOA localhost. root.localhost. (
@ IN SOA
dns
.
localnet
.example.
ru
. admin.
localnet
.example.
ru
. (
2 ; Serial
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;@ IN NS localhost.
; name servers - NS records - определяем имена DNS-серверов
IN NSdns
.
localnet
.example.
ru
.
@ IN A 127.0.0.1
; name servers - A records - определяем адреса компьютеров, сначала сервер(ы) DNS
dns
.
localnet
.example.
ru
. IN A
192.168.32.211
@ IN AAAA ::1
; 1
92.
1
6
8.
32
.0/
24
- A records - а потом все остальные компьютер(ы) сети
host.localnet
.example.
ru
. IN A
192.168.32.96
- вносим измения в файл /etc/bind/zones/db.32.168.192 реверсивной зоны:
$TTL 604800
@ IN SOA localhost. root.localhost. (
@ IN SOA
localnet
.example.
ru
. admin.
localnet
.example.
ru
. (
1 ; Serial
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
; name servers
IN NS
dns
.
localnet
.example.
ru
.
1.0.0 IN PTR localhost. ; delete this line
; PTR Records
211
IN PTR
dns
.
localnet
.example.
ru
. ;
192.168.32
.
2
11
96
IN PTR host.
localnet
.example.
ru
. ;
192.168.32
.
96
- проверяем созданную конфигурацию с помощью соответствующих инструментов :
named-checkconf
named-checkzone localnet.example.ru /etc/bind/zones/db.
localnet.example.ru
named-checkzone 32.168.192.in-addr.arpa /etc/bind/zones/db.32.168.192
- и перезапускаем службу:
systemctl restart bind9
Проверить работу сервера можно выполнив на сервере команду:
dig @localhost host.localnet.example.ru
Добавляем резервный сервер.
Как и в примере ранее, предположим, что у нас есть
- домен
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.loca
l, и перезапустим сервис. Добавляемые строки выделены:
zone "localnet.example.com" {
type master;
file "/etc/bind/zones/db.localnet.example.ru";
allow-transfer { 192.168.32.212; }; # добавлен адрес вторичного сервера
};
zone "32.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.32.168.192";
allow-transfer { 192.168.32.212; }; # добавлен адрес вторичного сервера
};
- на резервном сервере 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;
192.168.32.212; # изменён адрес интерфейса };
- вносим изменения в файл конфигурации
/etc/bind/named.conf.loca
l.
zone "localnet.example.ru" {
type slave;
file "slaves/db.nyc3.example.com";
masters { 192.168.32.211; }; # адрес первого сервера
};
zone "32.168.192.in-addr.arpa" {
type slave;
file "slaves/db.32.168.192";
masters { 192.168.32.211; }; # адрес первого сервера
};
- проверяем корректность конфигурации и перезапускаем сервис
named-checkconf
systemctl restart bind9
Добавляем служебные записи (SRV-записи).
Служебная запись (SRV-запись) — стандарт в DNS, определяющий имя хоста и номер порта серверов для определённых служб. Определяется в RFC 2782.
Могут использоваться в различных протоколах, например, в Kerberos.
SRV-записи располагаются в файлах зоны (в примере выше - это файл /etc/bind/zones/db.localnet.example.ru).
Формат записи:
Где:
- service - символьное имя сервиса;
- proto - транспортный протокол используемый сервисом, как правило _tcp или _udp;
- name - доменное имя, для которого эта запись действует;
- TTL - стандарт DNS, время жизни;
- class- стандарт DNS, поле класса (это всегда IN);
- priority - приоритет целевого хоста, более низкое значение означает более предпочтительный;
- weight - относительный вес для записей с одинаковым приоритетом;
- port - Порт TCP или UDP, на котором работает сервис;.
- target - канонические имя машины, предоставляющей сервис.
Примеры служебных записей (Kerberos и NTP)
$ORIGIN localdomain.example.com.
$TTL 1h
@ IN SOA dns.localdomain.example.com. root.localdomain.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS dns.localdomain.example.com.
@ IN AAAA ::1
dns.localdomain.example.com. IN A 10.0.2.254
dhcp.localdomain.example.com. IN A 10.0.2.254
kdc.localdomain.example.com. IN A 10.0.2.253
ntp.localdomain.example.com. IN A 10.0.2.253
;kerberos
_kerberos TXT "LOCALDOMAIN.EXAMPLE.COM"
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.localhost.example.com.
Включение аутентификации по ключам.
В работе
Настройка клиентов
В работе.