From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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.4 Received: (qmail 30746 invoked from network); 4 Nov 2023 15:41:47 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Nov 2023 15:41:47 -0000 Received: (qmail 23681 invoked by uid 550); 4 Nov 2023 15:41:44 -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 23648 invoked from network); 4 Nov 2023 15:41:43 -0000 Date: Sat, 4 Nov 2023 11:41:40 -0400 From: Rich Felker To: Ayush Agarwal Cc: musl@lists.openwall.com Message-ID: <20231104154139.GT4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] questions about musl DNS resolver On Sat, Nov 04, 2023 at 12:12:58PM +0530, Ayush Agarwal wrote: > Hi, > > I was reading about how DNS works in Linux distributions and I noticed > some differences in the way libc resolvers work in glibc and in musl. > I hope it's okay if I ask a few (potentially stupid) questions? > > 1. Why not offer a different man page on musl distributions for pages > like resolv.conf(5) and resolver(3) considering how their > implementation details and behavior are different from glibc? Is not > offering them intentional or does it require someone to step up and > write the documentation? Ideally the linux-man provided ones would document which things are glibcisms vs widely available elsewhere, but short of that, maybe it would be nice for someone to maintain musl-specific versions for distros to use. > 2. Which options in the resolv.conf(5) man page are supported by musl? > I know "search" and "nameserver" are supported but what about > "options" like "ndots", "edns0", "use-vc", "trust-ad"? search/domain, nameserver, and options: ndots, attempts, and timeout. trust-ad would be a no-op; it's always on. glibc's having it optional and off by default badly breaks anything trying to use dnssec/dane right. edns0 is not supported, intentionally because it would require munging and unmunging queries behind the caller's back (or treating libc-internal queries differently). use-vc is not supported because it doesn't really play well with our parallel query model or stateless design. > 3. It seems that version 1.2.1 added support for DNSSEC queries but > how do I confirm if DNSSEC queries are sent and received with musl? Do > I need to use the "option edns0 trust-ad" directive in resolv.conf for > it work? The usual suspects like drill and kdig seem to use their own > resolver. I'm not sure what you man by "DNSSEC queries". The normal application usage for DNSSEC that's supported by musl is for the stub resolver to make a normal query, with the AD bit set, to a trusted (ideally should run on localhost so trust is not crossing network boundaries) nameserver that will validate DNSSEC, ServFail on anything invalid/spoofed, and report via the AD bit of the answer packet whether the result is DNSSEC-protected. As of musl 1.2.1, the AD bit of the query is always set when you use the res_* API. All you have to do is interpret it in the answer. If you want to actually do DNSSEC validation yourself, or just see the RRSIG, etc. records, you need to construct a suitable query in EDNS0 form with the DO bit set. It can be sent (and the answer received) via the res_send function. Strictly speaking this does not depend on the musl version, but you'll need 1.2.4+ to get answers larger than 512 bytes (which these answers usually are). The resolv.conf edns0 option has nothing to do with this. It's about whether the stub resolver's construction of queries will make them in EDNS0 form, not whether res_send will accept EDNS0-form packets from the caller. > 4. The musl version 1.2.4 added TCP fallback to DNS. Is this fallback > intended to work automatically when the size of a DNS query is large > or does it need any configuration? Yes, it works automatically. Originally I intended to add capability to skip fallback if there's a non-empty answer list in the truncated packet, which might be an option at some point in the future, but right now it always happens, and by default it will continute to automatically happen. So, TL;DR: no configuration is needed for any of the stuff you want. It just all works, or at least is intended to. If you run into problems, please reach out here for help. Rich