Я использую авторитетную версию BIND 9.9.5-9 + deb8u8-Debian на Debian Jessie. У меня есть рабочая зона для robin.info который работает правильно (различные тесты сообщают об успехе, например, инструмент проверки DNS pingdom.com)
Я пытаюсь защитить его с помощью dnssec. Я следую инструкциям, данным в Руководство по BIND DNSSEC, глава 4 с легким началом. Я успешно сгенерировал ZSK и KSK и обновил свою зону, добавив строки, выделенные жирным шрифтом:
zone "robin.info" {
type master;
file "/etc/bind/zones/robin.info";
include "/etc/bind/include-zones/acls";
каталог ключей "/etc/bind/dnssec/robin.info/2016"; встроенное подписывание да; автоматическое поддержание DNS;
}; Я убедился, что нет .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) Предложение ошибки с серийными номерами (начальная ошибка была last serial 2016121113 != transaction first serial 2016121111). Однако я думал, что мне не нужно слишком беспокоиться о сериалах, поскольку в базе знаний ISC я могу прочитать это:
Обратите внимание, что серийный номер в этом ответе не совпадает с номером в файле 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 на примерах». По сути, только одна зона должна быть главной, а другая - подчиненной. После добавления нескольких acls, ключей и уведомлений для 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;
};
};
Ядро кажется could not get zone keys for secure dynamic update сообщение об ошибке, поэтому возврат к беззнаковому; и поскольку он не проходит путь подписи, который автоматически подталкивает SOA для подписи, он жалуется, что SOA устарела.
Я получил такое же сообщение об ошибке при добавлении подписи в три зоны и почесал голову, затем вздохнул и просто перезапустил имя полностью. Это решило проблему для меня. Привязать 9.11.0P3.
Я не припомню, чтобы когда-либо сталкивался с этой проблемой при добавлении подписи, но все остальные зоны были подписаны давным-давно с переходом под более раннюю версию Bind. Кроме того, эти три зоны являются файлами обратного 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.