Hello,
apologies if I am breaking the thread - I imported from the Mailman archive and thus have no message IDs. I am taking this opportunity to reply to two emails at once :)
On 11 Jul 2016, at 22:38, ietf-dane at dukhovni.org wrote:
Requesting "DO" is expected to subsume "AD". It does with BIND and "unbound". The libresolv API does not provide a mechanism to turn on the "AD" bit in requests made via res_search(3).
I have requested an enhancement for this at https://sourceware.org/bugzilla/show_bug.cgi?id=20358
The only relevant resolver flag RES_USE_DNSSEC turns on "DO", not "AD".
I can see how that happened pre-RFC6840 but today this is an annoying limitation. I have the impression Postfix has a private ‘clone’ of res_*, so maybe Postfix could change to +AD? It would seriously reduce DNS response sizes for your TLSA queries.
On 11 Jul 2016, at 23:12, cs at sys4.de wrote:
setting the AD-Bit without DO-Bit in a DNS query is a rather new addition to DNSSEC (Feb 2013 -- https://tools.ietf.org/html/rfc6840#page-10 ).
It is used when a client just wants the AD-Bit in the response, without the DNSSEC records. Only quite new DNS resolver support this.
In DNSSEC, there are only new resolvers. DNSSEC is too new to be running an old resolver.
The original DNSSEC standard RFC 4033-4035 as implemented in BIND 9, Unbound, MS DNS and other DNS resovlers, when a stub-resolver asks with the DO-Bit set, it will validate the data and return the DNSSEC-records plus the AD-Bit set in case all data validates.
Neither 4035 or 6840 are clear enough on this. But indeed all other implementations, including Google DNS, do validation + AD if DO is in the query.
If PowerDNS recursor does not set the AD-Bit on a query with DO-Bit set, it looks like the DNSSEC protocol is not implemented in a compatible way to existing software.
We did not expect anybody to rely on ‘DO implies AD’, as we didn’t think that usage made any sense. In light of the glibc limitation however, we are going to accommodate ‘older’ clients, tracked at https://github.com/PowerDNS/pdns/issues/4159
Kind regards,