Руководство по bind

Данное руководство описывает установку и конфигурацию BIND для домена и локальной сети.

Введение

BIND — самый часто используемый DNS-сервер в Интернете. Данное руководство объяснит, как настроить BIND для домена, используя различные конфигурации, одну для локальной сети, и одну для остального мира. Для этого будут использованы два вида (views):

1. Вид для внутренней зоны (локальная сеть).
2. Вид для внешней зоны (остальной мир).

Данные, которые будут использоваться в примерах

Конфигурация BIND

Установка

Сначала, установите net-dns/bind.

Настройка /etc/bind/named.conf

Сначала нужно сконфигурировать /etc/bind/named.conf. Первым шагом будет указание корневого каталога bind, порт, который будет прослушиваться, PID-файл и строка для протокола IPv6.

ФАЙЛ /etc/bind/named.confРаздел options

options {
        directory "/var/bind";
  
        listen-on-v6 { none; };
        listen-on port 53 { 127.0.0.1; ВАШ_ЛОКАЛЬНЫЙ_IP; };
  
        pid-file "/var/run/named/named.pid";
};

Вторая часть named.conf — внутренний вид, используемый для нашей локальной сети.

ФАЙЛ /etc/bind/named.confВид для внутренней сети (internal view)

view "internal" {
        match-clients { ВАША_ЛОКАЛЬНАЯ_СЕТЬ; localhost; };
        recursion yes;
  
        zone "ВАШ_ДОМЕН" {
                type master;
                file "pri/ВАШ_ДОМЕН.internal";
                allow-transfer { any; };
        };
};

Третья часть named.conf — внешний вид, используемый для разрешения наших доменных имен для остального мира, и разрешения всех остальных доменных имен для нас (и всех, кто захочет использовать наш DNS сервер).

ФАЙЛ /etc/bind/named.confВид для внешней сети (external view)

view "external" {
        match-clients { any; };
        recursion no;
  
        zone "." IN {
                type hint;
                file "named.ca";
        };
  
        zone "127.in-addr.arpa" IN {
                type master;
                file "pri/127.zone";
                allow-update { none; };
                notify no;
        };
  
        zone "ВАШ_ДОМЕН" {
                type master;
                file "pri/ВАШ_ДОМЕН.external";
                allow-query { any; };
                allow-transfer { ПОДЧИНЕННЫЙ_DNS_СЕРВЕР; };
        };
};

Последняя часть named.conf это политика логов.

ФАЙЛ /etc/bind/named.confПолитика логов

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

Каталог /var/log/named/ должен существовать и принадлежать named:

Создание файла внутренней зоны

Мы используем имена хостов и IP-адреса из примера сети, показанного ниже. Заметьте, что почти все (но не все) доменные имена оканчиваются на «.» (точку).

ФАЙЛ /var/bind/pri/ВАШ_ДОМЕН.internal

$TTL 2d
@	IN SOA	ns.ВАШ_ДОМЕН.	АДМИНИСТРАТОР.ВАШ_ДОМЕН. (
	ИЗМЕНЕНИЕ	; serial
	3h	; refresh
	1h	; retry
	1w	; expiry
	1d )	; minimum
  
ВАШ_ДОМЕН.		IN MX	0 mail.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN TXT	"v=spf1 ip4:ВАШ_ПУБЛИЧНЫЙ_IP/32 mx ptr mx:mail.ВАШ_ДОМЕН ~all"
ВАШ_ДОМЕН.		IN NS	ns.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN NS	ПОДЧИНЕННЫЙ_DNS_СЕРВЕР
www.ВАШ_ДОМЕН.	        IN A	192.168.1.3
ns.ВАШ_ДОМЕН.		IN A	192.168.1.5
mail.ВАШ_ДОМЕН.	        IN A	192.168.1.3
router.ВАШ_ДОМЕН.	IN A	192.168.1.1
hell.ВАШ_ДОМЕН.	        IN A	192.168.1.3
heaven.ВАШ_ДОМЕН.	IN A	192.168.1.5
desktop.ВАШ_ДОМЕН.	IN A	192.168.1.4

Создание файла внешней зоны

Здесь у нас только поддомены, информацию о которых мы хотим отдавать для внешних клиентов (www, mail и ns).

ФАЙЛ /var/bind/pri/ВАШ_ДОМЕН.external

$TTL 2d
@	IN SOA	ns.ВАШ_ДОМЕН.	АДМИНИСТРАТОР.ВАШ_ДОМЕН. (
	ИЗМЕНЕНИЕ	;serial
	3h	;refresh
	1h	;retry
	1w	;expiry
	1d )	;minimum
  
ВАШ_ДОМЕН.		IN MX	0 mail.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN TXT	"v=spf1 ip4:ВАШ_ПУБЛИЧНЫЙ_IP/32 mx ptr mx:mail.ВАШ_ДОМЕН ~all"
ВАШ_ДОМЕН.		IN NS	ns.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN NS   ПОДЧИНЕННЫЙ_DNS_СЕРВЕР
www.ВАШ_ДОМЕН.    	IN A	ВАШ_ПУБЛИЧНЫЙ_IP
ns.ВАШ_ДОМЕН.		IN A	ВАШ_ПУБЛИЧНЫЙ_IP
mail.ВАШ_ДОМЕН.	        IN A    ВАШ_ПУБЛИЧНЫЙ_IP

Окончательная конфигурация

Вам нужно добавить named к уровню доступ по умолчанию:

Конфигурация клиентов

Теперь вы можете использовать свой DNS сервер для всех машин в вашей локальной сети для разрешения доменных имен. Измените файл /etc/resolv.conf на всех машинах вашей локальной сети.

