Кратко

  • DNSSEC превратил отрицательный ответ DNS в проверяемое доказательство, подписав упорядоченные границы вокруг отсутствующих имён и типов записей.
  • NSEC3, Opt-Out и повторное использование проверенного кэша распределяют раскрытие данных, вычислительную нагрузку, гарантии делегирования и время начала работы нового имени.

Представьте архив, где каждый имеющийся документ снабжён подлинной подписью. Подписи доказывают подлинность показанных документов, но не подтверждают, что архивариус не спрятал запрошенный. Для доказательства отсутствия нужен ещё и подписанный каталог, порядок которого делает пробел видимым.

Именно такой смысловой переход совершило аутентифицированное доказательство отсутствия в DNSSEC.

Обычный DNS возвращает NXDOMAIN, когда имени нет, либо ответ без данных, когда имя существует, но запрошенного типа записи нет. Без проверки DNSSEC такое отрицание надёжно лишь настолько, насколько надёжен путь ответа. Атакующему на пути иногда достаточно заставить сервис исчезнуть, не подменяя его адрес.

RFC 4034 дал подписанной зоне способ описывать пробелы. Запись NSEC указывает следующее авторитетное имя в каноническом порядке и содержит карту типов, существующих у текущего имени. RFC 4035 задаёт проверку. Если запрос попадает между двумя подписанными границами, интервал доказывает отсутствие точного имени. Если имя есть, но нужного типа нет в подписанной карте, доказательство относится к типу. Ошибка имени должна также исключить подстановочное имя, которое могло бы дать ответ.

Протокол не создаёт отрицательную запись для каждого возможного вопроса — пространство меток слишком велико. Доказательством служит упорядоченный интервал: два аутентифицированных факта ограничивают пустоту.

Первое доказательство раскрывало каталог

У ясности NSEC есть и другая сторона. Поскольку каждая запись указывает следующее авторитетное имя, терпеливый опрашивающий может пройти цепочку и восстановить зону.

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

RFC 5155 ввёл NSEC3. Цепочка сохранилась, но читаемые имена заменены хешами. Валидатор всё ещё доказывает попадание хеша запроса в подписанный диапазон; перечисляющему приходится угадывать метки вне сети.

Это препятствие, а не секретность. Обычные имена предсказуемы и встречаются в сертификатах, журналах и ссылках. RFC 9276 подчёркивает убывающую отдачу: дополнительные итерации нагружают серверы и валидаторы, но не превращают угадываемые имена в тайну.

Opt-Out вписывает цену масштаба в доказательство

В огромных зонах с множеством делегирований отдельная NSEC3-запись для каждого неподписанного потомка создаёт нагрузку на подпись и память. Opt-Out позволяет диапазону покрывать небезопасные делегирования без отдельного хеша для каждого.

Экономия реальна, как и смысловая уступка. RFC 5155 говорит, что диапазон Opt-Out не утверждает ни наличие, ни отсутствие небезопасного делегирования внутри него. Остальные авторитетные данные защищены, но доказательство на этой границе намеренно уже. Зона получает более дешёвые изменения делегирования, отказавшись от одинакового криптографического утверждения о каждом неподписанном потомке.

Поэтому Opt-Out — решение управления, а не нейтральная настройка. Оно определяет, за какие отрицания отвечает оператор. RFC 9276 не рекомендует его малым зонам и допускает преимущественно для очень крупных, динамичных зон с небольшой долей подписанных делегирований.

Пробел из кэша отвечает на будущий вопрос

RFC 8198 разрешает валидирующему резолверу активно использовать кэшированные диапазоны NSEC или NSEC3. Если следующий запрос попадает в уже доказанную пустоту, отрицательный ответ можно синтезировать без нового обращения к авторитетному серверу.

Это снижает задержку, нагрузку и утечку бесполезных запросов вверх по цепочке, а также помогает против части атак со случайными метками. Но кэш применяет подписанное утверждение к будущим вопросам, поэтому срок его действия становится эксплуатационным условием.

TTL NSEC или NSEC3 вместе с настройками отрицательного кэширования определяют, когда заработает вновь созданное имя. Если опубликовать его сразу после широкого доказательства отсутствия, валидаторы всё ещё вправе отвечать из кэша «нет». Протокол действует правильно; план изменений проигнорировал срок действия отрицательного доказательства.

Современная практика выбирает простоту

RFC 9276 рекомендует NSEC, если свойства NSEC3 не нужны. При необходимости NSEC3 требуется ноль дополнительных итераций и рекомендуется пустая соль. Лишние итерации повышают вычислительную нагрузку, риск исчерпания CPU и ошибки совместимости; постоянная соль мало помогает, поскольку полное имя уже делает расчёт специфичным для зоны.

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

Эти RFC определяют механизм и актуальную практику, но не доказывают качество конкретного развёртывания. Его нужно измерять на реальных авторитетных и валидирующих границах.

Источники