Why does an authoritative name server not DNSSEC-validate its own results?
Because it can't, not without being a recursive nameserver itself, which would be bad.
To fully validate DNSSEC, you need to start from the root and go through the whole link of DS/DNSKEY records, and the authoritative resolver you consult is not authoritative on all of that, just its part down the link.
See for example section 6 of RFC 4033, "Resolver consideration":
A security-aware resolver has to be able to perform cryptographic
functions necessary to verify digital signatures using at least the
mandatory-to-implement algorithm(s). Security-aware resolvers must
also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to obtain necessary DNSKEY, DS, and RRSIG records. A security-aware
resolver should be configured with at least one trust anchor as the
starting point from which it will attempt to establish authentication
chains.
And RFC 4035, section §3.2.3 "The AD Bit" under "Recursive Name Servers":
The name server side of a security-aware recursive name server MUST
NOT set the AD bit in a response unless the name server considers all
RRsets in the Answer and Authority sections of the response to be
authentic. The name server side SHOULD set the AD bit if and only if
the resolver side considers all RRsets in the Answer section and any
relevant negative response RRs in the Authority section to be
authentic. The resolver side MUST follow the procedure described in
Section 5 to determine whether the RRs in question are authentic.
However, for backward compatibility, a recursive name server MAY set
the AD bit when a response includes unsigned CNAME RRs if those CNAME
RRs demonstrably could have been synthesized from an authentic DNAME
RR that is also included in the response according to the synthesis
rules described in [RFC2672].
As for:
it makes a difference whether an answer gets validated or not
Of course it does, that is the whole purpose of DNSSEC. But end clients do not consult authoritative nameservers directly during the course of normal operations. They use a recursive nameserver, which in turns iterate over various different authoritative nameservers to get the final reply, and which can validate DNSSEC if configured to do so.
I was wondering why SSHFP records did not work doing ssh -o VerifyHostKeyDNS from the name server itself
Whatever problem you have here is not related to anything above. ssh should use whatever OS level resolver is configured to get the data.
See https://github.com/openssh/libopenssh/blob/05dfdd5f54d9a1bae5544141a7ee65baa3313ecd/ssh/dns.c#L191 which is inside the verify_host_key_dns function:
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);
}
and getrrsetbyname is defined in https://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/openbsd-compat/getrrsetbyname.c and is basically a wrapper around res_query which is the low level libc binding to do DNS queries.
I have found at https://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/ some details on ssh behavior between a validated (DNSSEC) SSHFP record or not.