ФАЙЛ /etc/resolv.conf

search ВАШ_ДОМЕН
nameserver IP_ВАШЕГО_СЕРВЕРА_DNS

Заметьте, что IP_ВАШЕГО_СЕРВЕРА_DNS тот же, что и ВАШ_ЛОКАЛЬНЫЙ_IP, который мы использовали в данном документе. В примере он был 192.168.1.5.

Тестирование

Мы можем протестировать наш новый сервер DNS. Сначала нам нужно запустить сервис.

Теперь мы собираемся выполнить некоторые host-команды к некоторым доменам. Для этого теста мы можем использовать любой компьютер в нашей локальной сети. Если у вас нет пакета net-dns/host, вы можете вместо него использовать ping. В противном случае сначала запустите emerge host.

www.gentoo.org has address 209.177.148.228
www.gentoo.org has address 209.177.148.229

hell.ВАШ_ДОМЕН has address 192.168.1.3

router.ВАШ ДОМЕН has address 192.168.1.1

Защищаем сервер программой iptables

Во время использования DNS-сервиса, для дополнительной защиты, можно настроить iptables такими правилами:

iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Vicente Olivert Riera, nightmorph
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article’s associated history page.

DNS (Domain Name System, система доменных имён) — система, в которой все доменные имена серверов находятся в определённой иерархии. Для чего она нужна? 

Представим, что нам нужно обратиться к устройству с IP-адресом 92.53.116.191. Чтобы это сделать мы можем ввести адрес в командной строке и получить нужную информацию. Но запомнить много таких комбинаций цифр очень трудно. Поэтому были придуманы специальные серверы, которые позволяют преобразовывать доменные имена в IP-адреса. Так, когда вы вводите в поисковой строке браузера timeweb.cloud, данные запроса отправляются на DNS-сервер, который ищет совпадения в своей базе. Затем DNS-сервер посылает на устройство нужный IP-адрес и только тогда браузер обращается непосредственно к ресурсу.

Настройка собственной DNS позволяет более гибко и точно конфигурировать систему и не зависеть от третьих лиц. В этой статье мы рассмотрим, как настроить DNS с помощью сервера имён BIND на Ubuntu. 

Термины

Зона — часть иерархии доменных имён, которая размещается на DNS-сервере. Она нужна для того, чтобы установить рамки, в пределах которых распространяется ответственность конкретного сервера или группы серверов. 

Корневые серверы — это DNS-серверы, которые содержат информацию о доменах первого уровня (.ru, .com и так далее). 

Доменом называют именованную часть в иерархии DNS. Это определённый узел, который включает в себя другие узлы. DNS-адреса читаются справа налево и начинаются с точки, точкой также отделяются домены. То есть домен poddomen.domen.ru правильно читать так: .ru.domen.poddomen. Чаще всего доменное имя отражает структуру иерархии DNS, но последняя точка опускается. 

FQDN — это имя полное имя домена, которое включает в себя имена всех родительских доменов. 

Ресурсная запись — это единица хранения информации. Проще говоря, это запись, которая содержит связь имени с какой-либо служебной информацией. Ресурсная запись состоит из следующих элементов:

1. Имя (NAME) — имя или IP-адрес, которому принадлежит зона. 
2. Время жизни (Time to Live, TTL) — время хранения записи в кэше DNS, по прошествии которого запись удаляется. 
3. Класс (CLASS) — тип сети, чаще всего IN — Internet.
4. Тип (TYPE) — назначение записи
5. Различная информация (DATA)

Самые частые ресурсные записи

A-запись. Имя хоста на адрес IPv4. Для каждого сетевого интерфейса можно сделать только одну A-запись. 

timeweb.com.              86400     IN     A      185.114.246.105

AAAA-запись. Это то же самое, что А-запись, только справедливо для IPv6.

CNAME. Каноническая запись. Содержит псевдоним реального имени для перенаправления.

ftp             86400   IN      CNAME       store.cloud.timweb.com.

MX. Указывает хосты для доставки почты, адресованной домену. Поле NAME содержит домен назначения, а поле DATA — приоритет и хост для приёма почты. 

website.ru.             17790   IN      MX      10 mx.website.ru.
website.ru.             17790   IN      MX      20 mx2.website.ru.

NS. Указывает на DNS-сервер, которым обслуживается домен. 

PTR. IP-адрес в доменное имя. Необходимо для обратного преобразования имён.

SOA. Описывает основные настройки зоны.

SRV. Содержит адреса серверов, которые обеспечивают работу внутренних служб домена. Например, Jabber.

Инфраструктура

Для того, чтобы следовать всем инструкциям в статье, вам необходимо иметь как минимум два сервера Ubuntu в одном ЦОД. Любой из этих серверов вы можете заказать на timeweb.cloud.

Нам понадобится два сервера на Ubuntu 18.04, они будут использоваться в качестве первичного и вторичного DNS-серверов — ns1 и ns2 соответственно. А также дополнительные серверы, которые будут использовать наши настроенные серверы. 

Вы должны иметь права суперпользователя на каждом из серверов. Чтобы узнать, как это получить административные доступ, воспользуйтесь статьёй в нашем блоге — Редактирование файла sudoers.

В этой статье мы будем использовать bind в качестве DNS-сервера. Установим пакет bind9 из репозитория Linux:

sudo apt update && sudo apt upgrade -y
sudo apt install bind9

Кроме этого рекомендуем установить сразу инструменты мониторинга сети: 

sudo apt install dnsutils

После установки запускаем службу bind9:

