Re: [musl] TCP support in the stub resolver

[Rich Felker <dalias@libc.org>]

On Sun, May 03, 2020 at 10:46:55AM +0200, Florian Weimer wrote:
> * Bartosz Brachaczek:
> 
> > On Sat, May 2, 2020 at 5:44 PM Rich Felker <dalias@libc.org> wrote:
> >
> >> On Sat, May 02, 2020 at 05:28:48PM +0200, Florian Weimer wrote:
> >> > * Rich Felker:
> >> >
> >> > > On Tue, Apr 21, 2020 at 07:26:08PM +0200, Florian Weimer wrote:
> >> > >> * Rich Felker:
> >> > >>
> >> > >> >> I'm excited that Fedora plans to add a local caching resolver by
> >> > >> >> default.  It will help with a lot of these issues.
> >> > >> >
> >> > >> > That's great news! Will it be DNSSEC-enforcing by default?
> >> > >>
> >> > >> No.  It is currently not even DNSSEC-aware, in the sense that you
> >> > >> can't get any DNSSEC data from it.  That's the sad part.
> >> > >
> >> > > That's really disappointing. Why? Both systemd-resolved and dnsmasq,
> >> > > the two reasonable (well, reasonable for distros using systemd already
> >> > > in the systemd-resolved case :) options for this, support DNSSEC fully
> >> > > as I understand it. Is it just being turned off by default because of
> >> > > risk of breaking things, or is some other implementation that lacks
> >> > > DNSSEC being used?
> >> >
> >> > It's systemd-resolved.  As far as I can tell, it does not provide
> >> > DNSSEC data on the DNS client interface.
> >>
> >> According to this it does:
> >>
> >> https://wiki.archlinux.org/index.php/Systemd-resolved#DNSSEC
> >>
> >> However it's subject to downgrade attacks unless you edit a config
> >> file. Note that the example shows:
> >>
> >>     ....
> >>     -- Data is authenticated: yes
> >>
> >> so it looks like it's setting the AD bit like it should.
> >>
> >
> > Relevant info:
> > https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC
> 
> This section talks about DNSSEC validation.  As far as I can tell,
> running systemd-resolved as the stub resolver prevents applications
> from accessing DNSSEC data and doing their own validation (or just
> looking add DNSSEC record types), independently of how
> systemd-resolved is built and configured.

Normally applications don't want to do their own DNSSEC validation,
just get back a valid AD flag indicating that the trusted nameserver
did it, and AIUI it works with systemd-resolved, but indeed with a
non-broken nameserver it should still be possible for the application
to do it. Are you saying that, if you request full DNSSEC data with
EDNS0 DO flag, systemd-resolved refuses to give it? Does dig
+trace/+dnssec fail to work with it?

Rich