FreeBSD-12
BIND-9.11
После некоторых усилий я исправил ошибку. Теперь я вижу это:
07-Jun-2019 18:01:25.299 zone parschecks/IN/public (unsigned): loaded serial 2019070701 (DNSSEC signed)
07-Jun-2019 18:01:25.299 dns_master_load: file format mismatch (not raw)
07-Jun-2019 18:01:25.299 zone parschecks.ca/IN/public (signed): loading from master file /usr/local/etc/namedb/master/parschecks.ca.hosts.signed failed: not implemented
07-Jun-2019 18:01:25.299 zone parschecks/IN/public (signed): not loaded due to errors.
Исходный вопрос:
У меня есть этот домен, который сообщает, что его ключ истек, когда я перезагружаю имя:
Jun 7 15:32:24 dns38 named[19583]: /usr/local/etc/namedb/master/parschecks.ca.hosts:53: signature has expired
Jun 7 15:32:25 dns38 named[19583]: zone parschecks.ca/IN/public (signed): receive_secure_serial: unchanged
Однако я вручную подписал этот домен:
2019-06-07 15:26:34: dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:26:50: dnssec-keygen -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:27:05: dnssec-signzone -N increment -S -o parschecks.ca parschecks.ca.hosts Kparschecks.ca.+013+37572
И файлы hosts вроде обновились:
-rw-r--r-- 1 bind bind 609 Mar 12 12:59 Kparschecks.ca.+008+29077.key
-rw------- 1 bind bind 1776 Mar 12 12:59 Kparschecks.ca.+008+29077.private
-rw-r--r-- 1 bind bind 479 Mar 12 12:59 Kparschecks.ca.+008+32223.key
-rw------- 1 bind bind 1200 Mar 12 12:59 Kparschecks.ca.+008+32223.private
-rw-r--r-- 1 bind bind 479 Feb 19 21:17 Kparschecks.ca.+008+43116.key
-rw------- 1 bind bind 1200 Feb 19 21:17 Kparschecks.ca.+008+43116.private
-rw-r--r-- 1 bind bind 346 Jun 7 15:24 Kparschecks.ca.+013+35858.key
-rw------- 1 bind bind 187 Jun 7 15:24 Kparschecks.ca.+013+35858.private
-rw-r--r-- 1 bind bind 346 Jun 7 15:26 Kparschecks.ca.+013+37572.key
-rw------- 1 bind bind 187 Jun 7 15:26 Kparschecks.ca.+013+37572.private
-rw-r--r-- 1 bind bind 345 Jun 7 15:26 Kparschecks.ca.+013+50724.key
-rw------- 1 bind bind 187 Jun 7 15:26 Kparschecks.ca.+013+50724.private
-rw-r--r-- 1 bind bind 344 Jun 7 15:27 dsset-parschecks.ca.
-rw-r--r-- 1 bind bind 9515 Apr 18 12:03 parschecks.ca.hosts
-rw-r--r-- 1 bind bind 512 Mar 22 17:28 parschecks.ca.hosts.jbk
-rw-r--r-- 1 bind bind 2395 Apr 18 12:28 parschecks.ca.hosts.jnl
-rw-r--r-- 1 bind bind 15960 Jun 7 15:32 parschecks.ca.hosts.signed
-rw-r--r-- 1 bind bind 128161 Jun 7 15:43 parschecks.ca.hosts.signed.jnl
named.conf содержит это:
zone "parschecks.ca" {
type master;
file "/usr/local/etc/namedb/master/parschecks.ca.hosts";
key-directory "/usr/local/etc/namedb/master/";
auto-dnssec maintain;
inline-signing yes;
};
Мы находимся в процессе перехода к встроенному подписанию, но пока не смогли заставить его работать. Если мы удалим пункты автоматического обслуживания из записи зоны в named.conf, файл зоны по-прежнему будет считаться истекшим.
rndc -s 127.0.0.1 reload parschecks.ca
zone reload up-to-date
В файле hosts ничего не изменилось. Но после увольнения загружаться не будет. Какой шаг мне не хватает?
Комбинация настройки named для обработки процесса подписания для вас (auto-dnssec maintain), при этом он работает из управляемого вручную файла зоны (предположительно без подписи) в качестве входных (inline-signing yes), но затем также вручную подписать зону (вызвав dnssec-signzone) не ожидается, что сработает, и более чем вероятно объясняет, как все стало запутано.
Что касается того, как очистить беспорядок (я ожидаю, что это потребуется независимо от того, в каком направлении вы решите двигаться), я бы предложил просто начать с неподписанной версии файла зоны (при необходимости очистите его вручную, хотя он звучит как parschecks.ca.hosts должен быть без знака).
Я говорю это, потому что теперь у вас есть все эти автоматически сгенерированные файлы (файл журнала для самого файла зоны, автоматически подписанная зона с журналом), содержащие данные, которые могут не соответствовать вашим намерениям, а с файлами журнала есть проблема, что журнал может быть не синхронизированными с соответствующим файлом зоны. (Похоже, вы перезаписали автоматически созданный подписанный файл, как указано, жаловался, что этот файл был не в ожидаемом формате для inline-signing setup, а затем и этот файл журнала, вероятно, тоже не синхронизирован).
Я также вижу значительное количество ключевых файлов в этом каталоге, но, не видя ключевых метаданных, трудно сказать, вызовет ли это проблему (возможно, будет разумно очистить и это).
В любом случае, конечно, сначала создайте резервную копию всего, но затем процесс очистки, вероятно, будет состоять из удаления всего, кроме неподписанного файла зоны + фактически используемых ключевых файлов, и начать с чистого листа с named настроен для режима подписи, который вы действительно собираетесь использовать (вам нужно решить).
В целом, я бы посоветовал просто избегать dnssec-signzone полностью, поскольку он довольно устаревший и неудобный (у вас есть дополнительный шаг при внесении изменений, но также повторяющийся дополнительный шаг, основанный на времени, для обновления подписей, независимо от того, вносите ли вы какие-либо изменения или нет, и вам нужно как-то с этим справиться).
Автоматизированный процесс подписи в BIND существует уже много лет (по крайней мере, через 10 лет), поэтому мне не имеет смысла рассматривать dnssec-signzone когда у вас даже нет рабочей настройки, основанной на этом в качестве отправной точки (если, конечно, вы хорошо знакомы с этой настройкой и вам нужно будет подготовиться больше перед переключением).
Чтобы узнать, как настроить автоматическую подпись, см. Руководство по BIND DNSSEC.
Исправление моей ситуации, касающееся работы dnssec-signzone, было:
Убедитесь, что имя домена в SOA совпадает именно домен, для которого публикуется зона DNS.
Убедитесь, что любой .jnl и .jbk файлы для зоны удаляются.
Убедитесь, что любой .signed файл для зоны удаляется.
Убедитесь, что все встроенные записи RRSIG удалены из главного файла.
Убедитесь, что используемый ключ подписи зоны (ZSK) правильно подписан ключом подписи ключа (KSK) для этой зоны.
Убедитесь, что записи ресурсов DSKEY в зоне соответствуют хэшам для ключей, которые вы собираетесь использовать.
Удалите любые другие ключи для зоны, которые могут присутствовать.
Используйте dnssec-signzone с параметром -S «умная подпись» и параметром -o имя_домена, если файл главной зоны не имеет точно такого же имени зоны. Не указывайте конкретный ключевой файл. Не используйте параметр -N для отмены схемы нумерации зон по умолчанию «приращение». (Если вы не знаете об этом намного больше, чем я)
При использовании встроенной подписи зоны НЕ должны быть динамическими. (Встроенная подпись ISC в ISC BIND 9.9.0 - Примеры
Ряд основных файлов зоны изначально страдали от одного или нескольких исправленных выше дефектов, многие из которых затем были усугублены попытками диагностировать проблему, оставив артефакты в зоне. мастера каталог. Эти файлы зон нормально работали с BIND-9.8, но, очевидно, некоторые из них противоречили ожиданиям от 9.11. и требования встроенной подписи.
Эти дефекты, вероятно, были причиной того, что встроенная подпись не работала для одних зон, в то время как для других. Я не смог найти никаких записей в журнале, которые указывали бы на тип ошибки и named-checkconf -z не выявил ни одного. Запуск с именем на переднем плане на другом порту и загрузка дефектных зон с использованием параметров отладки давали подсказки о том, как действовать, но никогда не указывали на запись дымящегося пистолета в файлах зон.
Еще неизвестно, решило ли это проблему с автоматическим обслуживанием и встроенной подписью.