sudo service bind9 start

Основной конфигурационный файл сервера — /etc/bind/named.conf. Он описывает общие настройки и обычно разбивается на несколько других для удобства. С работы с параметрами внутри этого файла начинается настройка DNS.

named.conf.options. Этот файл содержит общие параметры сервера. В нём укажем данные для конфигурации DNS.

options {
        dnssec-validation auto;
        auth-nxdomain no;
        directory "/var/cache/bind";
        recursion no; # запрещаем рекурсивные запросы на сервер имён
        listen-on {
                     172.16.0.0/16; 
                     127.0.0.0/8;    };
        forwarders { 
172.16.0.1;
            8.8.8.8;  
        };
};

Чтобы проверить, что всё внесено верно, нужно воспользоваться одной из утилит демона named — named-checkconf.

sudo named-checkconf

Если всё написано верно, bind-сервер начал работать. 

Первичный DNS-сервер

Первичный DNS-сервер — сервер, который хранит главную копию файла данных зоны. Все зоны будем хранить в каталоге /etc/bind/master-zones основного DNS-сервера. Создадим директорию:

sudo mkdir /etc/bind/master-zones

В ней создадим файл для описания зоны:

sudo touch /etc/bind/master-zones/test.example.com.loсal.zone

… и добавим в него SOA-, NS- и A-записи:

$ttl 3600 
$ORIGIN test.example.com. 
test.example.com.               IN              SOA  (      
ns.test.example.com.    
abuse.test.example.com.  
                                2022041201 
                                10800 
                                1200 
                                604800 
                                3600   ) 
@                               IN              NS              ns.test.example.com. 
@                               IN              NS              ns2.test.example.com.
@                               IN              A                172.16.101.3 
ns                              IN               A                172.16.0.5 
ns2                             IN              A                172.16.0.6

После этого необходимо запустить проверку утилитой named-checkzone.

sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.loсal.zone

named.conf.local. Это ещё один файл, который включается в общий конфиг сервера. В нём мы укажем локальные зоны:

zone "test.example.com." {
                type master;
                file "/etc/bind/master-zones/test.example.com.local.zone";
};

После того, как пропишем нужные данные, проверим конфиг и перезагрузим bind9 (флаг -z проверяет файлы зон):

sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart
sudo service bind9 status

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

Настройка представлений позволяет гибко управлять разрешением имён из разных подсетей. В файле /etc/bind/named.conf укажем:

include "/etc/bind/named.conf.options";
acl "local" { 172.16.0.0/16; };
view "local" {
                include "/etc/bind/named.conf.local";
                match-clients { local; };
};

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

Затем нужно заново перезагрузить bind9:

sudo service bind9 restart

После перезагрузки сервера с другого компьютера локальной сети можно запросить наличие у сервера 172.16.0.5 SOA-записи: 

dig @172.16.0.5 -t SOA test.example.com

На этом этапе настройка основного DNS-сервера завершена. Далее в статье — вторичный сервер, настройка почтового сервера и обратная зона. 

Вторичный сервер

Первые шаги абсолютно такие же, что и в случае с первичным сервером — установка bind9 и сетевых утилит.

sudo apt update && sudo apt upgrade -y
sudo apt install bind9
sudo apt install dnsutils
sudo service bind9 start

Далее для того, чтобы хранить файлы зон, создадим каталог /etc/bind/slave и снабдим его необходимыми правами:

sudo mkdir slave
sudo chmod g+w slave

Приступаем к настройке зоны на вторичном сервере. В файл /etc/bind/named.conf.local добавляем зону

zone "test.example.com." {
        type slave;
        file "/etc/bind/slave/test.example.com.local.zone";
        masters { 172.16.0.5; };
};

… и в основном конфигурационном файле named.conf настраиваем представления:

include "/etc/bind/named.conf.options";
acl "local" { 172.16.0.0/16; };
view "local" {
        match-clients { local; };
        include "/etc/bind/named.conf.local";
};

После добавления настроек нужно проверить синтаксис, а затем перезагрузить bind9:

sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart

Если нет ошибок, нужно выполнить трансфер зоны:

sudo rndc retransfer test.example.com

Команда rndc retransfer позволяет выполнить трансфер зоны без проверки серийных номеров. Вкратце, первичный (ns1) и вторичный (ns2) DNS-серверы работают следующим образом. ns2 «смотрит» только на серийный номер зоны, игнорируя содержание всего файла. 

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

Как только настроили сервер и выполнили трансфер зоны, в конфиге named.conf на первичном сервере нужно ограничить передачу адресом вторичного сервера. Для этого в named.conf нужно добавить директиву allow-transfer с указанием IP-адреса вторичного DNS-сервера.

И перезагружаем сервер:

sudo service bind9 restart

Далее все операции будем проводить на первичном сервере. 

Добавление MX-записи

В этом примере мы используем mx в качестве имени хоста, поскольку это общепринятое обозначение. Тогда FQDN — mx.test.example.com. 

В файл зоны /etc/bind/master-zones/test.example.com.loсal.zone добавляем ресурсные записи почты и обновляем серийный номер.

Проверим синтаксис и перезапустим bind9:

sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.local.zone
sudo service bind9 reload

Обратная зона

Обратная зона DNS — это особая доменная зона, которая предназначена для того, чтобы определять имя узла по его IP адресу. Например, адрес узла 192.168.1.10 в обратной нотации превращается в 10.1.168.192.in-addr.arpa. Благодаря тому, что используется иерархическая модель, можно делегировать управление зоной владельцу диапазона IP-адресов. 

