[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 May 2020 12:51:10 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: musl@...ts.openwall.com
Subject: Re: TCP support in the stub resolver
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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
