Почему авторитетный сервер имен не проверяет DNSSEC свои собственные результаты?
Потому что он не может, не будучи рекурсивным сервером имен, что было бы плохо.
Чтобы полностью проверить DNSSEC, вам нужно начать с корня и пройти всю ссылку ДС/DNSKEY записи, и авторитетный распознаватель, с которым вы консультируетесь, не является авторитетным для всего этого, а только для его части по ссылке.
См., например, раздел 6 RFC 4033, «Рассмотрение распознавателя»:
Безопасный распознаватель должен уметь выполнять криптографические операции.
функции, необходимые для проверки цифровых подписей с использованием как минимум
обязательный для реализации алгоритм(ы). Безопасные распознаватели должны
также иметь возможность формировать цепочку аутентификации из нового
обученную зону обратно к ключу аутентификации, как описано выше. Этот
могут потребоваться дополнительные запросы к промежуточным зонам 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 функция:
результат = getrrsetbyname(имя хоста, DNS_RDATACLASS_IN,
DNS_RDATATYPE_SSHFP, 0, &отпечатки пальцев);
если (результат) {
verbose("Ошибка поиска DNS: %s", dns_result_totext(результат));
возврат -1;
}
если (отпечатки пальцев->rri_flags & RRSET_VALIDATED) {
*флаги |= DNS_VERIFY_SECURE;
debug("Найдено %d защищенных отпечатков пальцев в DNS",
отпечатки пальцев->rri_nrdatas);
} еще {
debug("Найдено %d небезопасных отпечатков пальцев в DNS",
отпечатки пальцев->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) ССХФП записывать или нет.