По своей сути, PTR-запись определяет домен по адресу, а значит это практически то же самое, что и A-запись. Она используется в основном для проверки почтовых серверов.

Для настройки зоны обратного просмотра создадим новый файл зоны:

sudo nano /etc/bind/master-zones/16.172/in-addr.arpa.zone

и поместим в него следующее содержимое:

$TTL    3600 
16.172.in-addr.arpa.            IN      SOA  ( 
ns.test.example.com. 
admin.test.example.com. 
                                2022041202 
                                10800 
                                1200 
                                604800 
                                3600  )
                                IN      NS            ns.test.example.com. 
                                IN      NS           ns2.test.example.com. 
3.101.16.172.in-addr.arpa.      IN      PTR              test.example.com. 
5.0.16.172.in-addr.arpa.        IN      PTR           ns.test.example.com. 
6.0.16.172.in-addr.arpa.        IN      PTR          ns2.test.example.com. 
2.101.16.172.in-addr.arpa.      IN      PTR         mail.test.example.com.

Проверим зону и убедимся в корректности конфигурации:

sudo named-checkzone 16.172.in-addr.arpa /etc/bind/master-zones/16.172.in-addr.arpa.zone

Теперь эту зону нужно добавить в конфигурационный файл named.conf:

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

zone "16.172.in-addr.arpa." {
                type master;
                file "/etc/bind/master-zones/16.172.in-addr.arpa.zone";
                allow-transfer { 172.16.0.6; };
        };

После этого проверяем синтаксис и перезагружаем bind9.

Можно приступать к аналогичной настройке на вторичном сервере. В named.conf.local добавьте следующую конфигурацию:

zone "16.172.in-addr.arpa." { 
        type slave; 
        file "/etc/bind/slave/16.172.in-addr.arpa.zone"; 
        masters { 172.16.0.5; }; 
};

На этом этапе мы завершили работу с локальными доменными зонами. Можно приступать к конфигурации внешней доменной зоны. 

Внешняя доменная зона

Во-первых, для того, чтобы запросы из внешней сети обрабатывались нашим сервером нужно в файле конфигурации named.conf.options добавить внешний адрес в директиву listen-on:

...
listen-on {
    aaa.bbb.ccc.ddd/32; # наш внешний IP
    172.16.0.0;
    127.0.0.0/8
}
…

Далее создадим файл зоны (не забудьте изменить серийный номер!) и добавим в него внешние IP-адреса. 

sudo nano /etc/bind/master-zones/test.example.com.zone

$ttl 3600
$ORIGIN test.example.com.
test.example.com.               IN              SOA  (     
ns.test.example.com.
admin.test.example.com.
                                2022041205
                                10800
                                1200
                                604800
                                3600   )
@                               IN              NS              ns.test.example.com.
@                               IN              NS              ns2.test.example.com.
@                               IN              A               aaa.bbb.ccc.ddd # первый внешний адрес
ns                              IN              A               aaa.bbb.ccc.ddd
ns2                             IN              A               eee.fff.ggg.hhh # второй внешний адрес

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

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

И добавим в него следующее содержимое:

zone "test.example.com." { 
                type master; 
                file "/etc/bind/master-zones/test.example.com.zone";
                allow-transfer { 172.16.0.6; };
};

После этого подключим файл в named.conf, добавив такой блок:

acl "external-view" { aaa.bbb.ccc.ddd; };
view "external-view" {
                       recursion no;
                       match-clients { external-view; };
                       include "/etc/bind/named.conf.external";
};

Осталось проверить эту зону и перезагрузить bind9:

sudo named-checkconf -z
sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.zone
sudo service bind9 restart
sudo service bind9 status

На вторичном DNS-сервере в named.conf.options нам нужно указать внешний адрес сервера:

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

options {
        dnssec-validation auto;
        auth-nxdomain no;
        recursion no;
        directory "/var/cache/bind";
        listen-on {
                        eee.fff.ggg.hhh/24;
                        172.16.0.0/16;
                        127.0.0.0/8;
        };
};

И точно так же, как на первой машине, создаём новый файл named.conf.external:

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

Со следующим содержимым:

zone "test.example.com." {
        type slave;
        file "/etc/bind/slave/test.example.com.zone"; 
        masters { 172.16.0.5; };
};

Далее в named.conf добавляем следующий блок:

acl "external-view" { eee.fff.ggg.hhh; }; 
view "external-view" { 
        recursion no; 
        match-clients { external-view; }; 
        include "/etc/bind/named.conf.external"; 
};

И выполняем трансфер:

sudo rndc retransfer test.example.com IN external-view

Отладка

При настройке DNS-сервера очень важно внимательно отнестись к журналированию запросов. Это поможет при отладке на начальных стадиях, а во время полноценной работы сервера вы сможете в полной мере контролировать работу служб.

Bind9 позволяет полноценно настраивать правила журналирования — писать в один файл, разные категории помещать в разные журнал и так далее. 

Для того, чтобы записать отладочную информацию в один файл, нужно создать правила журналирования и подключить их в основной конфиг. Для этого создадим файл log.conf:

sudo nano /etc/bind/log.conf

И поместим в него содержимое:

logging {
    channel bind.log {
        file "/var/lib/bind/bind.log" versions 10 size 20m;
        severity debug;
        print-category yes;
        print-severity yes;
        print-time yes;
    };
        category queries { bind.log; };
        category default { bind.log; };
        category config { bind.log; };
};

После этого подключим файл в основной конфиг:

include "/etc/bind/log.conf"

И перезагрузим bind9:

sudo service bind9 restart

