DNSSEC: unsigned и bogus обозначают разные результаты проверки
Фотография конкретного исполнения не приложена.
Отсутствие подписи в ответе не всегда является ошибкой DNSSEC. Нужно установить, должна ли конкретная часть дерева быть защищена по доступной цепочке доверия. Без этого обычную неподписанную делегацию легко перепутать со сломанной подписанной зоной.
RFC 4033 различает secure, insecure, bogus и indeterminate в контексте проверки. Bogus означает, что требуемая проверка не сошлась при соответствующем основании доверия. Insecure не является синонимом любой ошибки сети или любого timeout.
Внешний SERVFAIL способен иметь разные причины. Для вывода о DNSSEC нужны сведения resolver о конкретной стадии, времени и цепочке. Также локальная trust policy может менять контекст, поэтому результат другого resolver не всегда воспроизводит исходную проверку.
В приёмке сохраняют validation state, ожидаемую делегацию и диагностическое основание отказа. Сравнивают предусмотренную unsigned-зону и контролируемую ошибку подписанной. Отчёт должен локализовать причину. Само отсутствие RRSIG в удобном packet view не подтверждает bogus и не даёт оснований отключать validation ради устранения любого DNS-отказа.
Основание — Numbered DNSSEC chain, denial, key lifecycle and zone-integrity references with selected explicit updates, разделы RFC4033 5 Scope of the DNSSEC Document Set and Last Hop Issues; RFC6840 DNSSEC validation clarifications. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC DNSSEC и целостности DNS-зон. Это разбор механизмов, а не полный актуальный профиль algorithms. Реальные signer, resolver, trust anchors, parent policy и ключи не проверялись; DNS-запросы, публикация zones и изменения делегации не выполнялись.