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 30081 invoked from network); 3 May 2020 17:20:09 -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 17:20:09 -0000 Received: (qmail 10019 invoked by uid 550); 3 May 2020 17:20:07 -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 10001 invoked from network); 3 May 2020 17:20:06 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com 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> <20200503165110.GW21576@brightrain.aerifal.cx> Date: Sun, 03 May 2020 19:19:54 +0200 In-Reply-To: <20200503165110.GW21576@brightrain.aerifal.cx> (Rich Felker's message of "Sun, 3 May 2020 12:51:10 -0400") Message-ID: <87a72pkkat.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] TCP support in the stub resolver * Rich Felker: > 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? The answer to a EDNS0 query does not contain any DNSSEC data even if the DO bit is set. The data in the additional section of such responses seems to be corrupted (dig reports parse errors). The CD flag in the query is apparently ignored. (I still need to investigate the details, sorry.)