On Wed, Jul 29 2020, Florian Obser <[email protected]> wrote:
> 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.
Thanks for confirming.
> 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.
Yep.
>> 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.
Note: that sentence was adapted from getrrsetbyname(3), stripping the
example list precisely because I didn't want to be specific. The devil
is in the details. I'm not even sure loopback communication be
considered secure.
> trust-ad is a button
> mere mortals cannot push.
Do mere mortals care about or rely on DNSSEC? ;)
> 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.
Well one of the reasons I'm proposing a knob is that I doubt we can find
a one-size-fits-all solution.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
