Рейтинг:0

BIND 9.16 dnssec-policy по умолчанию не обновляет ключи автоматически

флаг ci

Три месяца назад я обновил свои DNS-серверы до BIND 9.16 (сейчас работает 9.16.25), чтобы воспользоваться преимуществами нового dnssec-политика по умолчанию вариант, который позволит мне легко запускать DNSSEC для моих доменов. В документации указывалось, что управление ключами будет происходить автоматически. Я реализовал это, протестировал локально, выглядело так, что все подписывалось просто отлично, и с миром все было в порядке. Ранее я не реализовывал DNSSEC ни в какой форме для этих зон.

Позже я узнал, что должен был загрузить свои записи DS своему регистратору, чтобы сообщить TLD, что мои зоны были подписаны, и это замкнуло бы цепь, чтобы позволить DNSSEC действительно произойти... поэтому я начал делать это в этом месяце. Однако при этом начались сбои, и я быстро узнал, что срок действия всех моих подписей истек через 15 дней после внедрения DNSSEC.

Я попытался сделать ручное переключение клавиш для одной зоны. Это изменило подписи для некоторых записей, но не для всех (например, без записей A, AAAA, CNAME). Я посмотрел в документах подробности о том, как dnssec-политика по умолчанию реализован и обнаружил, что срок действия ключей не истекает, но срок действия подписей истекает через 15 дней или около того... и что, если срок действия ключей не истекает, обновление никогда не будет запланировано. Так что мне делать с просроченными сигами?

Есть ли dnssec-политика по умолчанию действительно работает так, как рекламируется, и я упускаю что-то важное, или я действительно должен катить здесь свой собственный?

Соответствующие настройки в named.conf.options:

параметры {
[..]
        автоматическая проверка dnssec;
        dnssec-политика по умолчанию;
        dnssec-dnskey-kskonly да;
        каталог управляемых ключей "/var/lib/bind";
[..]
};
Patrick Mevzek avatar
флаг cn
«Позже я узнал, что должен был загрузить свои записи DS моему регистратору, чтобы сообщить TLD, что мои зоны были подписаны». Да, в противном случае нет цепочки доверия DNSSEC, поэтому тот факт, что ваша зона подписана, в значительной степени не имеет значения. Это своего рода ядро ​​​​дизайна DNSSEC, я рекомендую вам полностью понять это, прежде чем идти дальше (вы упомянули, что раньше не делали DNSSEC). Что касается «срок действия всех моих подписей истек через 15 дней после того, как я внедрил DNSSEC». это может иметь место, но отдельно от факта отправки DS в реестр через регистратора.
Christopher Hinkle avatar
флаг ci
Спасибо, Патрик. Проблема, с которой я столкнулся, заключалась в том, что как только я загрузил свои записи DS, все сломалось, потому что срок действия подписи истек. Мне нужно исправить срок действия подписи, прежде чем я смогу загрузить записи DS, чтобы ничего не сломалось, когда я это сделаю. У вас есть понимание, как я могу это сделать?
Patrick Mevzek avatar
флаг cn
Вы смотрели свои файлы журнала привязки? Подписи зон и обновления ключей должны регистрироваться? Это может помочь: https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP) (речь идет об изменениях в 9.17, и если вы можете, вы должны переключиться на него). См. https://bind9.readthedocs.io/en/v9_16_26/dnssec-guide.html: «Утверждение dnssec-policy вызывает подписание зоны и включает автоматическое обслуживание зоны. Это включает повторное подписание зоны как срок действия подписи и замена ключей на периодической основе».
Christopher Hinkle avatar
флаг ci
Я так и сделал. Я нашел ту же документацию, которую вы цитировали, и именно поэтому я для начала обновился до Bind 9.16 (я упомянул об этом в посте). Журналы показывают "перенастройку зональных ключей" для каждой зоны один раз в час. Тем не менее подписи истекли без их продления. Журнал dnssec показывает первоначальную конфигурацию, а затем ничего, кроме повторяющихся записей о реконфигурации, несмотря на истечение срока действия.
Patrick Mevzek avatar
флаг cn
Увеличьте уровень журнала и дважды проверьте права доступа ко всем файлам/каталогам. Также обратите внимание, что 9.17 должен быть еще проще в отношении DNSSEC, чем 9.16. Я рекомендую вам просто попробовать спокойно с нуля с игрушечной зоной и поэкспериментировать. На данном этапе с данными элементами я понятия не имею, почему у вас что-то не работает. Это: «Я пытался сделать ручное переключение клавиш для одной зоны». касается.Вы либо должны позволить привязке сделать все за вас, либо вы делаете все вручную, но смешивание тоже может быть рецептом проблем.
Patrick Mevzek avatar
флаг cn
«Журналы показывают «перенастройку ключей зон» для каждой зоны один раз в час». Я не думаю, что это должно быть ожидаемым случаем. ключи не надо менять так часто. KSK на год, ZSK на несколько недель. Что может меняться чаще, так это подписи. Если bind так часто говорит о ключах, может быть проблема.
Christopher Hinkle avatar
флаг ci
«Возможно, там есть проблема». ПРАВИЛЬНО! Вот почему я задаю вопрос. :) Я получил это только с использованием `dnssec-policy default` без какой-либо другой конфигурации. Он использует CSK вместо KSK/ZSK. Я не могу использовать 9.17, потому что я использую это на Ubuntu 20, которая на данный момент поддерживает только 9.16.
Рейтинг:0
флаг cn