Можно создать несколько таких файлов с разными настройками и подключать их  в зависимости от стадии разработки или нагрузки на сервер. 

Заключение

Теперь вы сможете самостоятельно сконфигурировать систему так, чтобы обращаться к реусрсам по имени, а не по IP-адресу. Для этого в качестве примера мы настроили на сервере с ОС Ubuntu DNS с помощью пакета bind9.

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

BIND (or named) is the most widely used Domain Name System (DNS) server.

Note: The organization developing BIND is serving security notices to paying customers up to four days before Linux distributions or the general public.[1]^{[dead link 2023-09-16 ⓘ]}

Installation

Install the bind package.

Start/enable the named.service systemd unit.

To use the DNS server locally, use the 127.0.0.1 nameserver (meaning clients like Firefox resolve via 127.0.0.1), see Domain name resolution.
This will however require you to #Allow recursion while a firewall might block outside queries to your local named.

Configuration

BIND is configured in /etc/named.conf. The available options are documented in named.conf(5).

Reload the named.service unit to apply configuration changes.

Restrict access to localhost

BIND by default listens on port 53 of all interfaces and IP addresses. To only allow connections from localhost add the following line to the options section in /etc/named.conf:

listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };

Set up DNS forwarding

To make BIND forward DNS queries to another DNS server add the forwarders clause to the options section.

Example to make BIND forward to the Google Public DNS servers:

forwarders {
    8.8.8.8; 2001:4860:4860::8888;
    8.8.4.4; 2001:4860:4860::8844;
};

(As of 9.18, only plaintext DNS servers are supported as forwarders.)

Serve DNS over TLS or HTTPS

To enable serving DNS over TLS or HTTPS in BIND 9.18, define a tls block specifying your certificate, then add listen-on clauses enabling DNS over TLS and HTTPS listeners (as well as a standard DNS listener).

/etc/named.conf

tls mycert {
    cert-file "<path>.crt";
    key-file "<path>.key";
};

options {
    // Standard port 53 listeners need to be re-added explicitly
    listen-on    { any; };
    listen-on-v6 { any; };
    
    // Add a DNS over TLS listener on standard port 853
    listen-on    tls mycert { any; };
    listen-on-v6 tls mycert { any; };
    
    // Add a DNS over HTTPS listener on custom port
    listen-on    port 9443 tls mycert http default { any; };
    listen-on-v6 port 9443 tls mycert http default { any; };
    
    // If needed, add a cleartext HTTP listener for a reverse proxy
    //listen-on    port 8443 tls none http default { 127.0.0.1; };
    //listen-on-v6 port 8443 tls none http default { ::1; };
};
...

Note that tls{} is defined at the top level, not inside the options{} block.

A configuration template for running a domain

Following is a simple home nameserver being set up, using domain.tld as the domain being served world-wide like this wiki’s archlinux.org domain is.

A more elaborate example is DNS server with BIND9, while this shows how to set up internal network name resolution.

Creating a zonefile

Create /var/named/domain.tld.zone.

$ORIGIN domain.tld.
$TTL 2h

@               SOA     ns1 hostmaster (
                                2018111111 ; Serial
                                8h         ; Refresh
                                30m        ; Retry
                                1w         ; Expire
                                1h )       ; Negative Cache TTL
                NS      ns1
                NS      ns2
                
@               A       203.0.113.1
                AAAA    2001:db8:113::1
                MX      10 mail
                TXT     "v=spf1 mx"

www             A       203.0.113.1
                AAAA    2001:db8:113::1

ns1             A       203.0.113.4
                AAAA    2001:db8:113::4

ns2             A       198.51.100.5
                AAAA    2001:db8:5100::5

mail            A       198.51.100.6
                AAAA    2001:db8:5100::6
imap            CNAME   mail
smtp            CNAME   mail

$ORIGIN defines the default suffix for all names which do not already end with a . (dot), e.g. mail will be expanded to mail.$ORIGIN ⇒ mail.domain.tld. everywhere.

$TTL defines the default time-to-live (i.e. cache expiry time) for all records which do not have their own TTL specified. Here it is 2 hours.

Serial must be incremented manually before reloading named every time you change a resource record for the zone. Otherwise secondary servers (replicas or slaves) will not re-transfer the zone: they only do it if the serial is greater than that of the last time they transferred the zone. This example uses the somewhat common YYYYMMDDXX format, but this is not required; the serial number can also just start at 1.

Configuring master server

Add your zone to /etc/named.conf:

zone "domain.tld" IN {
        type master;
        file "domain.tld.zone";
        allow-update { none; };
};

Reload the named.service unit to apply the configuration change.

Allow recursion

If you are running your own DNS server, you might as well use it for all DNS lookups, or even #Serve the root zone locally by yourself. The former will require the ability to do recursive lookups. In order to prevent DNS Amplification Attacks, recursion is turned off by default for most resolvers. The default Arch /etc/named.conf file allows for recursion only on the loopback interface:

allow-recursion { 127.0.0.1; ::1; };

If you want to provide name service for your local network; e.g. 192.168.0.0/24, you must add the appropriate range of IP addresses to /etc/named.conf:

allow-recursion {
    192.168.0.0/24;
    fd01:2345:6789::/64;
    127.0.0.1;
    ::1;
};

Configuring BIND to serve DNSSEC signed zones

DNSSEC validation is enabled by default. Do not forget to check that «edns» is not disabled.

On master DNS server:

• generate KSK and ZSK keys:

 $ dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com
 $ dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com

