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 autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 4896 invoked from network); 28 Apr 2020 03:09:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 28 Apr 2020 03:09:38 -0000 Received: (qmail 13451 invoked by uid 550); 28 Apr 2020 03:09:33 -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 13415 invoked from network); 28 Apr 2020 03:09:32 -0000 Date: Mon, 27 Apr 2020 23:09:19 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200428030919.GR11469@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] AD bit in outgoing DNS queries In order to obtain information on whether the result is in a DNSSEC signed zone, which is needed for some applications including RFC-conforming use of DANE records, the AD bit must be set in the outgoing DNS query, indicating support by the client. musl's resolver library does not presently set the AD bit, and historically (~5+ years ago) at least there were compatibility problems with broken nameservers/firewalls/etc. failing to reply or dropping packets if it was set. I'd really really like to just set it unconditionally, since it's the modern, resonable, Right Thing to do, and since making it configurable/stateful is nasty -- depending on how you do it, it turns into either a: - layer violation, if config affects res_mkquery rather than just res_query, or a - least-surprise violation, if config only affects res_send and causes it to rewrite the header bits of the query at send-time. We already don't support incredibly-broken nameservers like the notorious ones on some home router appliances that drop concurrent A and AAAA requests. But I don't want this to turn into some kinda big regression if there are actually still broken setups in the wild. Can anyone dig up information on whether this is non-issue like I hope it is? So far I haven't turned up much reliable/recent information either way. Rich