Рейтинг:0

Миграция DNSSEC с переносом только ключей KSK

флаг ma

Укороченная версия: Если DNSSec-подписанный сон внезапно заменяет оба ZSK (и все записи, относящиеся к старому ZSK), и в то же время сохраняет KSK (на которые ссылается вышестоящий сервер). Это вызовет какие-то проблемы? И не вызовет ли это проблем после истечения TTL зоны/записи?

Длинная версия: Поэтому я заменяю авторитарный DNS-сервер 2012R2 (с файловой поддержкой), на котором размещено несколько зон DNSSEC.

Из того, что я понял, невозможно перенести ZSK для зоны, но можно перенести KSK. (Технически я могу перенести оба, но по какой-то причине могу импортировать только KSK в зону). Также невозможно добавить какие-либо «пользовательские» записи, связанные с DNSSEC, когда Windows Server помечает зону как подписанную.Восходящий DNS-сервер (ДВУ уровня страны) содержит только ссылки на KSK.

Если я правильно понимаю, Если я скопирую зону, сгенерировать новые ZSK и подписать. Затем подключите его к сети (будет иметь тот же IP-адрес, что и предыдущий сервер). Это должно привести только к проблемам с проверкой подписи во время TTL рассматриваемой зоны/записи (я полагаю), и то только в том случае, если кто-то закэшировал именно запись, а не запись-подпись? (Я также знаю, что некоторые DNS-серверы могут кэшировать больше, чем TTL зоны).

Рейтинг:0
флаг cn

Если DNSSec-подписанный сон внезапно заменяет оба ZSK (и все записи, относящиеся к старому ZSK), и в то же время сохраняет KSK (на которые ссылается вышестоящий сервер). Это вызовет какие-то проблемы?

Да. Вы, кажется, забываете, что записи DNS имеют TTL. Таким образом, рекурсивные распознаватели будут/могут иметь старые данные ключа в своем кеше (т. DNSKEY записи со списком старых ZSK) и, следовательно, ожидают, например, найти с ним подписи. "Вдруг" никогда не перепутается с DNS. Никакие изменения не должны производиться без льготных периодов.

Из того, что я понял, невозможно перенести ZSK для зоны, но можно перенести KSK.

Мне непонятно, что вы подразумеваете под "мигрировать" туда. ZSK по определению часто меняются, например, один раз в месяц или каждые 2 месяца, но с перекрытием.

Несмотря ни на что, у вас всегда есть этот уродливый метод изменить ситуацию, который работает, но открывает окно без безопасности:

  • удалить DS у родителя
  • подождите «достаточно» времени (по крайней мере, ДС ТТЛ и еще кое-что)
  • теперь ваша зона больше не защищена DNSSEC, вы можете мутировать ее содержимое по своему желанию, в том числе о ключах
  • как только вы достигли своей новой желаемой конфигурации и проверили, что DNSSEC в порядке, смоделировав конкретный ДС у родителя, то вы можете поставить это ДС запись обратно у родителя.

Конечно, если у вас есть какой-либо мониторинг в вашей зоне, который ожидает DNSSEC, он будет кричать во время процедуры (или, по крайней мере, тоже хороший тест для мониторинга).

флаг ma
«Мигрировать» — перенести ключ на другой сервер и сдать зону. Проблема в том, что у Windows, похоже, нет возможности предварительно опубликовать или дважды подписать зону одним ключом с каждого сервера... Он берет на себя управление DNSSEC, а затем не позволяет вам ничего делать.
флаг ma
TTL для зон, по-моему, сократился до 15 минут. Я знаю, что общедоступные серверы могут не соблюдать TTL ниже часа. Время простоя сервиса в течение часа допустимо (особенно когда затрагивается только аудитория с поддержкой DNSSEC, и я могу сделать это в ночное время). Если нет других временных меток/тайм-аутов, я должен их придерживаться. Удаление записей DS у родителя является альтернативным решением проблемы, но я пытаюсь найти лучшее решение.
Patrick Mevzek avatar
флаг cn
@Zerqent Почему вы не можете использовать те же ключи на новом сервере?
флаг ma
Я не могу найти способ сделать это на Windows Server. Вы можете импортировать ключ на другой сервер (он хранится в сертификате в Windows).Затем вы можете вызвать Add-DnsServerSigningKey, чтобы импортировать KSK. Если вы попытаетесь сделать это с помощью ZSK, он явно проигнорирует указанный вами ключ и просто сгенерирует новый (также, если вы посмотрите на параметры, на самом деле будет сказано, что параметр предназначен только для KSK)
Patrick Mevzek avatar
флаг cn
Для плавной миграции вам следует выполнить правильное обновление, поэтому в основном создайте новый ключ на новом сервере, убедитесь, что он добавлен на старый сервер, в запись DNSKEY, чтобы текущий KSK подписал новый ZSK. Если вы можете переместить сами подписи, найдите способ, чтобы новый сервер вычислял подписи и включал их в старый сервер. Через некоторое время (см. https://datatracker.ietf.org/doc/html/rfc7583#section-3.2 для справки) вы можете удалить старый ZSK в качестве ключа подписи, а затем полностью переместить зону на новый сервер, поскольку не используете старый ЗСК. Или стать мошенником (без DNSSEC, удалив DS в родительском).
Patrick Mevzek avatar
флаг cn
(Извините, я мало, если вообще ничего не знаю о специфике Windows, поэтому я надеюсь, что кто-то может добавить ответ, который поможет вам больше узнать об этой конкретной ОС; я просто дал несколько общих советов по обслуживанию DNSSEC).
флаг ma
Здоровья Патрик. Я был по колено в нескольких RFC :). однако, как только я подписываюсь с Windows, я не могу добавить запись DSKEY, поэтому в основном я остаюсь либо в этом сценарии (аварийное переключение всех ZKeys и ожидание TTL - или больше?), либо в отключении dnssec, переносе, а затем восстановлении.
Patrick Mevzek avatar
флаг cn
Представьте, что вы не выполняли какое-то «рутинное» запланированное обновление/обслуживание, но по каким-то причинам ваша текущая инфраструктура каким-то образом дала сбой, и вам пришлось «немедленно» перенести управление DNS/подписями+ключами на какой-то новый сервер, чтобы восстановить службу. Как бы вы справились с этим? Это может показаться далеким/ненужным, но все зависит от того, насколько критичен этот конкретный сервис по отношению к другим вещам (см. недавний сбой в FB: нарушение их зоны также блокировало различные внутренние инструменты), и спокойное управление изменениями сейчас также может вам помочь. составить план действий в экстренных случаях. Или наоборот.

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

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