Содержание

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

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

Info

apt install bind9

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

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

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

Info
apt install dnsutils

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

...


Info
titleДанная статья применима к:
  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.7)
  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.6)
  • Astra Linux Special Edition РУСБ.10015-16 исп. 1 и исп. 2

  • Astra Linux Special Edition РУСБ.10265-01 (очередное обновление 8.1)

  • Astra Linux Common Edition 2.12



Info
titleСм. также:


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

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

Command

sudo apt install bind9

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

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

...

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

Важно: После настройки службы DNS не забудьте перенастроить службу DHCP,
чтобы клиентам выдавались правильные адреса серверов DNS.

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

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

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

  • сервер DNS с  адресом 192.168.32.211

Для создания кеширующего dns-сервера

  • раскомментируем в файле конфигурации /etc/bind/named.conf.options строки
Info
//  forwarders {
//      0.0.0.0;
//  };
  • указываем адреса используемых DNS-серверов (для примера взяты адреса DNS-серверов Google),
    и добавляем IP-адреса сетевых интерфейсов, по которым сервис должен принимать запросы
    (в примере - запросы с локального компьютера и с сетевого адреса 192.168.32.211):
Info
forwarders {
	8.8.8.8;
	8.8.4.4;
};
listen-on {
	127.0.0.1;
	192.168.32.211;
};
  • сохраняем файл
  • проверяем правильность конфигурации командой named-checkconf
  • и перезапускаем сервис
Info

service bind9 restart

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

Info

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-сервера в локальной сети позволяет организовать единое пространство имён для всех сетевых служб и пользователей.
В отличие от кеширующего сервера из предыдущего примера, этот сервер самостоятельно обрабатывает запросы, относящиеся к его зоне ответственности.

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

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

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

...

  •      — инструмент управления службой DNS.

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

Command
sudo apt install dnsutils

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

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

Многие устаревшие материалы в сети Интернет рекомендуют для работы bind создать учётную запись и группу named.
Этого делать не следует, так как при установке пакета будут автоматически созданы учётная запись пользователя и группа, причем не named, как написано в устаревших метериалах, а учетная запись bind и группа bind. 
Соответственно, сервис будет работать от имени bind:bind, а не от имени named:named, о чем следует помнить при работе с устаревшими примерами из сети Интернет.

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

Warning

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

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



/etc/bind/named.confОсновной файл конфигурации.
Этот файл изменять не следует, так как он содержит в себе только сслылки на остальные конфигурационные файлы (см. ниже)
/etc/bind/named.conf.optionsФайл для глобальных настроек службы
/etc/bind/named.conf.localФайл для настроек зоны DNS
/etc/bind/named.conf.default-zonesФайл конфигурации зон "по умолчанию".
В частности, этом файле содержатся ссылки на автоматически созданные файлы конфигурации зоны localhost /etc/bind/db.local и /etc/bind/127.db

Подробности о конфигурационных параметрах см. в руководстве 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 строки

Code Block
//  forwarders {

...

	8.8.4.4;
};

...

//      0.0.0.0;
//  };
и указать адреса серверов, которым нужно передавать запросы:
Code Block
forwarders {
	

...

192.

...

168.

...

32.1;

...


	

...

8.

...

8.

...

8.

...

8;

...

  • внесём информацию о домене в файл конфигурации /etc/bind/named.conf.local. Исходно в этом файле содержатся только комментарии. Добавляем следующие строки:
Info
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, путь к файлу данных
};
  • создаём каталог для хранения файлов данных, и копируем в созданный каталог образцы файлов данных:
Info

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:

...

	8.8.4.4;
};

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

Code Block
listen-on {
	127.0.0.1;
	192.168.32.100;
};
listen-on-v6 {
    none;
};
  • сохраняем файл конфигурации
  • проверяем правильность конфигурации командой (если команда не выдаёт никаких сообщений - значит ошибок нет)
Command
sudo named-checkconf
  • и перезапускаем сервис
Command

sudo systemctl restart bind9

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

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

Command
Titledig @localhost www.astralinux.ru | grep msec

;; Query time: 15 msec

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