• change zone configuration:

 zone "example.com" {
       type master;
       allow-transfer { ... };
       auto-dnssec maintain;
       inline-signing yes;
       key-directory "master/";
       file "master/example.com.zone";
 };

Now bind will sign zone automatically. (This example assumes that all required files are in /var/named/master/)

Then you should pass DS records (from dsset-example.com. file) to parent zone owner probably using your registrar website. It glues parent zone with your KSK.

KSK (and corresponding DS records) should be changed rarely because it needs manual intervention, ZSK can be changed more often because this key is usually shorter to be faster in signature checking.

You can schedule old ZSK key expiration and generate new one using:

 $ dnssec-settime -I +172800 -D +345600 Kexample.com.+000+111111.key
 $ dnssec-keygen -S Kexample.com.+000+111111.key -i 152800

Bind should automatically use new ZSK key at appropriate time.

There are external mechanisms such as OpenDNSSEC with fully-automatic key rollover available.

Automatically listen on new interfaces

By default bind scan for new interfaces and stop listening on interfaces which no longer exist every hour. You can tune this value by adding :

interface-interval <rescan-timeout-in-minutes>;

parameter into named.conf options section. Max value is 28 days. (40320 min)
You can disable this feature by setting its value to 0.

Then restart the service.

Running BIND in a chrooted environment

Running in a chroot environment is not required but improves security.

Creating the jail house

In order to do this, we first need to create a place to keep the jail, we shall use /srv/named, and then put the required files into the jail.

# mkdir -p /srv/named/{dev,etc,usr/lib/engines,var/{run,log,named}}

Copy over required system files:

# cp -av /etc/{localtime,named.conf} /srv/named/etc/
# cp -av /usr/lib/engines-1.1/* /srv/named/usr/lib/engines/
# cp -av /var/named/* /srv/named/var/named/.

Set up required nodes in /dev/:

# mknod /srv/named/dev/null c 1 3
# mknod /srv/named/dev/random c 1 8

Set ownership of the files:

# chown -R named:named /srv/named

This should create the required file system for the jail.

Service unit

Next we need a replacement unit file so that the service calls bind which will allow force bind into the chroot:

/etc/systemd/system/named-chroot.service

ExecStart=/usr/bin/named -4 -f -u named -t "/srv/named"

Now, reload systemd with daemon-reload, and start the named-chroot.service.

Serve the root zone locally

If you do not want to rely on third-party DNS services, you can serve the root zone locally following RFC:7706. This can be achieved by using BIND as a DNS recursive resolver.

To manage a recursive resolver, you typically need to configure a root hints file. This file contains the names and IP addresses of the authoritative name servers for the root zone.

Grab the file from IANA website and place it into /var/named.

Edit your server config, adding the respective file:

/etc/named.conf

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

Recursion also should be allowed in the config. See #Allow recursion.

See also

• BIND 9 Administrator Reference Manual (ARM)
• BIND ARM on readthedocs
• BIND knowledgebase
• Internet Systems Consortium, Inc. (ISC)
• Pro DNS and BIND with abbreviated version online
• DNS Glossary
• Archived mailing list discussion on BIND’s future
• root zone transfer made simple — serve root@home copy the /etc/named.conf , restart BIND & enjoy!
• DNSSEC
• a BIND configuration template

Background

Note: There are some issues with this Howto, too numerable to fix quickly, and it requires bringing up to standard. I’m mentioning this to help anyone to avoid the unnecessary time trying to resolve their DNS, owing the the inconsistencies in this document, particularly if you’re new to DNS configuration. One example is here…

box IN A 192.168.1.10

… in all other places, the document uses the machine name example ns. Here it changes to box (I believe the author was simply trying to show that additional computers would be listed, but failed to use a different address for box. I modified the example file to give box an address of 192.168.1.21).

Introduction

Domain Name Service (DNS) is an Internet service that maps IP addresses and fully qualified domain names (FQDN) to one another. In this way, DNS alleviates the need to remember IP addresses. Computers that run DNS are called name servers. Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most widely deployed DNS server.

This guide is aimed at people looking to learn how to configure and maintain a DNS server, such as for a network (caching name server) or to serve DNS zones for a domain name.

Installation

BIND9 is available in the Main repository. No additional repository needs to be enabled for BIND9.

Before we begin, you should be familiar with RootSudo.

To install the server simply install the bind9 package. See InstallingSoftware for details on using package managers.

A very useful package for testing and troubleshooting DNS issues is the dnsutils package. Also, the BIND9 Documentation can be found in the bind9-doc package.

BIND9 Configuration Scenarios

BIND9 can provide many different DNS services.

Some of the most useful setups are:

Caching Server

In this configuration BIND9 will find the answer to name queries and remember the answer for the next query. This can be useful for a slow internet connection. By caching DNS queries, you will reduce bandwidth and (more importantly) latency.

Primary Master Server

BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network).

Secondary Master Server

A secondary master DNS server is used to complement a primary master DNS server by serving a copy of the zone(s) configured on the primary server. Secondary servers are recommended in larger setups. If you intend to serve a registered domain name they ensure that your DNS zone is still available even if your primary server is not online.

Hybrids

You can even configure BIND9 to be a Caching and Primary Master DNS server simultaneously, a Caching and a Secondary Master server or even a Caching, Primary Master and Secondary Master server. All that is required is simply combining the different configuration examples.

Stealth Servers

There are also two other common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary. These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference.

For example, you have 3 DNS servers; A, B and C.

A is the Primary, B and C are secondaries.

If you configure your registered domain to use A and B as your domain’s DNS servers, then C is a Stealth Secondary. It’s still a secondary, but it’s not going to be asked about the zone you are serving to the internet from A and B

