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

Краткое резюме

Перечислим основные принципы, которым необходимо следовать при развертывании DNSSEC.

1. Размер ключа KSK должен быть достаточно большим, потому что это имеет большее влияние на безопасность DNS при компрометации ключа KSK. Период действительности (период обновления) для ключа ZSK должен быть достаточно коротким, потому что существует больший риск для угадывания ключа.
2. Закрытые ключи, соответствующие и ZSK, и KSK, не должны храниться в поддерживающем DNSSEC первичном авторитетном сервере, если name-сервер не должен выполнять динамических обновлений. Если динамические обновления поддерживаются, закрытый ключ ZSK, должен храниться на name-сервере с соответствующим управлением доступом на уровне файла и директории или в криптографически защищенном виде.
3. Создание подписи с использованием ключа KSK должно выполняться в режиме off-line с использованием ключа KSK-private, хранящегося off-line; затем множество ресурсных записей DNSKEY вместе с его RRSIG -ресурсной записью должны быть записаны в зонный файл первичного авторитетного name-сервера.
4. Хранение ключа ZSK-private и создание подписи с использованием данного ключа должно выполняться в режиме off-line; множество ресурсных записей вместе с RRSIG -ресурсными записями может затем быть записано в зонный файл первичного авторитетного name-сервера. Исключением является случай, когда name-сервер поддерживает динамические обновления. При этом ключ ZSK-private должен располагаться на name-сервере.

Минимизация раскрываемой DNS-информации

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

Существует вероятность, что атакующий попытается получить информацию о локальной сети с использованием сервисов DNS и использует данную информацию для выполнения атаки. Некоторые типы информации, например, IP-адреса публичных серверов, предназначены для того, чтобы быть доступными всем. Что касается другой информации, администратору DNS рекомендуется выполнить определенные действия при создании зонного файла, которые бы сводили раскрытие локальной сети к минимуму. Данный процесс должен быть выполнен до подписывания зоны. Информация о сети, которая должна быть абсолютно закрытой, не должна публиковаться в DNS совсем.

Выбор значений параметров в SOA RR

Первое действие, которое должен предпринять администратор DNS, – это гарантировать, что значения данных ресурсной записи SOA являются корректными. Значения в данной ресурсной записи определяют взаимодействие между первичным и вторичными серверами в зоне, а именно, с какой периодичностью вторичные серверы должны выполнять зонные пересылки с первичного сервера. Эти данные также содержат минимальное значение TTL, которое говорит клиентским resolver’ам, как долго находятся данные в кэше. Смысл этих полей следующий:

• Serial Number. Serial number в SOA RDATA используется для указания вторичным серверам, что произошли изменения в зоне и зонная пересылка должна быть выполнена. Данное значение должно возрастать при изменении данных в зоне.
• Refresh Value. Refresh value говорит вторичным серверам, сколько секунд проходит между зонными пересылками. Для зон, которые часто обновляются, данное значение должно быть маленьким (от 20 минут до 2 часов). Для зон, которые обновляются не часто, может быть указано большее число (от 2 до 12 часов). Для подписанных зон данное значение не должно быть больше, чем длина периода действительности RRSIG, чтобы гарантировать, что вторичные зоны не содержат зон с истекшими RRSIG. Данное значение также может зависеть от ограничений, связанных с шириной пропускания на стороне первичного сервера. Заметим, что если первичный сервер создает сообщение NOTIFY при своем обновлении, вторичный сервер будет немедленно выполнять зонную пересылку и не ждать, пока нужно будет обновлять с соответствии со значением refresh.
• Retry Value. Retry value является периодом времени, через который вторичный сервер должен попытаться выполнить зонную пересылку, если предыдущая попытка окончилась неудачно. Данное значение должно быть делителем значения refresh. Возможный диапазон значений для данного поля может быть от 5 минут до 1 часа.
• Expire Value. Expire value является временем, в течение которого вторичный сервер должен считать зонную информацию действительной, если он не может установить соединение с первичным сервером для получения обновления. Данное поле позволяет вторичным серверам продолжать функционировать при различных сетевых сбоях. Значение зависит от частоты изменений в зоне и надежности соединения между name-серверами, оно может быть от 2 до 4 недель.
• Minimum TTL. Значение minimum TTL является значением по умолчанию для всех множеств ресурсных записей в зоне, если они сами не имеют собственного значения TTL, указанного в зонном файле. Данное значение зависит от того, как часто информация изменяется в зоне. Если зона статическая, значение может быть большим; если динамическая, значение должно быть маленьким. Однако для зон, которые используют DNSSEC значение должно быть достаточно большим, чтобы информация оставалась в кэше до тех пор, пока она является действительной. Считается, что минимальным значением должно быть 30 секунд, рекомендуемый диапазон – от 30 минут до 5 дней.

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

1. Значение refresh в SOA ресурсной записи зоны должно быть выбрано в зависимости от частоты обновлений. Если зона подписана, значение refresh должно быть меньшим, чем период действительности RRSIG.
2. Значение retry в SOA ресурсной записи зоны должно равняться 1/10 от значения refresh.
3. Значение expire в SOA ресурсной записи зоны должно быть от 2 до 4 недель.
4. Минимальное значение TTL должно быть между 30 секундами и 24 часами, чтобы гарантировать, что устаревшие множества ресурсных записей будут очищены из кэшей клиентов.