Command
Titledig @localhost www.astralinux.ru | grep msec
  ;; 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 используем из предыдущего примера:
Code Block
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.local. Исходно в этом файле содержатся только комментарии. Добавляем следующие строки:
Code Block
zone "localnet.example.ru"    {                    # имя прямой зоны
    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, путь к файлу 

...

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

sudo mkdir /etc/bind/zones
sudo cp /etc/bind/db.local /etc/bind/zones/db.localnet.example.ru

...


sudo cp /etc/bind/db.127 /etc/bind/zones/db.32.168.192
sudo chown -R bind:bind /etc/bind/zones

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

...

  • :
Code Block
$TTL    604800
@       IN      

...

SOA     

...

dns.localnet.example.ru. admin.localnet.example.ru. (
                         

...

     3 

...

      

...

  • вносим измения в файл реверсивной зоны:

...

  ; 

...

Serial

...

 

...

 

...

 

...

 

...

 

...

       

...

      

...

     

...

 

...

 604800         ; 

...

Refresh
                          86400    

...

     

...

; 

...

Retry
                        

...

2419200         ; 

...

Expire
                         604800 

...

)       ; Negative 

...

Cache 

...

TTL
; name servers - NS records - определяем имена DNS-серверов
        IN      NS 

...

     

...

dns.localnet.example.ru.
; name servers - A records - определяем адреса компьютеров, сначала сервер(ы) DNS
dns.localnet.example.ru.           IN   

...

 

...

  A     

...

 192.168.32.211
; 192.168.32.0/24 - A records - а потом все остальные компьютер(ы) сети
host.localnet.example.ru.      

...

    IN  

...

    A  

...

    192.168.32.96
  • вносим измения в файл /etc/bind/zones/db.32.168.192 реверсивной зоны:
Code Block
$TTL    604800
@       IN      

...

SOA     

...

localnet.example.ru. 

...

admin.localnet.example.ru. (
      

...

      

...

     

...

   

...

 

...

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

...

named-checkconf

...

 

...

     

...

named-checkzone 32.168.192.in-addr.arpa /etc/bind/zones/db.32.168.192
  • и перезапускаем службу:
Info
systemctl restart bind9

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

Info
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.local, и перезапустим сервис.  Добавляемые строки выделены:

...

   3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         

...

604800 )   

...

 

...

   ; Negative Cache TTL ;

; name servers
      IN      NS      dns.localnet.example.ru.
; PTR Records
211 IN      

...

PTR     dns.localnet.example.ru.    ; 192.168.32.211
96  IN      PTR     host.localnet.example.ru.   ; 192.168.32.96
  • проверяем созданную конфигурацию с помощью соответствующих инструментов :
Command

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

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

systemctl restart bind9

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

Command
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.local, и перезапустим сервис.  Добавляемые строки выделены:
Code Block
zone "localnet.example.ru"    {                    
    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:
Code Block
forwarders {
	8.8.8.8;
	8.8.4.4;
};

listen-on {
	127.0.0.1;
	192.168.32.212; # изменён адрес интерфейса
};
  • вносим изменения в файл конфигурации /etc/bind/named.conf.local.
Code Block
zone "localnet.example.ru" {
    type slave;
    file "slaves/db.nyc3.example.ru";
    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; };  # адрес первого сервера

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

named-checkconf
systemctl restart bind9

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

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

SRV-записи располагаются в файлах зоны (в примере выше - это файл  /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:
Info
forwarders {
	8.8.8.8;
	8.8.4.4;
};
listen-on {
	127.0.0.1;
	192.168.32.212; # изменён адрес интерфейса
};
  • вносим изменения в файл конфигурации /etc/bind/named.conf.local.
Info
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; };  # адрес первого сервера
};
  • проверяем корректность конфигурации и перезапускаем сервис
Info
named-checkconf
systemctl restart bind9

Дальнейшие настройки.

В работе.

).

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

Code Block
_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)

Code Block
$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 не поддерживается сетью), в файл парамеров сервера можно добавить секцию:

Code Block
server ::/0 {
        bogus yes;
};


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

В работе

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

...

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