Сетевые средства 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-зон и внесению открытых ключей в родительскую зону.

См. также[править]