DNSSEC validation via AD bit?

[Gregory Shapiro]

sendmail's implementation of DANE determines whether DNSSEC validation was successful based on the presence of the AD bit in the response to the DANE record lookup.  

An equivalent dig lookup would be:

    % dig TLSA _25._tcp.smtp.gshapiro.net.
    ...
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 160
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ...
    ; ANSWER SECTION:
    _25._tcp.smtp.gshapiro.net. 5   IN      TLSA    3 1 1 8B2B0BF34A1D650A91399A28D5E6BBF377FB5319E9850078538164F5 557CD5BA

As you can see above the flags returned include "ad".

However, if sendmail is run on a server that lists the authoritative nameserver for a domain as a resolver (/etc/resolv.conf), the AD bit is not returned for lookups of those authoritative domains.  For example, when running the above dig command pointing at ns.gshapiro.net (running BIND 9.16.24), the AD bit is not returned:

    > dig TLSA _25._tcp.smtp.gshapiro.net. @ns.gshapiro.net
    ...
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45940
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ...
    ;; ANSWER SECTION:
    _25._tcp.smtp.gshapiro.net. 120 IN      TLSA    3 1 1 8B2B0BF34A1D650A91399A28D5E6BBF377FB5319E9850078538164F5 557CD5BA

Two questions:

1. Is there a reason when BIND is running as both a recursive server and an authoritative server for a domain, it doesn't set the AD bit when answering resolver queries for one of its authoritative domains?

2. Should sendmail not be trusting the AD bit in replies from the admin configured (i.e., trusted by admin) resolvers?  I.e., should sendmail be doing something different for DANE DNSSEC validation?  Note that DANE doesn't allow for treating the authoritative server differently so I don't believe we can use the AA bit as a substitute for the AD bit.

Thanks!