Настройка Stub зоны на сервере Bind
Данная настройка требует правильную цепочку доверенностей DNS серверов. Если у вас её нет, впишите следующие параметры в файл.
dnssec-enable no;
dnssec-validation no;
Static-stub позволяeт указать конкретные IP по которым следует обращаться для преобразования имен (resolving) заданных зон, в обход обслуживающих данные зоны DNS-серверов;
Откройте конфигурационный файл bind.
nano /etc/named.conf
Настройте зону следующим образом:
zone "stub.test" {
type static-stub;
server-addresses { 192.168.0.1; 192.168.0.50; };
};
* где stub.test — домен, для которого нужно делать перенаправление запросов; 192.168.0.1, 192.168.0.50 — адреса DNS-серверов на которые перенаправляем запросы.
Перезапустите bind, чтобы применить настройки:
Зоны пересылки
Данная настройка требует правильную цепочку доверенностей DNS серверов. Если у вас её нет, впишите следующие параметры в файл.
dnssec-enable no;
dnssec-validation no;
Задачу перенаправления DNS-запросов можно решить с помощью зоны типа forward. Настройка выполняется следующим образом:
zone "stub.test" {
type forward;
forwarders { 192.168.0.1; 192.168.0.30; };
};
Перезагрузить сервис:
systemctl restart named
Русскоязычные имена
Для записи русскоязычных имен хостов или доменов, нужно узнать как доменное имя выглядит в Punycode-представлении. Например с посмощью сервиса 2ip. И вписать имя в punycode-представлении в файл зоны, например:
xn----gtbc2bgjip IN A 10.81.200.222
Использование DNSSEC
DNSSEC описана в стандарте RFC 4033.
Создайте отдельный каталог для файлов с ключами.
mkdir /var/named/keys
cd /var/named/keys
Файлов генерируется достаточно много, поэтому для каждой зоны можно создать отдельную директорию с ключами.
Для работы DNSSEC требуется создать master-ключ (KSK, Key Signing Key), который
будет использован для создания цифровых подписей для других ключей, и ключи для
каждой из локальных зон (ZSK, Zone Signing Key).
Создаём KSK-ключ:
dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE example.net
Generating key pair......+++.....+++
Kexample.net.+005+38287
Создаём ZSK-ключ:
dnssec-keygen -a RSASHA1 -b 2048 -n ZONE example.net
Generating key pair.....+++ ..+++
Kexample.net.+005+55896
Для того, что бы ключи сгенерировались, необходима рандомная составляющая. Для этого нужно переместить мышку несколько раз при генерации ключей, либо выполнять команды генерации с дополнительным параметром -r /dev/urandom например:
dnssec-keygen -f KSK -a RSASHA1 -b 2048 -r /dev/urandom -n ZONE example.net
Делаем ключи доступными для чтения процессу named:
chown named. *
Включим в настройках named.conf ведение лога DNSSEC для упрощения анализа возможных проблем.
Подготовим директорию для хранения лога:
mkdir /var/log/bind/
chown named. /var/log/bind/
В named.conf пропишем путь к логу, который ограничим максимальным размером в 20 Мб:
logging {
channel dnssec_log {
file "/var/log/bind/dnssec.log" size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 3;
};
category dnssec {
dnssec_log;
};
};Отредактируем секцию options:
options {
...
key-directory "/var/named/keys";
sig-validity-interval 20 10;
};* где key-directory — каталог для хранения сгенерированных ключей, необходимо прописать тот, в котором мы формировали последние командой dnssec-keygen; sig-validity-interval — период действия ключей: дней/период обновления.
Для зоны редактируем:
zone "example.net" {
type master;
file "master/example.net";
key-directory "keys/";
inline-signing yes;
auto-dnssec maintain;
};Опция 'inline-signing yes' включает режим прозрачного формирования подписей, не
требуя внесения изменений непосредственно в файл зоны. При работе
inline-signing вручную поддерживаемый файл с зоной преобразуется в динамическую
зону, для которой создаётся цифровая подпись. Из-за этого выдаваемый сервером
серийный номер, отличается от серийного номера прописанного в файле с зоной.
Изменения DNSSEC производятся в jnl-файле с журналом изменений.
Проверяем, что у пользователя named/bind есть права на запись в каталог хранения зоны. При необходимости, меняем владельца, например:
chown -R named:named /var/named/master
Открываем на редактирование файл зоны и меняем серийный номер.
Перезапускаем bind.
После перезапуска named в директории /var/named/keys появятся следующие файлы:
example.net
example.net.jbk
example.net.signed
example.net.jnl
При запросе параметров зоны можно заметить появление нового поля RRSIG
dig example.net +dnssec
...
example.net. 600 IN A 1.2.3.4
example.net. 600 IN RRSIG A 5 3 600 2012021356423 20120415331566 21695 net. IKekIJa314313G/xZpQ+B2313eqaDceR/VNcdsdasxV2 ...
Так как DNSSEC основан на обеспечении цепочки доверия, чтобы процесс
верификации заработал, требуется чтобы регистратор заверил созданный KSK-ключ,
подтвердив своё доверие. Для этого создадим на основе KSK-ключа DSKEY-ключ
(Delegation Signature Key)
dnssec-dsfromkey Kexample.net.+005+38287
example.net. IN DS 38287 5 1 E8C01C9CA1252389A9CB4E
example.net. IN DS 38287 5 2 57EC936A479A94C32324123134234523492359A623 39712D53
Копируем две сгенерированные строки в интерфейсе ввода DSKEY на сайте
регистратора домена. Верификация заработает после того как регистратор обновит
параметры первичной зоны.
Для поддержки DNSSEC-проверки на стороне резолвера следует добавить в настройки named.conf:
options {
...
dnssec-enable yes;
dnssec-validation auto;
...
};Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.
Скачать документ