Дано:
- У вас есть два сервера, которые будут работать как DNS-серверы имен. Здесь мы будем ссылаться на них как на ns1 и ns2.
- У вас есть два дополнительных клиента, которые будут использовать разрабатываемую вами инфраструктуру DNS. Здесь мы будем ссылаться на них как на host1 и host2. Вы можете добавить любое количество клиентов.
- Все серверы находятся в одном ЦОД (в мануале он условно называется nyc3).
- Все серверы поддерживают частную сеть (в мануале они находятся в подсети 10.128.0.0/16, вероятно, это значение вам нужно будет откорректировать).
- Все серверы обслуживают проект, который работает на домене example.com. Поскольку наша система DNS будет полностью внутренней и частной, вам не нужно приобретать доменное имя. Однако использование домена может помочь избежать конфликтов.
Учитывая все вышесказанное, имеет смысл организовать схему именования, которая использует nyc3.example.com для обозначения частной подсети или зоны. Таким образом, FQDN хоста host1 будет host1.nyc3.example.com. Схема представлена в следующей таблице:
| Хост | Роль | Частный FQDN | Внутренний IP-адрес |
| ns1 | Первичный DNS-сервер | ns1.nyc3.example.com | 10.128.10.11 |
| ns2 | Вторичный DNS-сервер | ns2.nyc3.example.com | 10.128.20.12 |
| host1 | Клиент Host 1 | host1.nyc3.example.com | 10.128.100.101 |
| host2 | Клиент Host 2 | host2.nyc3.example.com | 10.128.200.102 |
Примечание: Ваша ситуация будет отличаться, но условные имена и IP-адреса будут использоваться в этом мануале для демонстрации настройки DNS-сервера для обеспечения работы внутреннего DNS. Вы должны легко адаптировать эту настройку к своей собственной среде, заменив имена хостов и внутренние IP-адреса своими собственными данными. Использовать имя региона центра обработки данных в схеме именования нет необходимости, но мы используем его здесь, чтобы обозначить, что эти хосты принадлежат частной сети одного центра обработки данных. Если вы используете несколько центров обработки данных, вы можете настроить внутренний DNS в каждом соответствующем ЦОД.
В результате у вас будет первичный DNS-сервер ns1 и вторичный DNS-сервер ns2.
1: Установка BIND на DNS-серверы
Примечание: Обратите внимание на текст, выделенный красным цветом. Он часто указывает, что необходимо заменить своими данными или добавить в файл конфигурации.
На серверах ns1 и ns2 обновите индекс пакетов:
sudo apt update
Затем установите BIND:
sudo apt install bind9 bind9utils bind9-doc
Настройка режима IPv4
Прежде чем продолжить, переведите BIND в режим IPv4, поскольку частная сеть использует только IPv4. На обоих серверах отредактируйте конфигурационный файл по умолчанию bind9:
sudo nano /etc/default/bind9
Добавьте опцию -4 в конец параметра OPTIONS:
. . .
OPTIONS="-u bind -4"
Сохраните и закройте файл.
Чтобы обновить настройки, перезапустите BIND:
sudo systemctl restart bind9
2: Настройка первичного DNS-сервера
Конфигурация BIND состоит из нескольких файлов, которые включены в основной файл конфигурации named.conf. Имена этих файлов начинаются с named, потому что это имя процесса, который запускает BIND. Начнем с настройки файла options.
Файл options
На сервере ns1 откройте этот файл:
sudo nano /etc/bind/named.conf.options
Над существующим блоком options создайте новый блок управления доступом ACL (access control list) под названием trusted. Здесь можно определить список клиентов, которые могут отправлять рекурсивные DNS-запросы (например, ваши серверы, находящиеся в том же ЦОД, что и ns1). Добавьте ns1, ns2, host1 и host2 в список доверенных клиентов:
acl "trusted" {
10.128.10.11; # ns1 - can be set to localhost
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
Теперь, когда у вас есть список доверенных DNS-клиентов, можно отредактировать блок options. В настоящее время начало блока выглядит следующим образом:
. . .
};
options {
directory "/var/cache/bind";
. . .
}
Под директивой directory добавьте выделенные строки конфигурации (и укажите соответствующий IP-адрес сервера ns1):
. . .
};
options {
directory "/var/cache/bind";
recursion yes; # enables resursive queries
allow-recursion { trusted; }; # allows recursive queries from "trusted" clients
listen-on { 10.128.10.11; }; # ns1 private IP address - listen on private network only
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
};
Теперь сохраните и закройте файл named.conf.options. В приведенной выше конфигурации указано, что только ваши доверенные серверы смогут запросить внешние домены у DNS-сервера.
Затем нужно настроить файл local, чтобы определить DNS-зоны.
Настройка файла local
На ns1 откройте файл named.conf.local:
sudo nano /etc/bind/named.conf.local
По идее, сейчас в файле нет ничего, кроме нескольких комментариев. Здесь нужно указать зоны прямого и обратного просмотра. Зоны DNS определяют конкретную область управления и определения записей DNS. Поскольку домены будут находиться в субдомене «nyc3.example.com», мы будем использовать его как зону прямого просмотра. Внутренние IP-адреса серверов находятся в IP-пространстве 10.128.0.0/16, потому мы создадим зону обратного просмотра, чтобы определять обратные просмотры в этом диапазоне.
Добавьте зону прямого просмотра, заменив имя зоны и внутренний IP-адрес вторичного DNS-сервера в директиве allow-transfer:
zone "nyc3.example.com" {
type master;
file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
Учитывая, что вы используете частную подсеть 10.128.0.0/16, добавьте зону обратного просмотра (обратите внимание, что имя этой зоны начинается с «128.10», обратно от «10.128»):
. . .
};
zone "128.10.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.10.128"; # 10.128.0.0/16 subnet
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
Если ваши серверы охватывают несколько частных подсетей, но находятся в одном и том же центре данных, обязательно укажите дополнительный файл зоны и зону для каждой отдельной подсети. Когда вы закончите добавлять все нужные зоны, сохраните и выйдите из файла named.conf.local.
Теперь, когда зоны указаны в BIND, необходимо создать соответствующие файлы зон прямого и обратного просмотра.
Создание файла зоны прямого просмотра
Файл зоны прямого просмотра определяет записи DNS для прямого просмотра DNS. То есть, когда DNS получает запрос имени, например host1.nyc3.example.com, он будет искать в файле зоны прямого просмотра для разрешения соответствующего внутреннего IP-адреса host1.
Создайте каталог, в котором будут находиться файлы зон. Согласно конфигурации named.conf.local, его расположение – /etc/bind/zones:
sudo mkdir /etc/bind/zones
В качестве основы для файла зоны прямого просмотра можно использовать файл зоны db.local. Скопируйте его в нужное место:
sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com
Откройте файл в редакторе:
sudo nano /etc/bind/zones/db.nyc3.example.com
Изначально он выглядит так:
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
Сначала нужно отредактировать запись SOA. Замените первый localhost доменом FQDN ns1, а затем замените root.localhost на admin.nyc3.example.com. Редактируя файл зоны, необходимо увеличить значение serial перед перезапуском процесса named. Мы увеличим его до 3. Теперь файл должен выглядеть примерно так:
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Затем удалите три записи в конце файла (после записи SOA). В исходном файле выше они отмечены комментарием «delete this line».
В конце файла добавьте записи своего сервера имен (замените имена своими данными). Обратите внимание, что во втором столбце указано, что это записи NS.
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Теперь добавьте записи A для ваших хостов, которые принадлежат к этой зоне. Сюда входят все серверы, чье имя должно заканчиваться на.nyc3.example.com. В данном случае нужно добавить записи A для ns1, ns2, host1 и host2 следующим образом:
. . .
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
Сохраните и закройте файл.
В результате файл зоны имеет такой вид:
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
Теперь пора заняться файлом (файлами) зоны обратного просмотра.
Создание файла(ов) зоны обратного просмотра
Файлы зоны обратного просмотра определяют записи DNS PTR для обратного просмотра DNS. То есть, когда DNS получает запрос по IP-адресу, например, 10.128.100.101, он будет читать файлы этой зоны для разрешения соответствующего полного доменного имени (host1.nyc3.example.com в этом случае).
На ns1 для каждой зоны обратного просмотра, указанной в файле named.conf.local, создайте отдельный файл. Этот файл (ы) зоны обратного просмотра можно создать на основе файла db.127. Скопируйте его в нужное место (имя целевого файла должно соответствовать определению вашей зоны обратного просмотра):
sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128
Отредактируйте файл зоны, соответствующий зоне (зонам) обратного просмотра, определенной в named.conf.local:
sudo nano /etc/bind/zones/db.10.128
Изначально файл будет выглядеть так:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
Так же, как и в файле зоны прямого просмотра, здесь нужно отредактировать запись SOA и увеличить значение serial. Этот блок должен выглядеть примерно так:
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Теперь удалите две записи в конце файла (после записи SOA). Выше они помечены комментарием «delete this line».
В конце файла добавьте записи своего сервера имен (замените имена на свои). Обратите внимание, что во втором столбце указано, что это записи NS.
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Затем добавьте записи PTR для всех ваших серверов, чьи IP-адреса находятся в подсети этой зоны. В данном примере она включает в себя все хосты, потому что все они находятся в подсети 10.128.0.0/16. Обратите внимание: первый столбец состоит из двух последних октетов внутренних IP-адресов серверов в обратном порядке. Не забудьте заменить имена и внутренние IP-адреса своими данными.
. . .
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
Сохраните и закройте файл зоны. Повторите этот раздел для каждой отдельной зоны обратного просмотра.
В результате файл имеет такой вид:
$TTL 604800
@ IN SOA nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
Проверка синтаксиса конфигурации BIND
Запустите следующую команду, чтобы убедиться, что в файлах нет ошибок:
sudo named-checkconf
Если ваши конфигурационные файлы named не содержат синтаксических ошибок, вы вернетесь в командную строку оболочки и не увидите сообщений об ошибках. Если команда обнаружит проблемы, просмотрите сообщение об ошибке и перечитайте раздел 2, а затем повторно запустите named-checkconf.
Команда named-checkzone может использоваться для проверки правильности ваших файлов зон. Ее первый аргумент указывает имя зоны, а второй – соответствующий файл зоны, которые определены в named.conf.local.
Например, чтобы проверить конфигурацию зоны прямого просмотра nyc3.example.com, запустите следующую команду:
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
А чтобы проверить конфигурацию зоны обратного просмотра 128.10.in-addr.arpa, выполните следующую команду:
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
Проверив все конфигурационные файлы, вы можете перезапустить сервис BIND.
Перезапуск BIND
Чтобы перезапустить BIND, введите:
sudo systemctl restart bind9
Если у вас настроен брандмауэр UFW, откройте доступ к BIND:
sudo ufw allow Bind9
Первичный DNS-сервер настроен и может обрабатывать запросы DNS. Теперь создадим вторичный сервер.
3: Настройка вторичного DNS-сервера
В большинстве сред рекомендуется создать вторичный DNS-сервер, который будет отвечать на запросы, если первичный сервер выйдет из строя. К счастью, вторичный DNS-сервер намного проще настроить.
На ns2 отредактируйте файл named.conf.options:
sudo nano /etc/bind/named.conf.options
В начале файла добавьте ACL с внутренними IP-адресами доверенных серверов.
acl "trusted" {
10.128.10.11; # ns1
10.128.20.12; # ns2 - can be set to localhost
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
Под директивой directory вставьте такие строки:
recursion yes;
allow-recursion { trusted; };
listen-on { 10.128.20.12; }; # ns2 private IP address
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
Сохраните и закройте файл named.conf.options. Этот файл должен выглядеть точно так же, как и файл named.conf.options сервера ns1, за исключением того, что он должен прослушивать внутренний IP-адрес ns2.
Теперь отредактируйте файл named.conf.local:
sudo nano /etc/bind/named.conf.local
Определите вторичные зоны, соответствующие зонам первичного DNS-сервера. Обратите внимание, что тип должен быть slave, файл не содержит пути, и в нем есть директива masters, которая должна указывать внутренний IP-адрес первичного DNS-сервера. Если вы определили несколько зон обратного просмотра на первичном DNS-сервере, обязательно укажите их все здесь.
zone "nyc3.example.com" {
type slave;
file "db.nyc3.example.com";
masters { 10.128.10.11; }; # ns1 private IP
};
zone "128.10.in-addr.arpa" {
type slave;
file "db.10.128";
masters { 10.128.10.11; }; # ns1 private IP
};
Сохраните и закройте файл.
Чтобы проверить файлы на наличие ошибок, введите:
sudo named-checkconf
Если ошибок нет, перезапустите BIND:
sudo systemctl restart bind9
Разрешите подключения DNS, изменив правила брандмауэра UFW:
sudo ufw allow Bind9
Теперь у вас есть первичный и вторичный DNS-сервер. Пора настроить клиентские серверы.