См. пример в https://bind9.readthedocs.io/en/v9_16_26/dnssec-guide.html что говорит:

Включение автоматического обслуживания зоны DNSSEC и генерации ключей

Чтобы подписать зону, добавьте следующий оператор в ее предложение зоны в Файл конфигурации BIND 9:

параметры {
    директория "/etc/bind";
    рекурсия нет;
    ...
};

зона "example.com" в {
    ...
    dnssec-политика по умолчанию;
    ...
};

Оператор dnssec-policy заставляет зону быть подписанной и включает автоматическое обслуживание зоны. Это включает в себя повторное подписание зоны по мере истечения срока действия подписи и периодической замены ключей. Значение default выбирает политику по умолчанию, которая содержит значения, подходящие для большинство ситуаций.

Не то dnssec-политика может быть в зона заявление, или в параметры но тогда это применимо везде. Специально в начале, чтобы проверить вещи, вы можете ограничить вещи для каждой зоны. Но кроме этого, он должен работать из коробки с этой конфигурацией.

Если это не так для вас, вам необходимо предоставить более подробную информацию на основе ваших файлов журналов.

Позже на той же странице вы можете просмотреть ожидаемые строки журнала с приведенной выше конфигурацией:

07 апреля 2020 г. 16:02:55.045 зона example.com/IN (подписано): перенастройка ключей зоны
07 апреля 2020 16:02:55.045 перезагрузка конфигурации прошла успешно
07 апреля 2020 г. 16:02:55.046 keymgr: DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) создан для политики по умолчанию
07 апреля 2020 г. 16:02:55.046 Получение example.com/ECDSAP256SHA256/10376 (CSK) из хранилища ключей.
07 апреля 2020 г. 16:02:55.046 DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) теперь опубликован
07 апреля 2020 г. 16:02:55.046 DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) теперь активен
07 апреля 2020 г. 16:02:55.048 зона example.com/IN (подписано): следующее ключевое событие: 07 апреля 2020 г. 18:07:55.045

См. подписал в последней строке и метка времени, когда что-то (возможно, новые подписи) произойдет. Что касается:

Мне нужно исправить срок действия подписи, прежде чем я смогу загрузить записи DS, чтобы ничего не сломалось, когда я это сделаю.

Даже без проблем НИКОГДА не загружайте DS, не проверив локально, что валидация работает от начала до конца. Вы можете сделать это с помощью онлайн-инструмента, такого как DNSViz, явно указав новую DS, которую вы собираетесь добавить, и инструмент проверит все, как будто DS уже в порядке. Обратите внимание, что обычно KSK (из которых ДС запись в основном представляет собой хеш) предполагается, что она меняется «регулярно» на мелодию один раз в год каждые 2 года или что-то в этом роде. В этот момент вам нужно повернуть ДС также, но с предостережениями, если вы не хотите нарушить разрешение.

Christopher Hinkle avatar
флаг ci
_Config_: я намеренно поместил строку `dnssec-policy` в свой оператор параметров, потому что хотел, чтобы она применялась ко всем зонам. _Logfiles_: в моем журнале /var/log/named/dnssec есть описанные вами записи, за исключением того, что он никогда не говорит «(подписано)» после любой записи зоны, а «следующее ключевое событие» всегда происходит через 60 минут. По истечении 60 минут я получаю запись: «zone example.com/IN: перенастройка ключей зоны» и сразу после этого еще одну запись «следующее ключевое событие». Ничего никогда не перенастраивается. В журналах нет ошибок, связанных с этим процессом.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.