[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240307024316.GI4163@brightrain.aerifal.cx>
Date: Wed, 6 Mar 2024 21:43:16 -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 Wed, Mar 06, 2024 at 04:17:44PM -0800, David Schinazi wrote:
> As Jeffrey points out, when the IETF decided to standardize mDNS, they
> published it (RFC 6762) at the same time as the Special-Use Domain Registry
> (RFC 6761) which created a process for reserving domain names for custom
> purposes, and ".local" was one of the initial entries into that registry.
> The UTF-8 vs punycode issue when it comes to mDNS and DNS is somewhat of a
> mess. It was discussed in Section 16 of RFC 6762 but at the end of the day
> punycode won. Even Apple's implementation of getaddrinfo will perform
> punycode conversion for .local instead of sending the UTF-8. So in practice
> you wouldn't need to special-case anything here.
OK, these are both really good news!
> 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.
> >
>
> You're absolutely right. Most mDNS systems try all non-loopback non-p2p
> multicast-supporting interfaces, but sending to the default route interface
> would be a good start, more on that below.
This is really one thing that suggests a need for configurability
outside of what libc might be able to offer. With normal DNS lookups,
they're something you can block off and prevent from going to the
network at all by policy (and in fact they don't go past the loopback
by default, in the absence of a resolv.conf file). Adding mDNS that's
on-by-default and not configurable would make a vector for network
traffic being generated that's probably not expected and that could be
a privacy leak.
> > When you do that, how do you control which interface(s) it goes over?
> > I think that's an important missing ingredient.
>
> You're absolutely right. In IPv4, sending to a link-local multicast address
> like this will send it over the IPv4 default route interface. In IPv6, the
> interface needs to be specified in the scope_id. So we'd need to pull that
> out of the kernel with rtnetlink.
There's already code to enumerate interfaces, but it's a decent bit of
additional machinery to pull in as a dep for the stub resolver, and
it's not clear how to do it properly for IPv4 (do scope ids work with
v4-mapped addresses by any chance?)
Another issue you haven't mentioned: how does TCP fallback work with
mDNS? Or are answers too large for standard UDP replies just illegal?
> > 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.
>
> I'm not familiar with what you mean by unioning here, are you referring to
> interface selection, DNS name server selection, or something else?
By unioning I just mean providing a view of the hostname space that's
the union of two or more sources of information (nameservers that
aren't just redundant sources for the same DNS root).
> > So is there something wrong with the solution presented in the wiki
> > page? Because that is generally the answer we recommend: If you want any
> > name resolution other than DNS, write a proxy that does what you want
> > and point resolv.conf to it. Similarly, if you want any user database
> > lookup other than local files, write an nscd proxy that does what you
> > want.
>
> That's certainly an option. Ideally I'd rather avoid adding additional
> processes that can be failure points, when the stub can send these itself
> with a very small modification.
FWIW this is generally the approach musl takes. But if mDNS is
sufficiently standardized, intended to be supported in stub resolvers
by the standards, and doesn't have strong reasons not to do it, it
might be acceptable.
> > Reason for that is that that is the most generic way to support any
> > other name service besides DNS. It avoids the dependency on dynamic
> > loading that something like glibc's nsswitch would create, and would
> > avoid having multiple backends in libc. I really don't think anyone
> > wants to open that particular door. Once mDNS is in there, someone will
> > add NetBIOS, just you wait.
>
>
> I'm definitely supportive of the slippery slope argument, but I think
> there's still a real line between mDNS and NetBIOS. mDNS uses a different
> transport but lives inside the DNS namespace, whereas NetBIOS is really its
> own thing - NetBIOS names aren't valid DNS hostnames.
>
> Let me know what you think of the above. If you think of mDNS as its own
> beast then I can see how including it wouldn't really make sense. But if
> you see it as an actual part of the DNS, then it might be worth a small
> code change :-)
I'm not worried about slippery slopes to NetBIOS. :-P I am concerned
about unwanted network traffic that can't be suppressed, privacy
leaks, inventing new configuration knobs, potentially pulling in more
code & more fragility, getting stuck supporting something that turns
out to have hidden problems we haven't thought about, etc.
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.