If you configure your registered domain to use B and C as your domain’s DNS servers, then A is a stealth primary. Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.

DNS Record Types

There are lots of different DNS record types, but some of the most common types are covered below.

Address Records

The most commonly used type of record. This record maps an IP Address to a hostname.

www      IN    A      1.2.3.4

Alias Records

Used to create an alias from an existing A record. You can create a CNAME record pointing to another CNAME record. But it doubles the number of requests made to the nameserver, thus making it an inefficient way to do so.

mail     IN    CNAME  www
www      IN    A      1.2.3.4

Mail Exchange Records

Used to define where email should be sent to and at what priority. Must point to an A record, not a CNAME. Multiple MX records can exist if multiple mail servers are responsible for that domain.

        IN    MX  10    mail.example.com.

        [...]

mail    IN    A       1.2.3.4

Name Server Records

Used to define which servers serve copies of this zone. It must point to an A record, not a CNAME.

This is where Primary and Secondary servers are defined. Stealth servers are intentionally omitted.

        IN    NS     ns.example.com.

        [...]

ns      IN    A      1.2.3.4

Configuring BIND9

BIND9 Configuration files are stored in:

/etc/bind/

The main configuration is stored in the following files:

/etc/bind/named.conf
/etc/bind/named.conf.options
/etc/bind/named.conf.local

Caching Server configuration

The default configuration is setup to act as a caching server.

All that is required is simply adding the IP numbers of your ISP’s DNS servers.

Simply uncomment and edit the following in /etc/bind/named.conf.options:

        [...]

        forwarders {
             1.2.3.4;
             5.6.7.8;
        };

        [...]

(where 1.2.3.4 and 5.6.7.8 are the IP numbers of your ISP’s DNS servers)

Now restart the bind daemon:

sudo /etc/init.d/bind9 restart

Testing

If you installed the dnsutils package you can test your setup using the dig command:

dig -x 127.0.0.1

If all goes well you should see output similar to:

; <<>> DiG 9.4.1-P1 <<>> -x 127.0.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13427
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

[...]

;; Query time: 1 msec
;; SERVER: 172.18.100.80#53(172.18.100.80)
;; WHEN: Mon Nov 26 23:22:53 2007
;; MSG SIZE  rcvd: 93

The dig command can also be used to query other domains for example:

dig google.com

If you «dig» a domain name multiple times you should see a drastic improvement in the Query time: between the first and second query. This is due to the server caching the query.

Primary Master Server configuration

In this section BIND9 will be configured as the primary master for the domain example.com. Simply replace example.com with your fully qualified domain name.

Zone File

To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit named.conf.local:

        [...]

        zone "example.com" {
             type master;
             file "/etc/bind/db.example.com";
        };

        [...]

Now use an existing zone file as a template:

sudo cp /etc/bind/db.local /etc/bind/db.example.com

Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional «.» at the end. Change 127.0.0.1 to the nameserver’s IP Address and root.localhost to a valid email address, but with a «.» instead of the «@». also leaving the «.» at the end.

Also, create an A record for ns.example.com the name server in this example:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.example.com.
ns      IN      A       192.168.1.10

;also list other computers
box     IN      A       192.168.1.21

You must increment the serial number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the serial once.

Now, you can add DNS records to the bottom of the zone.

Tip: Many people like to use the last date edited as the serial of a zone, such as  2005010100  which is yyyymmddss (where s is serial)

Once you’ve made a change to the zone file BIND9 will need to be restarted for the changes to take effect:

sudo /etc/init.d/bind9 restart

Reverse Zone File

Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to convert from an address to a name.

Edit /etc/bind/named.conf.local and add the following:

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

Note: replace 1.168.192 with the first three octets of whatever private network you are using. Also, name the zone file db.192 in the example appropriately.

Now create the db.192 file:

sudo cp /etc/bind/db.127 /etc/bind/db.192

Next edit /etc/bind/db.192 changing the basically the same options as in /etc/bind/db.example.com:

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
10      IN      PTR     ns.example.com.

; also list other computers
21      IN      PTR     box.example.com.

The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in /etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192.

After creating the reverse zone file restart bind9:

sudo /etc/init.d/bind9 restart

Testing

You should now be able to ping example.com and have it resolve to the host configured above:

ping example.com

You can also use the named-checkzone utility that is part of the bind9 package:

named-checkzone example.com /etc/bind/db.example.com

and

named-checkzone 1.168.192.in-addr.arpa. /etc/bind/db.192

This is a great way to make sure you haven’t made any mistakes before restarting bind9.

You can use the dig utility to test the reverse zone as well as the new domain name:

dig 1.168.192.in-addr.arpa. AXFR

You should see output resolving 1.168.192.in-addr.arpa. to your nameserver.

Secondary Master Server configuration

Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable.

First, on the primary master server, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local:

        [...]

        zone "example.com" {
             type master;
             file "/etc/bind/db.example.com";
             allow-transfer { @ip_secondary; };
        };

        [...]

        zone "1.168.192.in-addr.arpa" {
             type master;
             notify no;
             file "/etc/bind/db.192";
             allow-transfer { @ip_secondary; };
        };

       [...]

Note: replace @ip_secondary with the actual IP Address of your secondary server.

Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the /etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones:

        [...]

        zone "example.com" {
             type slave;
             file "/var/cache/bind/db.example.com";
             masters { @ip_master; };
        };

        [...]

        zone "1.168.192.in-addr.arpa" {
             type slave;
             file "/var/cache/bind/db.192";
             masters { @ip_master; };
        };

        [...]

