Безопасность DNS Query/Response

Аварийное обновление ключа

Аварийное обновление ключа происходит тогда, когда один или более ключей в зоне ( ZSK или KSK компрометируются или закрытая компонента потеряна и необходимо выполнить переподписывание. Данный тип обновления не является плановым, поэтому велика вероятность разорвать цепочку аутентификации, если администратору зоны необходимо выполнить процесс обновления.

Аварийное обновление ZSK

Администратор DNS может обновить компрометированный ключ ZSK более быстро, чем компрометированный ключ KSK, потому что компрометация влияет только на зону. Возможность более быстрого обновления является другой причиной, по которой администратор зоны выполняет обновление ключа ZSK более часто. Если администратор зоны имеет новую DNSKEY -ресурсную запись, уже опубликованную в зоне в качестве части набора ключей зоны (первые три шага в процессе, который рассматривался ранее), следующий шаг зависит от того, является ли ключ компрометированным.

Если используемый в текущий момент ключ ZSK компрометирован, администратор зоны может немедленно заменить его на новый ключ. Нет необходимости ждать, чтобы истек период TTL, потому что новый ключ уже опубликован к данному моменту. Администратор может просто удалить старые RRSIG из зоны и переподписать новым ключом ZSK раньше, чем предполагалось сделать плановое обновление. Функционирование DNS должно продолжиться нормально после такого переподписывания, без разрыва цепочки аутентификации.

Если новый ключ ZSK (следующий ключ ZSK, который будет использоваться) компрометирован, его следует заменить немедленно в множестве ключей зоны. Такая замена также может выполниться автоматически, потому что новый ключ не использовался для создания каких-либо RRSIG ; должно быть переподписано только множество ключей зоны. Также возможно просто удалить компрометированный ключ и заменить его новым ключом ZSK за одно обновление.

Однако существует опасность, что атакующий использовал скомпрометированный ключ ZSK для подделки ответов, исходящих из зоны. Такая опасность реальна в течение того времени, какое текущий ключ KSK остается активным, в соответствии с периодом обновления ключа KSK. После того как ключ ZSK был компрометирован, администратор зоны должен инициировать обновление ключа KSK как можно скорее.

Аварийное обновление KSK

Когда компрометирован ключ KSK зоны, единственным действием должно быть инициирование его обновления. Данное обновление, однако, не аналогично процессу планового обновления ключа KSK. Должен существовать способ оповестить администратора родительской зоны, что старый ключ KSK компрометирован и не следует принимать никаких сообщений об обновлении ключа KSK с использованием данного ключа. Замененный ключ должен быть передан и верифицирован с использованием некоторого безопасного канала, чтобы гарантировать идентификацию дочерней зоны, что может включать один или более неDNSSEC методов аутентификации. Данный процесс может быть аналогичен тому, который используется при установлении начального ключа KSK дочерней зоны.

Рекомендация:

Администратор DNS должен иметь способ аварийного контактирования с администратором родительской зоны, чтобы иметь возможность выполнять аварийное обновление ключа KSK.

Переподписывание зоны

Зонный файл переподписывается (т.е. заново создаются RRSIG -ресурсные записи), в следующих ситуациях:

• подписи истекли или истекут в скором времени;
• содержимое зонного файла изменилось в результате динамического обновления;
• один из ключей подписывания скомпрометирован или заменяется в плановом порядке.

Существуют две стратегии для переподписывания данных зоны.

• Полное переподписывание. Все существующие записи подписи ( RRSIG -ресурсные записи) удаляются, зонный файл сортируется заново, все NSEC -ресурсные записи создаются, и, наконец, создаются новые записи подписи. Полное переподписывание выполняется в следующих ситуациях:

  • зонный файл создается из некоторой back-end базы данных;
  • администратор зоны установил выполнение данного переподписывания в пакетном режиме для выполнения на конкретный день и время, основываясь на времени истечения действительности подписи.
• Инкрементальное переподписывание. NSEC ресурсные записи модифицированы, потому что существующее множество ресурсных записей удалено, NSEC -ресурсные записи добавлены, потому что новое множество ресурсных записей добавлено в зонный файл. В этом случае подписи создаются только для тех ресурсных записей, которые были изменены. Инкрементальное переподписывание выполняется, когда изменения в содержимом зонного файла минимальны, что обычно бывает после динамического обновления.

Рекомендации:

1. Периодическое переподписывание должно быть запланировано до истечения действительности RRSIG -ресурсных записей, существующих в зоне. Это уменьшит риск того, что подписанная зона будет фиктивной в результате истекших подписей.
2. Серийный номер в SOA ресурсной записи должен быть увеличен перед переподписыванием зонного файла. Если данная операция не сделана, вторичные name-серверы могут не получить новые подписи, потому что они выполняют обновление исключительно на основе соответствия серийного номера SOA. В результате этого некоторые поддерживающие безопасность resolver’ы не будут иметь возможность проверять подписи (и таким образом иметь безопасный ответ), а другие — будут.