On Sun, Jul 26 2020, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> On Sat, Jul 25 2020, Sebastian Benoit <be...@openbsd.org> wrote:
[...]
>> If you enable trust-ad on a system that moves around, e.g. your laptop, you
>> will experience failures, which is why unwind tests for this and falls back
>> to non-trusting dhcp learned resolvers in such cases. In fact it also falls
>> back to the stub resolver, i.e. our libc resolver. Which makes me think that
>> trust-ad should not be used when you run unwind (because the whole point of
>> the fallback is that dnssec does not work). But thats a documentation issue.
One important thing to keep in mind: trust-ad is not so much about being
able to do DNSSEC validation. It's about trusting the validation done
by the resolver(s). So if the resolver can't do validation and ensures
that AD flag is clear in the reply there is no breach of contract.
> Thanks for pointing this out. I would expect from unwind(8) that it
> always clears the AD bit from its responses if it could not validate
> them. Inclusing when it falls back to dynamically learned resolvers or
> the libc resolver.
So I did a few tests and read some unwind(8) code, and it *appears* safe
to use unwind(8) along with "options trust-ad".
First you mention fallback to DHCP-learned resolvers. Those you should
probably not trust indeed, but it looks like unwind(8) attempts to use
them to perform its own validation. So the value of the AD flag in
unwind(8)'s response should be trustworthy. At least that's what I see
when I test unwind with "preference { dhcp }".
And then there's the asr fallback, tested with "preference { stub }".
unwind(8) allocates its own asr context, ignoring the global
/etc/resolv.conf and thus "options trust-ad". IIUC it then hands off
the answer to libunbound which cooks its own soup. So it looks like
unwind needs no special code to disable/ignore "options trust-ad".
I have no idea how unwind/libunbound behaves when using forwarders, the
"accept bogus" feature, (opportunistic) DoT or other stuff I'm probably
overlooking. But AFAICS using unwind + "options trust-ad" brings no
problem. cc'ing Florian, input welcome.
I think the issue with trust-ad is the list of resolvers that end up in
resolv.conf. I would expect people who use a resolver on localhost to
also have other resolvers listed in their /etc/resolv.conf, because of
a conscious choice (bsd.rd) or just because it should be more reliable.
It seems to me that the resolv.conf(5) manpage addition should cover
that. Or should I make it more explicit?
Index: share/man/man5/resolv.conf.5
===================================================================
RCS file: /d/cvs/src/share/man/man5/resolv.conf.5,v
retrieving revision 1.60
diff -u -p -r1.60 resolv.conf.5
--- share/man/man5/resolv.conf.5 25 Apr 2020 14:22:04 -0000 1.60
+++ share/man/man5/resolv.conf.5 25 Jul 2020 02:08:17 -0000
@@ -285,6 +285,15 @@ first as an absolute name before any sea
.It Cm tcp
Forces the use of TCP for queries.
Normal behaviour is to query via UDP but fall back to TCP on failure.
+.It Cm trust-ad
+Sets the AD flag in DNS queries, and preserve the value of the AD flag
+in DNS replies (this flag is stripped by default).
+Useful when applications want to ensure that the DNS resources they
+look up have been signed with DNSSEC and validated by the
+.Ic nameserver .
+This option should be used only if the transport between the
+.Ic nameserver
+and the resolver is secure.
.El
.El
.Pp
Lazy me would be tempted to just let asr trust 127.0.0.1 / ::1 by
default and let others deal with the edge cases, but where is the fun in
that... :)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
