Сетевые средства Debian/BIND/Обслуживание первичных копий зон
Для определений хранимых локально зон предусмотрен файл /etc/bind/named.conf.local.
Описание зоны
[править]Рассмотрим следующий пример описания зоны example.org:
zone "example.org" {
type master;
file "/var/lib/bind/dynamic/db.example.org.signed";
allow-transfer { localhost; };
update-policy local;
auto-dnssec maintain;
key-directory "/var/lib/bind/keys/example.org";
};
Зона example.org определена здесь как первичная (master); файлом для ее хранения выбран db.example.org.signed в директории /var/lib/bind/dynamic.
Обычной практикой является разрешение AXFR-запросов только обслуживающим зону вторичным серверам, а также, возможно, пользователям самой данной системы. Предполагая, что данная зона не обслуживается никакими вторичными серверами, мы ограничили доступ к AXFR-запросу только лишь данной системой (localhost) опцией allow-transfer. (При наличии вторичных серверов, может иметь смысл дополнить этот список элементами key, содержащими используемые для связи с ними ключи транзакций.)
Кроме того, опция auto-dnssec maintain; разрешает BIND выполнять автоматическое обслуживание записей DNSSEC зоны, включая смену ключей согласно заданному расписанию. Директория, содержащая файлы ключей DNSSEC, указана опцией key-directory.
Обновление зоны самим BIND помешает внесению правок непосредственно в файл зоны (например, текстовым редактором.) Поэтому, имеет смысл также разрешить динамическое обновление зоны (в частности, программой nsupdate(8)), что и сделано опцией update-policy local;.
При желании по каким-либо причинам опустить поддержку DNSSEC для данной зоны, следует исключить опции auto-dnssec и key-directory из ее определения. Также, имеет смысл исключить и суффикс .signed из имени хранящего ее файла.
Если, кроме того, динамическое обновление зоны также не требуется, можно исключить и опцию update-policy. (Компоненту dynamic имени файла зоны можно при этом заменить на, например, zone.)
Создание ключей зоны
[править]Каждая зона обладает ключами двух типов:
- ключи, подписывающие ключи (англ. Key Signing Key, KSK);
- ключи, подписывающие записи зоны (англ. Zone Signing Key, ZSK).
Ключи зоны, как правило, делаются короче, чтобы упростить задачу по проверке получаемых с их помощью цифровых подписей. Следующая из этого меньшая их криптостойкость может быть компенсирована частым (по меньшей мере — несколько раз в год) обновлением. Напротив, ключи ключей (используемые, как следует из названия, только для подписи открытых ключей зоны — включая и самих себя) можно сделать более длинными, и менять реже.
Для создания ключей DNSSEC можно использовать поставляемую с BIND программу dnssec-keygen(8), подобно:
# (z=example.org \
&& dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK "$z" \
&& dnssec-keygen -a RSASHA1 -b 1024 -n ZONE "$z")
Здесь создаются ключи длины 2048 и 1024 бит, для использования с алгоритмами RSA и SHA-1, сохраняемые в файлы с именами вида Kexample.org.+005+1337.key (открытый ключ) и Kexample.org.+005+1337.private (закрытый ключ.)
Отметим, что поскольку опции -S, -P, -A, -R, -I, -D, -i не были использованы, созданные ключи будут иметь неограниченный срок действия.
После создания ключей, их требуется перенести в указанную в определении зоны директорию, разрешив также доступ к ним серверу BIND. Например (предполагая, что ключи созданы в текущей директории):
# (z=example.org \
&& d=/var/lib/bind/keys/${z%.} \
&& install -v -d -m 0750 -g bind -- "$d" \
&& install -v -m 0644 -- K"${z%.}".+005+*.key "$d"/ \
&& install -v -m 0640 -g bind -- K"${z%.}".+005+*.private "$d"/)
После добавления новых ключей, следует проинформировать BIND о необходимости обновить подписи записей зоны, используя одну из следующих команд:
- # rndc sign example.org — немедленно обновить подписи;
- # rndc loadkeys example.org — загрузить добавленные ключи и выполнить обновление подписей согласно расписанию.
Впрочем, что очевидно, перед этим следует создать сам файл зоны.
Создание начальной редакции файла зоны
[править]Начальная редакция файла db.example.org.signed зоны example.org может быть подобна:
$ORIGIN .
$TTL 86400 ; 1 day
example.org. IN SOA ns0.example.org. dnsmaster.example.net. (
2013236000 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns1.example.org.
NS ns2.example.org.
NS ns1.example.net.
NS ns2.example.net.
DNSKEY 257 3 5 AwEAA...
DNSKEY 256 3 5 AwEAA...
ns1 AAAA 2001:db8:42::53:53
A 192.0.2.53
ns2 AAAA 2001:db8:1337::53:53
A 192.0.2.153
Отметим, что адрес электронной почты администратора DNS (dnsmaster@example.net в данном примере) указывается в виде доменного имени — dnsmaster.example.net.. (Другими словами, разделитель @ адреса заменяется на точку.) Кроме того, имеет смысл использовать адрес в отличном домене (в данном примере — example.net, а не example.org), поскольку проблемы с обслуживанием DNS-зоны example.org могут сделать доставку на соответствующие почтовые адреса невозможной.
В качестве начального серийного номера зоны выбрано число 2013236000 — 236-й день 2013 г. (другими словами, 24 августа 2013; это число легко получить командой $ date -u +%Y%j000.) При необходимости полностью переписать файл зоны, серийный номер можно сбросить в значение, соответствующее текущей дате. (Если, конечно, оно не окажется меньшим, чем последнее использованное.)
Традиционно, в качестве серийного номера использовалось число, подобное 2013082403 — состоящее из года, месяца, дня, и номера редакции в течение дня. Однако при динамическом обновлении зоны (что является, по-видимому, необходимым для удобной работы с DNSSEC) серийный номер будет лишь увеличиваться на единицу при каждой правке, и данный формат не будет сохранен.
В данном примере, зону обслуживают четыре сервера имен (англ. name server, NS.) Имена двух из них (ns1.example.org, ns2.example.org) принадлежат этой же зоне, а значит требуют включения в зону соответствующих адресных (AAAA, A) записей. Напротив, адресные записи серверов ns1.example.net, ns2.example.net включены в зону example.net и не требуют какого-либо упоминания в рассматриваемой зоне.
Отдельно отметим, что адресные записи для обслуживающих зону example.org серверов ns1.example.org, ns2.example.org должны быть также продублированы и в родительской зоне (в данном случае — org.) Такое дублирование также называется клеем (англ. glue или glue records.)
Наконец, в зону включены открытые ключи — как ключ ключей (KSK; DNSKEY 257…), так и ключ зоны (ZSK; DNSKEY 256…) Данные для этих записей можно извлечь из файлов .key, созданных ранее программой dnssec-keygen(8).
Актуализация изменений
[править]Итак, для включения первичной зоны example.org в конфигурацию BIND выполнены следующие шаги:
- зона определена в конфигурации BIND (
/etc/bind/named.conf.local); - созданные пары ключей зоны помещены в выбранную директорию (
/var/lib/bind/keys/example.org); доступ к закрытым ключам разрешен только группеbind; - начальный вариант зоны помещен в файл
db.example.org.signedдиректории/var/lib/bind/dynamic.
Сообщить BIND о внесенных изменениях, а также подписать новую зону, можно следующими командами.
# rndc reload server reload successful # rndc sign example.org.
По выполнению этих команд, BIND должен начать обслуживание зоны, что можно проверить, например, выполнив локально команду dig:
$ dig +norecurse @::1 any example.org
В выводе этой команды должны обнаружиться связанные с корнем созданной зоны записи. (Прежде всего — записи типов SOA, NS, DNSKEY.)
Внести в зону записи, составляющие ее полезную нагрузку, можно используя nsupdate(8). Более подробно этот вопрос рассмотрен в разделе «Некоторые сведения о DNS.» В том же разделе приведена более детальная информация о диагностике состояния DNS-зон и внесению открытых ключей в родительскую зону.