Note: replace @ip_master with the IP Address of the Primary. The zone file must be in /var/cache/bind/ because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor’s configuration in /etc/apparmor.d/usr.sbin.named).

Restart the server, and in /var/log/syslog you should see something similar to:

syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401
syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer
syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)

Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.

Testing

Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.

Chrooting BIND9

Chrooting BIND9 is a recommended setup from a security perspective if you don’t have AppArmor installed. In a chroot enviroment, BIND9 has access to all the files and hardware devices it needs, but is unable to access anything it should not need. AppArmor is installed by default on recent Ubuntu releases. Unless you’ve explicitly disabled AppArmor, you might want to read this before you decide to attempt a chrooted bind. If you still want to go forward with it, you’ll need this information, which isn’t covered in the instructions that follow here.

To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below

The Chroot Enviroment

Create the following directory structure

$ sudo mkdir -p /chroot/named
$ cd /chroot/named
$ sudo mkdir -p dev etc/namedb/slave var/run

Set permissions for chroot environment

$ sudo chown root:root /chroot
$ sudo chmod 700 /chroot
$ sudo chown bind:bind /chroot/named
$ sudo chmod 700 /chroot/named

Create or move the bind configuration file.

$ sudo touch /chroot/named/etc/named.conf

or

$ sudo cp /etc/bind/named.conf /chroot/named/etc

Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.

$ sudo chown bind:bind /chroot/named/etc/namedb/slave

This is where the files for all slave zones will be kept. This increases security, by stopping the ability of an attacker to edit any of your master zone files if they do gain access as the bind user. Accordingly, all slave file names in the /chroot/named/etc/named.conf file will need to have directory names that designate the slave directory. An example zone definition is listed below.

zone "my.zone.com." {
        type slave;
        file "slaves/my.zone.com.dns";
        masters {
                10.1.1.10;
        };
};

Create the devices BIND9 requires

$ sudo mknod /chroot/named/dev/null c 1 3
$ sudo mknod /chroot/named/dev/random c 1 8

Give the user bind access to the /chroot/named/var/run directory that will be used to strore PID and statistical data.

$ sudo chown bind:bind /chroot/named/var/run

BIND9’s Configuration

Edit the bind startup options found in /etc/default/bind9. Change the line the reads:

/etc/default/bind9:

OPTIONS="-u bind"

So that it reads

/etc/default/bind9:


OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"

The -t option changes the root directory from which bind operates to be /chroot/named. The -c option tells Bind that the configuration file is located at /etc/named.conf. Remember that this path is relative to the root set by -t.

The named.conf file must also recieve extra options in order to run correctly below is a minimal set of options:

/chroot/named/etc/named.conf:

options {
    directory "/etc/namedb";
    pid-file "/var/run/named.pid";
    statistics-file "/var/run/named.stats";
};

Ubuntu’s syslod Daemon Configuration

/etc/init.d/sysklogd:


        [...]

SYSLOGD="-u syslog -a /chroot/named/dev/log"

        [...]

(Author Note: Check this config)

Restart the syslog server and BIND9

$ sudo /etc/init.d/sysklogd restart
$ sudo /etc/init.d/bind9 restart

At this point you should check /var/log/messages for any errors that may have been thrown by bind.

Starting, Stopping, and Restarting BIND9

Use the following command to start BIND9 :

$ sudo /etc/init.d/bind9 start

To stop it, use :

$ sudo /etc/init.d/bind9 stop

Finally, to restart it, run

$ sudo /etc/init.d/bind9 restart

Status

To check the status of your BIND9 installation:

$ host localhost

or

$ dig @localhost

(where localhost is the system you are setting BIND9 up on. If not localhost, use the appropriate IP number.)

Logging

BIND9 has a wide variety of logging configuration options available. There are two main options to BIND9 logging the channel option configures where logs go, and the category option determines what to log.

If no logging option is configured for the default option is:

logging {
     category default { default_syslog; default_debug; };
     category unmatched { null; };
};

Next we will configure BIND9 to send debug messages related to DNS queries to a separate file.

Channel Option

First, we need to configure a channel to specify which file to send the messages to. Edit /etc/bind/named.conf.local and add the following:

logging {
    channel query.log {
        file "/var/log/query.log";
        // Set the severity to dynamic to see all the debug messages.
        severity dynamic;
    };
};

Category Option

Next, configure a category to send all DNS queries to the query file:

logging {
    channel query.log {
        file "/var/lib/bind/query.log";
        // Set the severity to dynamic to see all the debug messages.
        severity debug 3;
    };

    category queries { query.log; };
};

Note: the debug option can be set from 1 to 3. If a level isn’t specified level 1 is the default.

Now restart BIND9 for the changes to take affect:

sudo /etc/init.d/bind9 restart

You should see the file /var/log/query.log fill with BIND9 log information. This is a simple example of the BIND9 logging options available see bind9.net manual for more information.

Additional Possibilities

You can monitor your BIND9 server usage by installing the bindgraph package from the Universe (To enable Universe — see AddingRepositoriesHowto) and following configuration details as outlined in bindgraph’s README documents

Further Information

Online Recources

«ISC’s BIND9 Manual»

TLDP’s «DNS HOWTO» (For General Overview)

«Chroot BIND Howto»

Debian BIND Wiki

BIND reference guide

Printed Resources

«DNS & BIND» — Paul Albitz & Cricket Liu — 5th Edition — «O’Reilly Press» (Amazon.com)

DNS & BIND Cookbook — Cricket Liu — 4th Edition — «O’Reilly Press» (Amazon.com)

CategoryNetworking CategoryInternet