Why does an authoritative name server not DNSSEC-validate its own results?

Question

If I query a name server a record it is authoritative for it seems the answer does not get DNSSEC validated:

$ dig cloudflare.com @ns3.cloudflare.com

; <<>> DiG 9.16.22-Debian <<>> cloudflare.com @ns3.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28361
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com.                        IN      A

;; ANSWER SECTION:
cloudflare.com.         300     IN      A       104.16.133.229
cloudflare.com.         300     IN      A       104.16.132.229

;; Query time: 3 msec
;; SERVER: 162.159.0.33#53(162.159.0.33)
;; WHEN: Sat Nov 20 15:29:00 CET 2021
;; MSG SIZE  rcvd: 75

There is no "ad" flag returned, hence the answer is not DNSSEC validated. If I ask a non-authoritative server the same query, an "ad" flag is returned:

$ dig cloudflare.com @1.1.1.1

; <<>> DiG 9.16.22-Debian <<>> cloudflare.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23361
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com.                        IN      A

;; ANSWER SECTION:
cloudflare.com.         145     IN      A       104.16.132.229
cloudflare.com.         145     IN      A       104.16.133.229

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Nov 20 15:35:35 CET 2021
;; MSG SIZE  rcvd: 75

Could you please tell me:

1. Is this a correct and well defined behavior?
2. What is the reason no validation is done?
3. Could I change this behavior with ISC bind9 in the configuration? How?

(If this behavior is intentional one should never configure a name server to use its own name server software to resolve, because for some client software it makes a difference whether an answer gets validated or not: I was wondering why SSHFP records did not work doing ssh -o VerifyHostKeyDNS <host> from the name server itself).

Answer 1

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.