[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240306161544.GH4163@brightrain.aerifal.cx>
Date: Wed, 6 Mar 2024 11:15:44 -0500
From: Rich Felker <dalias@...c.org>
To: David Schinazi <dschinazi.ietf@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
