Вторичный (secondary, slave) авторитетный сервер зоны
Основная функция slave сервера — автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP, посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).
Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.
Прежде чем приступить к настройке slave DNS сервера, необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:
root@debian:~# dig @10.0.0.152 example.com. axfr ; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr ; (1 server found) ;; global options: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)
Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:
- Скопировать конфигурационный файл named.conf с master сервера;
- Заменить параметр type master на type slave в тех зонах, для которых он будет вторичным;
- Параметр allow-transfer { 10.0.0.191; }; заменить на masters { 10.0.0.152;}; в тех зонах, для которых он будет вторичным;
- Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
- Создать каталоги для логов, как в предыдущем примере.
Итого, мы получаем конфиг slave сервера:
root@debian:~# cat /etc/bind/named.conf
options {
directory "/var/cache/bind";
allow-query { any; }; // отвечать на запросы со всех интерфейсов
recursion no; // запретить рекурсивные запросы
auth-nxdomain no; // для совместимости RFC1035
listen-on-v6 { none; }; // IPv6 нам не нужен
version "unknown"; // не отображать версию DNS сервера при ответах
};
// нижеописанные зоны определяют сервер авторитетным для петлевых
// интерфейсов, а так же для броадкаст-зон (согласно RFC 1912)
zone "localhost" {
type master;
file "localhost";
};
zone "127.in-addr.arpa" {
type master;
file "127.in-addr.arpa";
};
zone "0.in-addr.arpa" {
type master;
file "0.in-addr.arpa";
};
zone "255.in-addr.arpa" {
type master;
file "255.in-addr.arpa";
};
// описание основной зоны
zone "example.com" {
type slave;
file "example.com";
masters { 10.0.0.152; };
};
//описание обратной зоны
zone "0.0.10.in-addr.arpa" {
type slave;
file "0.0.10.in-addr.arpa";
masters { 10.0.0.152; };
};
// настройки логирования
logging {
channel "misc" {
file "/var/log/bind/misc.log" versions 4 size 4m;
print-time YES;
print-severity YES;
print-category YES;
};
channel "query" {
file "/var/log/bind/query.log" versions 4 size 4m;
print-time YES;
print-severity NO;
print-category NO;
};
category default {
"misc";
};
category queries {
"query";
};
};
после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:
root@debian:~# ls -la /var/cache/bind/ итого 28 drwxrwxr-x 2 root bind 4096 Июл 8 18:47 . drwxr-xr-x 10 root root 4096 Июл 8 15:17 .. -rw-r--r-- 1 bind bind 416 Июл 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind bind 455 Июл 8 18:32 example.com ........
В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.
Start named-chroot service
To configure dns server on Red Hat Enterprise Linux 7 the installation of does NOT change how the named service is run. On the contrary it installs new service that needs to be started using command, if you want to run named service in a chroot environment.
But before, make sure to stop and disable any named service which is available and running on your RHEL 7 Linux host:
# systemctl stop named # systemctl disable named
Next start service using systemctl:
# systemctl start named-chroot
# systemctl status named-chroot
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; disabled; vendor preset: disabled)
Active: active (running) since Fri 2019-06-21 17:00:25 IST; 1min 1s ago
Process: 5321 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} -t /var/named/chroot $OPTIONS (code=exited, status=0/SUCCESS)
Process: 5319 ExecStartPre=/bin/bash -c if ; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS)
Main PID: 5323 (named)
Tasks: 4
CGroup: /system.slice/named-chroot.service
└─5323 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot
Jun 21 17:00:25 centos-8.example.com named: zone 2.0.10.in-addr.arpa/IN: loaded serial 1
Jun 21 17:00:25 centos-8.example.com named: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Jun 21 17:00:25 centos-8.example.com named: zone localhost.localdomain/IN: loaded serial 0
Jun 21 17:00:25 centos-8.example.com named: zone example.com/IN: loaded serial 1
Jun 21 17:00:25 centos-8.example.com named: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0....ial 0
Jun 21 17:00:25 centos-8.example.com named: zone localhost/IN: loaded serial 0
Jun 21 17:00:25 centos-8.example.com named: all zones loaded
Jun 21 17:00:25 centos-8.example.com named: running
Jun 21 17:00:25 centos-8.example.com named: zone example.com/IN: sending notifies (serial 1)
Jun 21 17:00:25 centos-8.example.com named: zone 2.0.10.in-addr.arpa/IN: sending notifies (serial 1)
Hint: Some lines were ellipsized, use -l to show in full.
Now our configure dns server steps are almost done, enable the service to start the service automatically after every reboot:
# systemctl enable named-chroot Created symlink from /etc/systemd/system/multi-user.target.wants/named-chroot.service to /usr/lib/systemd/system/named-chroot.service.
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.
Устанавливаем 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
У меня не установлен, так как во время инсталляции centos выбрал минимальный пакет программ. Сервер имен у нас будет работать в 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
Все в порядке, сервер запустился, необходимые файлы созданы, все готово для настройки. Займемся ей.
Add zone records
Next we need to add zone records for forward zone file and reverse zone file location in file. here example.com contains details for our forward zone file and contains information about reverse zone file.
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; }; zone "2.0.10.in-addr.arpa" IN { type master; file "example.com.rzone"; allow-update { none; }; };
NOTE:
For the reverse zone, here since our IP is , I have used as the zone name, similarly if your IP is then your reverse zone name syntax would be
We will create our forward and reverse zone files in the next steps.
На сервере Slave
Открываем на редактирование конфигурационный файл bind.
CentOS:
vi /etc/named.conf
Ubuntu:
vi /etc/bind/named.conf.local
И дописываем туда следующее:
zone «dmosk.ru» {
type slave;
file «slaves/dmosk.ru»;
masters { 192.168.0.10; };
};
* где dmosk.ru — зона (домен); slave — указание, что эта зона вторичная; slave/dmosk.ru — файл с записями зоны
Стоит обратить внимание, что используется относительный путь до файла — это значит, что каталог slave должен находиться в рабочей папке bind (ее путь определяется опцией directory). Можно также прописать абсолютный путь, например, /etc/bind/slave/dmosk.ru; 192.168.0.10 — IP-адрес первичного сервера, с которого будут вытянуты записи для созданной зоны
Создаем каталог для хранения вторичных зон.
CentOS:
mkdir /var/named/slaves
Ubuntu:
mkdir /var/cache/bind/slaves
* используемые в нашем примере каталоги применяются по умолчанию, но в Вашем случае они могут быть другими. Сверяйте данные по опции directory.
Чтобы настройки применились, необходимо перезапустить вторичный bind-сервер одной из команд:
systemctl reload named
systemctl reload bind
service bind9 reload
и перечитать информацию о настроенных DNS-зонах:
rndc reload
Проверяем, что файл с записями появился в базе bind:
CentOS:
ls /var/named/slaves/
Ubuntu:
ls /var/cache/bind/slaves
* команда выведет список файлов, среди которых должен быть наш (в конкретном примере, dmosk.ru).
Чтобы проверить работоспособность вторичного сервера BIND, запускаем консоль на любом компьютере в сети и вводим команду:
nslookup dmosk.ru 192.168.0.15
* где dmosk.ru — домен, который мы создали; 192.168.0.15 — IP-адрес резервного DNS-сервера, на котором мы и создавали slave-зону (в моем примере).
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";
};
Настройка основного (главного) DNS-сервера
Установите на ваш сервер пакеты bind9.
Отредактируйте файл ‘/etc/named.conf’.
Теперь добавьте следующие, выделенные жирным шрифтом, строчки:
2. Создание файлов зон
Создайте файлы прямой и обратной зоны, которые мы упоминали в файле ‘/etc/named.conf’.
2.1 Создание прямой зоны
В директории /var/named создайте файл forward.unixmen.
Допишите следующие строчки:
На этом создание прямой зоны завершено, переходим далее.
2.2 Создание обратной зоны
В директории /var/named создайте файл reverse.unixmen.
Добавьте следующие строчки:
7. Проверка на ошибки
Теперь нужно убедиться в корректности выполнения проделанных нами пунктов.
Проверьте стандартный файл конфигурации DNS:
Если ничего не возвращается, ваш файл конфигурации настроен корректно.
Далее, проверьте прямую зону:
Затем, проверьте обратную зону:
Добавьте данные DNS-сервера в файл конфигурации сетевого интерфейса.
Отредактируйте файл ‘/etc/resolv.conf’,
Добавьте имя сервера и IP-адрес:
Сохраните и закройте файл.
Перезагрузите сетевую службу:
Настало время настройки дополнительного DNS-сервера.
Verify Zones
Visit any client machine and add a DNS server ip address in /etc/resolv.conf.
nameserver 192.168.0.10
If Network Manager manages the networking then place the following entry in /etc/sysconfig/network-scripts/ifcfg-eXX file.
DNS1=192.168.0.10
Restart network service.
ADVERTISEMENT
systemctl restart NetworkManager
Use the following command to verify the forward lookup.
dig www.itzgeek.local
Output: The DNS server should give 192.168.0.100 as ip for www.itzgeek.local.
; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> www.itzgeek.local ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35563 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.itzgeek.local. IN A ;; ANSWER SECTION: www.itzgeek.local. 86400 IN A 192.168.0.100 ;; AUTHORITY SECTION: itzgeek.local. 86400 IN NS primary.itzgeek.local. ;; ADDITIONAL SECTION: ns1.itzgeek.local. 86400 IN A 192.168.0.10 ;; Query time: 0 msec ;; SERVER: 192.168.0.10#53(192.168.0.10) ;; WHEN: Wed Jul 03 02:00:40 EDT 2019 ;; MSG SIZE rcvd: 100
Install BIND utilities yum install -y bind-utils package to get nslookup or dig command.
Confirm the reverse lookup.
dig -x 192.168.0.100
Output: The DNS server gives www.itzgeek.local as a name for 192.168.0.100.
; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> -x 192.168.0.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4807 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;100.0.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 100.0.168.192.in-addr.arpa. 86400 IN PTR www.itzgeek.local. ;; AUTHORITY SECTION: 0.168.192.in-addr.arpa. 86400 IN NS ns1.itzgeek.local. ;; ADDITIONAL SECTION: ns1.itzgeek.local. 86400 IN A 192.168.0.10 ;; Query time: 0 msec ;; SERVER: 192.168.0.10#53(192.168.0.10) ;; WHEN: Wed Jul 03 02:02:47 EDT 2019 ;; MSG SIZE rcvd: 124
It is now confirmed that both forward and reverse lookups are working fine.
Configure DNS Server (named.conf)
To configure DNS server first thing is to update our file. We have made the below highlighted changes in our file:
# cat /etc/named.conf
options {
listen-on port 53 { 127.0.0.1; any; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { localhost; any; };
allow-query-cache { localhost; any; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
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
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.
Зоны bind
Для возможности искать соответствия в собственной базе доменов, необходимо создать и настроить зоны. Существуют следующие типы зон:
- Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind.
- Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind.
- Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
- Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.
Проверка работы 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 сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, настроить запрет сайтов на микротике.
Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.
Онлайн курсы по Mikrotik
Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .
Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:
- Знания, ориентированные на практику;
- Реальные ситуации и задачи;
- Лучшее из международных программ.
Configure DNS Server on Client
To configure DNS server on a client you do not need to install any additional bind chroot related rpms, you only need to update the file on all the clients to use nameserver IP of the DNS server.
For example on my client node:
# cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 10.0.2.32
Let us verify the DNS server configuration by using :
# nslookup centos-8.example.com Server: 10.0.2.32 Address: 10.0.2.32#53 Name: centos-8.example.com Address: 10.0.2.32
As you see the client is properly able to get the response from the DNS server running on rhel linux host.
Lastly I hope the steps from the article to configure DNS server using bind chroot environment on Linux (CentOS/RHEL 7/8) was helpful. So, let me know your suggestions and feedback using the comment section.
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
