NSEC DNSSEC подтверждает отсутствие через диапазон имён и типы записей
Фотография конкретного исполнения не приложена.
Пустой ответ сам по себе не является криптографическим доказательством отсутствия данных. Для DNSSEC важно проверить предусмотренный denial proof. Иначе отсутствие нужной записи легко спутать с неполным или неподходящим ответом.
RFC 4034 задаёт NSEC с next name и type bitmap. Эти части помогают доказывать разные утверждения: отсутствие имени в диапазоне либо нужного типа у существующего имени. RFC 4035 описывает использование подписанных данных при validation отрицательного ответа.
Нельзя читать любой NSEC как универсальный запрет существования всей ветви. Нужно учитывать owner, диапазон, тип запроса и wildcard context. Также сам факт наличия NSEC без успешной проверки его подписи не даёт требуемого доверия к отрицательному результату.
В приёмке проверяют отсутствующее имя и отсутствующий RRtype отдельно. Сопоставляют ответ с конкретным доказательством и validation state. Отчёт должен показывать, какое утверждение подтверждено. Один пустой answer section не доказывает корректную отрицательную DNSSEC-валидацию и не объясняет, почему приложение не получило нужный адрес.
Основание — Numbered DNSSEC chain, denial, key lifecycle and zone-integrity references with selected explicit updates, разделы RFC4034 NSEC record; type bit maps; RFC4035 Authenticated denial of existence. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC DNSSEC и целостности DNS-зон. Это разбор механизмов, а не полный актуальный профиль algorithms. Реальные signer, resolver, trust anchors, parent policy и ключи не проверялись; DNS-запросы, публикация zones и изменения делегации не выполнялись.