From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 27016 invoked from network); 3 May 2020 16:51:27 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 May 2020 16:51:27 -0000 Received: (qmail 29974 invoked by uid 550); 3 May 2020 16:51:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29941 invoked from network); 3 May 2020 16:51:23 -0000 Date: Sun, 3 May 2020 12:51:10 -0400 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200503165110.GW21576@brightrain.aerifal.cx> References: <87a736y8nu.fsf@mid.deneb.enyo.de> <20200420173920.GD11469@brightrain.aerifal.cx> <87mu75uq3p.fsf@mid.deneb.enyo.de> <20200421150241.GL11469@brightrain.aerifal.cx> <87zhb4px73.fsf@mid.deneb.enyo.de> <20200501220238.GP21576@brightrain.aerifal.cx> <87wo5umk3z.fsf@mid.deneb.enyo.de> <20200502154429.GU21576@brightrain.aerifal.cx> <874ksxmmm8.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874ksxmmm8.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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