Как обновить зону с помощью auto-dnssec: keep
Я использую авторитетный BIND 9.9.5-9 + deb8u8-Debian на Debian Джесси.
У меня есть рабочая зона для robin.info , которая работает правильно (различные тесты сообщают об успехе, например, в инструменте проверки DNS pingdom.com)
Я пытаюсь защитить ее с помощью dnssec. Я следую инструкциям, приведенным в BIND DNSSEC Guide , глава 4, с легким запуском. Я успешно сгенерировал ZSK и KSK и обновил свою зону, добавив строки, выделенные жирным шрифтом:
zone "robin.info" {
type master;
file "/etc/bind/zones/robin.info";
include "/etc/bind/include-zones/acls";
key-directory "/etc/bind/dnssec/robin.info/2016";
inline-signing yes;
auto-dnssec maintain;
};
Я убедился, что нет .jnl , .jbk , .signed и .signed.jnl файлы присутствовали с файлом зоны, затем перезапустили привязку с rndc reload и подтвердили, что зона загружена и имеет записи DNSKEY, хотя у меня было несколько ошибки в журнале:
11-Dec-2016 13:54:20.742 zone robin.info/IN/internal (signed): loaded serial 2016121111
11-Dec-2016 13:54:20.742 zone robin.info/IN/external (signed): loaded serial 2016121111
11-Dec-2016 13:54:20.750 zone robin.info/IN/external (signed): receive_secure_serial: unchanged
11-Dec-2016 13:54:20.750 zone robin.info/IN/external (signed): reconfiguring zone keys
11-Dec-2016 13:54:20.766 zone robin.info/IN/external (signed): next key event: 11-Dec-2016 14:54:20.750
11-Dec-2016 13:54:20.796 zone robin.info/IN/internal (signed): receive_secure_serial: unchanged
11-Dec-2016 13:54:20.796 zone robin.info/IN/internal (signed): reconfiguring zone keys
11-Dec-2016 13:54:20.805 malformed transaction: /etc/bind/zones/robin.info.signed.jnl last serial 2016121113 != transaction first serial 2016121111
11-Dec-2016 13:54:20.805 zone robin.info/IN/internal (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
Эти последовательные ошибки, кажется, вызывают проблемы в дальнейшем, когда я хочу обновить свою зону. Я вношу изменения в беззнаковую зону /etc/bind/zones/robin.info и увеличиваю свой серийный номер до 2016121121
11-Dec-2016 13:57:58.658 zone robin.info/IN/internal (signed): serial 2016121121 (unsigned 2016121121)
11-Dec-2016 13:57:58.658 zone robin.info/IN/internal (signed): could not get zone keys for secure dynamic update
11-Dec-2016 13:57:58.658 zone robin.info/IN/internal (signed): receive_secure_serial: not found
11-Dec-2016 13:57:58.659 malformed transaction: /etc/bind/zones/robin.info.jnl last serial 2016121121 != transaction first serial 2016121111
11-Dec-2016 13:57:58.659 zone robin.info/IN/external (unsigned): not loaded due to errors.
11-Dec-2016 13:57:58.659 all zones loaded
11-Dec-2016 13:57:58.659 running
11-Dec-2016 13:57:58.661 zone robin.info/IN/internal (signed): reconfiguring zone keys
11-Dec-2016 13:57:58.670 malformed transaction: /etc/bind/zones/robin.info.signed.jnl last serial 2016121115 != transaction first serial 2016121111
11-Dec-2016 13:57:58.670 zone robin.info/IN/internal (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
11-Dec-2016 13:57:58.670 zone robin.info/IN/external (signed): reconfiguring zone keys
11-Dec-2016 13:57:58.671 zone robin.info/IN/external (signed): next key event: 11-Dec-2016 14:57:58.670
. Я могу подтвердить с помощью dig , что мой старая зона все еще загружена (из SOA и изменения, которые не видны).
Здесь есть несколько сообщений об ошибках:
1) Предполагается, что у меня проблемы с ключами ("не удалось получить ключи зоны для безопасности динамическое обновление »). Однако у bind не было проблем с этим при первой загрузке, и мои ключевые файлы доступны для чтения bind (named запускается от имени пользователя bind , который является членом группы bind ):
xavier@dent:/etc/bind/zones$ ls -l /etc/bind/dnssec/robin.info/2016
total 17k
-rw-r--r-- 1 root bind 603 Dec 10 17:23 Krobin.info.+008+43324.key
-rw-r----- 1 root bind 1.8k Dec 10 17:23 Krobin.info.+008+43324.private
-rw-r--r-- 1 root bind 604 Dec 10 17:22 Krobin.info.+008+44679.key
-rw-r----- 1 root bind 1.8k Dec 10 17:22 Krobin.info.+008+44679.private
2) Предложение об ошибке с серийными номерами (исходная ошибка была последний серийный номер 2016121113! = Транзакция первый серийный номер 2016121111 ). Однако я думал, что мне не нужно слишком беспокоиться о сериалах,
один в файле example.com.db. Named отслеживает серийный номер
номер подписанной версии зоны независимо от беззнаковой
версия. Если беззнаковая зона обновляется новым серийным номером
это выше, чем в подписанной копии, затем подписанная копия
будет увеличен, чтобы соответствовать ему, но в противном случае два сохраняются
[1]
Пока что единственный способ обновить зону, который я нашел, - это остановить привязку, удалить .jnl , .jbk , .signed и .signed.jnl и снова запустите привязку. Это кажется неправильным, и мне нужно убедиться, что я увеличил серийный номер достаточно, чтобы активировать новую зону.
Что я делаю не так и как исправить свой dnssec?
Думаю, я наконец нашел основную причину своей проблемы. У меня есть два представления, которые были настроены на включение одного и того же главного файла зоны дважды.
Вы не можете использовать один и тот же файл для двух зон. Так что это недопустимо и вызвало мою проблему:
view "internal" {
match-clients ...;
zone "example.com" {
type master;
file "/etc/bind/zones/example.net";
};
};
view "external" {
match-clients ...;
zone "example.com" {
type master;
file "/etc/bind/zones/example.net";
};
};
Правильный способ совместного использования зоны описан в главе 4 документа " Понимание представлений в BIND 9, на примере "руководства. По сути, только одна зона должна быть главной зоной, а другая - подчиненной. После добавления нескольких ACL, ключей и также-notify для localhost в в нужных местах, я избавился от этих ошибок.
В итоге это моя окончательная конфигурация:
key "internal" {
// TSIG Key generated with dnssec-keygen -a HMAC-MD5 -b 512 -n USER internal
algorithm hmac-md5;
secret "XXXX";
};
view "internal" {
match-clients { key internal; ...IPs...; }; // our network
zone "robin.info" {
type slave;
file "/etc/bind/slave-zones/robin.info"; // Not the same file as external view!
masters { 127.0.0.1; };
};
};
view "external" {
match-clients { !key internal; "any"; }; // everyone else
server 127.0.0.1 {
/* Deliver notify messages to internal view with internal key. */
keys { internal; };
};
zone "robin.info" {
type master;
file "/etc/bind/zones/robin.info";
// ACL file with allow-transfer and also-notify
// including secondary DNS servers and 127.0.0.1
include "/etc/bind/acls";
key-directory "/etc/bind/dnssec/robin.info/2017";
inline-signing yes;
auto-dnssec maintain;
};
};
Похоже, что ядро не может получить ключи зоны для сообщения об ошибке безопасного динамического обновления , поэтому возвращается к беззнаковому; и поскольку он не проходит путь подписи, который автоматически подрывает SOA для подписи, он жалуется, что SOA устарел.
Я получил такое же сообщение об ошибке при добавлении подписи в три зоны и почесал голову, затем вздохнул и просто перезапустил имя целиком. Это решило проблему для меня. Привязка 9.11.0P3.
Я не припомню, чтобы когда-либо видел эту проблему при добавлении подписи, но все другие зоны были подписаны давным-давно при переходе под более раннюю версию привязки. Кроме того, эти три зоны являются файлами обратного DNS, поэтому их имя немного необычно. Это почти все, что мне нужно объяснить.
Итак: привязать ошибку, перезапустить полное имя, дать ей найти ключевые файлы и затем подписать.
У меня возникла аналогичная проблема, также при использовании связывания debian jessie. У меня нет нескольких представлений или общих файлов, но привязка жаловалась на те же ошибки, что и:
11-Dec-2016 13:54:20.796 zone robin.info/IN/internal (signed): reconfiguring zone keys
11-Dec-2016 13:54:20.805 malformed transaction: /etc/bind/zones/robin.info.signed.jnl last serial 2016121113 != transaction first serial 2016121111
11-Dec-2016 13:54:20.805 zone robin.info/IN/internal (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
Мое решение заключалось в использовании
rndc sync -clean
вместе с перезагрузкой привязки (даже если динамические обновления не включены!). От человека:
Sync changes in the journal file for a dynamic zone to the master file. If the
"-clean" option is specified, the journal file is also removed. If no zone is
specified, then all zones are synced.