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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
