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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 8051 invoked from network); 2 May 2020 22:52:53 -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; 2 May 2020 22:52:53 -0000 Received: (qmail 15456 invoked by uid 550); 2 May 2020 22:52:46 -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 15438 invoked from network); 2 May 2020 22:52:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5lYLOBGUPDKS5YRJbTFSbok0EV0wzXVXng98yYj7wjs=; b=FPeeKyvR8Gmz7IJLL6xEgCOm0yv8bW648TAOdhUNHAeInISozErLsQOpCwWDTmMIZd umim691mSblJOKER2WHjC7DaE9npaqVEQ7tJceTZ5ZCNNopgs6DZag4coP9R1ZLPcGVK wKub1AXfi/FZLAI6Q/aqHLL8tjVXF9q2nUlQw+EWOdvPrs+IEcu8zViqFqZh/M3keLJe 8Ic8R9zjNfmQGr/nA7o0djWCKMeWc6U2N4P04pDy7XYTUQuNO0/JXNfDBhrCWHSfIV0H YYcYR4VEXpCy7pB0JVMaRHUumukpSh1MNtcvb4NS8Te/xMj5M3tWgVuSj/4O2doKr3kd +HUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5lYLOBGUPDKS5YRJbTFSbok0EV0wzXVXng98yYj7wjs=; b=cDLDVmsc37+Mz3OeE2jByfo+SvR12+miomo2dYL7rtquWUTLh7CPolDUMmCriQNi2i hdkg9kTetDYUelLcpAk7I0vm7wTsaEu9rXYiUVDQOTdrvzO6X+iLD8KTBN3zOCZHlM5J k6cSmLugteZXnQncAfycsulpuk6CCXrChJle83vusxuUZb0dtwoyqbWK+9QXmiaz+vX7 73uRGzmebPA2jiwW39+X9HNs+1peCbSoPW0W+gFlKltg8wjRCpWc0COwEkPIog0Xaxs6 d/rgQyWiNYFoZHPGQm8GKq6zhyM6Kw7uXNdM+/4Xff30BWMJgO/4G+t3ZV7kxXqfc2oQ iN2g== X-Gm-Message-State: AGi0Pub+FJ9EDIXc5fBcd4lzpzwJPI9Zs1P1qEUywMHATJG8NXFyXlCO yHrIGEwsEEZRQdb3VCZhl1c4WtoHqArUw1PMwktf9Xwt X-Google-Smtp-Source: APiQypJKvrH41zKrgDafjS9VqgZh9s/eMl294I2zn2zGLcuF2XXO6IsDxX0muKxJ2LNpcG1q1Kg4J8U9FbtJ8uQcO/8= X-Received: by 2002:a05:620a:85d:: with SMTP id u29mr3296651qku.496.1588459953573; Sat, 02 May 2020 15:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20200419000347.GU11469@brightrain.aerifal.cx> <871roj51x3.fsf@mid.deneb.enyo.de> <20200420012441.GW11469@brightrain.aerifal.cx> <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> In-Reply-To: <20200502154429.GU21576@brightrain.aerifal.cx> From: Bartosz Brachaczek Date: Sun, 3 May 2020 00:52:22 +0200 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000045d46705a4b22719" Subject: Re: [musl] TCP support in the stub resolver --00000000000045d46705a4b22719 Content-Type: text/plain; charset="UTF-8" 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 --00000000000045d46705a4b22719 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, May 2, 2020 at 5:44 PM Rich Felke= r <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 cac= hing resolver by
> >> >> default.=C2=A0 It will help with a lot of these issu= es.
> >> >
> >> > That's great news! Will it be DNSSEC-enforcing by de= fault?
> >>
> >> No.=C2=A0 It is currently not even DNSSEC-aware, in the sense= that you
> >> can't get any DNSSEC data from it.=C2=A0 That's the s= ad part.
> >
> > That's really disappointing. Why? Both systemd-resolved and d= nsmasq,
> > the two reasonable (well, reasonable for distros using systemd al= ready
> > in the systemd-resolved case :) options for this, support DNSSEC = fully
> > as I understand it. Is it just being turned off by default becaus= e of
> > risk of breaking things, or is some other implementation that lac= ks
> > DNSSEC being used?
>
> It's systemd-resolved.=C2=A0 As far as I can tell, it does not pro= vide
> DNSSEC data on the DNS client interface.

According to this it does:

https://wiki.archlinux.org/index.php/Sys= temd-resolved#DNSSEC

However it's subject to downgrade attacks unless you edit a config
file. Note that the example shows:

=C2=A0 =C2=A0 ....
=C2=A0 =C2=A0 -- Data is authenticated: yes

so it looks like it's setting the AD bit like it should.

--00000000000045d46705a4b22719--