[dns-operations] Any known AD=1 intolerant iterative resolvers?

Florian Weimer fw at deneb.enyo.de
Wed Apr 15 17:25:30 UTC 2020

* Viktor Dukhovni:

> On Wed, Apr 15, 2020 at 07:23:37AM +0200, Florian Weimer wrote:
>> > My instinct is that it is now safe to just always send AD=1 in queries,
>> > which would partly resolve the issue, but if that is liable to break
>> > lookups via some extant resolvers, then AD=1 would need to be
>> > configurable via options in /etc/resolv.conf or similar.
>> This approach does not work because you do not know whether the
>> recursive resolver merely echoes back the AD bit, or has actually
>> performed DNSSEC validation.
> That's not the question I'm asking.
>> I'm also not sure if the AD bit will be set for local authoritative
>> data in the recursive resolver, which did not undergo DNSSEC
>> validation.
> That's not the question I'm asking.
>> So the answer to the question whether you can send AD=1 queries
>> without increasing the query failure rate does not really matter
>> because Postfix cannot use that anyway.
> Well, in practice it can and does, and it works reliably with e.g. BIND,
> unbound, ... as the immediate (local) upstream resolver.  If the
> upstream resolver is not local, all bets are off anyway and the warranty
> is void.
> I just need to know whether a stub resolver that does not support DO=1
> can safely, by default, send AD=1.
> Your points are valid in general, but entirely out of scope in the
> supported case, because the forwarder is a modern resolver on the
> loopback interface.  But the stub resolver setting AD=1 needs to
> not encounter breakage also in the unsupported (for Postfix) cases.

My concern is that given the limitations of the AD flag, there is no
value in sending it by default, without explicit configuration.  So
even if it is save to send the flag by default (in the sense that it
does not increase query failure rates), you can't use the flag in
responses.  Ergo, there is no incentive to send it by default.

At least that's what I was thinking while writing my response. 8-)

More information about the dns-operations mailing list