Jeremie Courreges-Anglas([email protected]) on 2020.07.29 15:51:55 +0200: > On Sun, Jul 26 2020, Jeremie Courreges-Anglas <[email protected]> wrote: > > On Sat, Jul 25 2020, Sebastian Benoit <[email protected]> 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".
you are right, i forgot about that. > 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? I think its a good start. Fwiw i dont have other resolvers except localhost in resolv.conf, on laptops (all running unwind) as well as my gateway (running unbound). (Server type systems are a different thing of course). If the local resolver does not work, i want to notice it right away. > > 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 >
