On Wed, Jul 29, 2020 at 03:51:55PM +0200, Jeremie Courreges-Anglas wrote:
> 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".
Yes.
>
> 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 }".
>
unwind always does its own validation or decides it can't do
validation. In both cases you can trust the AD flag.
The AD flag is set if and only if unwind did a successful validation.
You cannot trust the RCODE (and answer) when AD is *NOT* set. That
seems like a strange and obvious statement but it is the main
difference to validating unbound. When you enable validation in
unbound and someone messes with your packets you will get a SERVFAIL.
You can trick unwind into believing that DNSSEC validation is not
possible in your current network location. It will still resolve but
it will NOT set AD.
In the context of the current discussion this means that you can't
validate SSHFPs, but you can still try to connect to your ssh server
if you have the fingerprint in known_hosts. The later is still save
even if people play tricks with DNS in your current location.
> 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
Yes. But even if it did not it would not matter since it will clear
AD.
> the answer to libunbound which cooks its own soup. So it looks like
No, the asr fallback is there for when your local network is truly
fucked - think last century equipment that knows DNS is udp/53 only and
max 512 bytes. While we already lower standards considerably in unwind
when we use libunbound compared to unbound the network still needs to
provide some things. Working edns0 is one of them, it's near
impossible to turn of in libunbound.
> 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
Nope, as stated above, you can trust AD.
> 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.
The last sentence is the problem in my opinion. trust-ad is a button
mere mortals cannot push.
The typical answer is: Oh, I use a vpn tunel and my nameserver is
behind the tunnel. Does the tunel terminate on the nameserver?
My enterprise vpn hands me 4 resolvers. They are in a different
subnet than the vpn concentrator.
> .El
> .El
> .Pp
>
> Lazy me would be tempted to just let asr trust 127.0.0.1 / ::1 by
probably only save if you know that you are talking to certain
software that does it's own validation (unwind, unbound). Not save if
you are talking to say dnscrypt-proxy.
> 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
>
--
I'm not entirely sure you are real.
