From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id CE80125470 for ; Wed, 6 Mar 2024 17:15:40 +0100 (CET) Received: (qmail 17946 invoked by uid 550); 6 Mar 2024 16:11:43 -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 17908 invoked from network); 6 Mar 2024 16:11:42 -0000 Date: Wed, 6 Mar 2024 11:15:44 -0500 From: Rich Felker To: David Schinazi Cc: musl@lists.openwall.com Message-ID: <20240306161544.GH4163@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] mDNS in musl On Tue, Mar 05, 2024 at 11:29:03PM -0800, David Schinazi wrote: > Hi everyone, > > I was debugging a network connectivity issue on Alpine and have tracked it > down to lack of support for mDNS in musl gethostbyname / getaddrinfo [1]. I > looked through the musl codebase to understand why, and it would be pretty > straightforward to fix. I'd be interested in writing a patch for this, so I > was wondering: would you be at all interested in potentially taking such a > patch? > > Some more info on mDNS: all names that end in ".local" are reserved for use > by mDNS, and instead of sending them to the DNS resolver, they're sent > locally over multicast - and the machine with that name replies with its IP > address. It's used today to discover printers and pretty much everything in > home networks. Last I checked, .local is not actually reserved by any relevant specification/authority. It was basically just appropriated by mDNS. The protocol spoken is also not exactly DNS (for example, it uses raw UTF-8 rather than IDN/punycode, which would need to be special-cased once we support the latter). There's also very much a policy matter of what "locally over multicast" means (what the user wants it to mean). Which interfaces should be queried? Wired and wireless ethernet? VPN links or other sorts of tunnels? Just one local interface (which one to prioritize) or all of them? Only if the network is "trusted"? Etc. My view has always been that the right way to do something like this, where there's no existing interface or contract/expectations for how the libc stub resolver does it, is that it belongs in a resolver speaking dns protocol on localhost. That way policy isn't baked-in to individual executables (which may be static linked) but kept in a place that's reasonable to have policy controls and where the user can customize them. > From looking through musl, both gethostbyname() and getaddrinfo() route > through __lookup_name(), which eventually calls name_from_dns(). From > looking at that function, the issue is that it doesn't treat .local > specifically - instead of sending those queries to multicast, it sends them > to the regularly configured DNS nameservers. > > The fix would be to modify name_from_dns() [2] such that if `name` ends in > ".local", then pass in a different conf variable to __res_msend_rc(). The > conf variable contains (amongst other things) the DNS nameservers to send > the query to. So, when the name ends in .local, instead of passing in the > regular nameservers, we pass the multicast addresses and ports dedicated to > mDNS (224.0.0.251:5353 and [ff02::fb]:5353). When you do that, how do you control which interface(s) it goes over? I think that's an important missing ingredient. > And that's it! This implementation is compatible with the "One-Shot > Multicast DNS Queries" mode of the mDNS RFC [3]. (Other versions of libc > have a mode to send the query over dbus to avahi so that it can cache mDNS > results locally. But that's the more complicated "Continuous Multicast DNS > Querying" mode of the RFC, and we don't need that here.) > > So what do you think, would you be interested in support for mDNS? (In case > it matters, I've made changes in getaddrinfo inside Apple's libc, so I'm > comfortable in this kind of code even though I have zero prior experience > with musl) If at some point there's a consensus on stub resolvers having an expectation to support this themselves, and on untanging the details like the above, and on "ownership" of the ".local" TLD, it might make sense to have a resolv.conf option to do this. Unlike general unioning of sources, which is really problematic, the mDNS stuff seems to be putting the decision which source to use *before* making any queries, which is a lot less problematic. Rich