Почему авторитетный сервер имен не проверяет DNSSEC-свои собственные результаты?

Почему авторитетный сервер имен не DNSSEC -проверяет свои собственные результаты?

Потому что он не может, не будучи сам рекурсивным сервером имен, что было бы плохо.

Чтобы полностью проверить DNSSEC, вам нужно начать с корня и пройти по всей ссылке записей DS/ DNSKEY, и авторитетный распознаватель, с которым вы консультируетесь, не является полномочным для всего этого, а только для его части вниз. ссылка на сайт.

См., например, раздел 6 RFC 4033, «Рассмотрение распознавателя».:

Резолвер, поддерживающий безопасность -, должен иметь функции, необходимые для проверки цифровых подписей с использованием как минимум обязательные -- -реализуют алгоритм (s ). Резолверы, поддерживающие безопасность -, должны также иметь возможность формировать цепочку аутентификации из нового обученную зону обратно к ключу аутентификации, как описано выше. Этот могут потребоваться дополнительные запросы к промежуточным зонам DNS для получения необходимых записей DNSKEY, DS и RRSIG. Служба безопасности -в курсе резолвер должен быть настроен по крайней мере с одним якорем доверия в качестве отправная точка, с которой он попытается установить аутентификацию цепи.

И RFC 4035, раздел §3.2.3 «Бит AD» в разделе «Рекурсивные серверы имен»:

Сторона сервера имен рекурсивного сервера имен, поддерживающего безопасность -, ДОЛЖНА НЕ устанавливайте бит AD в ответе, если только сервер имен не рассмотрит все RRsets в разделах ответа и полномочий ответа, чтобы быть аутентичный. Сторона сервера имен ДОЛЖНА устанавливать бит AD тогда и только тогда, когда сторона распознавателя рассматривает все наборы RRset в разделе ответа и любые соответствующие отрицательные ответы RR в разделе полномочий должны быть аутентичный. Сторона распознавателя ДОЛЖНА следовать процедуре, описанной в Раздел 5, чтобы определить, являются ли рассматриваемые RR подлинными. Однако для обратной совместимостирекурсивный сервер имен МОЖЕТ установить бит AD, когда ответ включает неподписанные записи CNAME RR, если эти CNAME Очевидно, что RR могли быть синтезированы из аутентичного DNAME. RR, который также входит в ответ согласно синтезу правила, описанные в [RFC2672].

Что касается :

, имеет значение, будет ли подтвержден ответ или нет.

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

Мне было интересно, почему записи SSHFP не работали при выполнении ssh -o VerifyHostKeyDNS с самого сервера имен

Какая бы проблема у вас ни возникла, она не связана ни с чем вышеперечисленным. sshдолжен использовать любой преобразователь уровня ОС, настроенный для получения данных.

См. https://github.com/openssh/libopenssh/blob/05dfdd5f54d9a1bae5544141a7ee65baa3313ecd/ssh/dns.c#L191, который находится внутри функции verify_host_key_dns:

    result = getrrsetbyname(hostname, DNS_RDATACLASS_IN,
        DNS_RDATATYPE_SSHFP, 0, &fingerprints);
    if (result) {
        verbose("DNS lookup error: %s", dns_result_totext(result));
        return -1;
    }


    if (fingerprints->rri_flags & RRSET_VALIDATED) {
        *flags |= DNS_VERIFY_SECURE;
        debug("found %d secure fingerprints in DNS",
            fingerprints->rri_nrdatas);
    } else {
        debug("found %d insecure fingerprints in DNS",
            fingerprints->rri_nrdatas);
    }

, а getrrsetbynameопределен вhttps://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/openbsd-compat/getrrsetbyname.cи в основном представляет собой оболочку вокруг res_query, которая является низкоуровневой привязкой libc для выполнения DNS-запросов.

Я нашел вhttps://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/некоторые подробности о sshповедении между подтвержденной (DNSSEC)SSHFPзаписью или нет.