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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 98DBC28C45 for ; Thu, 7 Mar 2024 23:51:19 +0100 (CET) Received: (qmail 5947 invoked by uid 550); 7 Mar 2024 22:47:18 -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 5905 invoked from network); 7 Mar 2024 22:47:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709851866; x=1710456666; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oPlHkERcHH2qu3PhNFRHKHzgUWx3Q03EwueCzJsg1fs=; b=lea/Z6bma/9LTmEQ/N0mQ0emIBkUSv3p0ywTvHtQA0dAbc6zHhYSTOMo5bDOWw/No7 wZR5UZHL16zSxdr46tqhVt8PeoS6vZz4b056aX46KytIvj4PAI7aD4jkrBfpExhHLQQk QqIXpkF9L4gjBwU9BZd4qgPJE4fCxHfmeiYqf/gtymkpc+r/SVO4n0877Dgfl1RLQUl8 1bxpM51wHkgOjTdPB8hLSByd0ge5OdatPr0XrQwfK4Erwj+MZdjlcb9YQdz6fbpDXNpR ALRG4FgAwhnO3/R6Gkv/rL2Nitu8khJNEOtLhkXVVvE2kYMbtRnOenBdX6TCfM3KQI/I CYHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709851866; x=1710456666; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oPlHkERcHH2qu3PhNFRHKHzgUWx3Q03EwueCzJsg1fs=; b=cOEFqHbJDLjlwaCWJv4ip8uxAVugPpZpcRalaiB462wfkKa8m9sYIgvh0a5ErEACGm 5zwAgqkshTLcUpkn3HeJ0R4N9C4XsdUAim7WcAwnlJZ7anPcPxpmJOEPTQctQcUndhEE qbYQi032XQCigvF93/zBPWN4fukCpiHBMpra301z2rJoYmo/LKupTpHBBxVVxaaG1H96 X3kKdwrwXuM8jhIzQY1dwwciskjv63sUsyu4kDwOUMVz557lCMyLyaVY06R3du7unKcH p+TE8e8b7u9YjbIGkm3gTOMTAoA+F4amO6K4rbDlYH8iFskP+OP8alIAxrJLZ2pLfOQx KRNw== X-Gm-Message-State: AOJu0YxkQmmDyXKS4KOvbeogKejj4k1/ltdd7Ta/f0FFZc+26VVzZlfk bqNTKjSId+3/a783P6N15RceITCdHVtFpodj8h4kYOMyWVkyhzmREWoOErFnxKg3Vik2rWNylFo EhH4fH2wig//pyaq/UIWhZSuO+kK9vb3M8Yc= X-Google-Smtp-Source: AGHT+IEsc6Xcknf4pnePyLI7zkR9C4y8CFd+STVZTm6w7vRkbQp08x1iS3z3jGGm619MN+NPHuPIOww1PE8+K0bmgAI= X-Received: by 2002:a25:bc12:0:b0:dc7:4806:4fb with SMTP id i18-20020a25bc12000000b00dc7480604fbmr17274873ybh.8.1709851865740; Thu, 07 Mar 2024 14:51:05 -0800 (PST) MIME-Version: 1.0 References: <20240306161544.GH4163@brightrain.aerifal.cx> <20240307024316.GI4163@brightrain.aerifal.cx> In-Reply-To: <20240307024316.GI4163@brightrain.aerifal.cx> From: David Schinazi Date: Thu, 7 Mar 2024 14:50:53 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000013825b061319e9a2" Subject: Re: [musl] mDNS in musl --00000000000013825b061319e9a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 6:42=E2=80=AFPM Rich Felker wrote: > 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 custo= m > > purposes, and ".local" was one of the initial entries into that registr= y. > > The UTF-8 vs punycode issue when it comes to mDNS and DNS is somewhat o= f > 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. > Totally agree. I was thinking through this both in terms of RFCs and in terms of minimal code changes, and had a potential idea. Conceptually, sending DNS to localhost is musl's IPC mechanism to a more feature-rich resolver running in user-space. So when that's happening, we don't want to mess with it because that could cause a privacy leak. Conversely, when there's a non-loopback IP configured in resolv.conf, then musl acts as a DNS stub resolver and the server in resolv.conf acts as a DNS recursive resolver. In that scenario, sending the .local query over DNS to that other host violates the RFCs. This allows us to treat the configured resolver address as an implicit configuration mechanism that allows us to selectively enable this without impacting anyone doing their own DNS locally. > > 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, Yeah we'd need lookup_name.c to include netlink.h - it's not huge though, netlink.c is 50 lines long and statically linked anyway right? > and > it's not clear how to do it properly for IPv4 (do scope ids work with > v4-mapped addresses by any chance?) > Scope IDs unfortunately don't work for IPv4. There's the SO_BINDTODEVICE socket option, but that requires elevated privileges. For IPv4 I'd just use the default route interface. Another issue you haven't mentioned: how does TCP fallback work with > mDNS? Or are answers too large for standard UDP replies just illegal? > Good point, I hadn't thought of that. That handling for mDNS is defined in [1]. In the ephemeral query mode that we'd use here, it works the same as for regular DNS: when you receive a response with the TC bit, retry the query with TCP. The slight difference is that you send the TCP to the address you got the response from (not to the multicast address that you sent the original query to). From looking at the musl code, we'd need a small tweak to __res_msend_rc() to use that address. Luckily that code already looks at the sender address so we don't need any additional calls to get it. [1] https://www.rfc-editor.org/rfc/rfc6762#section-18.5 > > 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). > Ah right. Yeah for mDNS the split is clean, that's part of why they reserved .local for this. > > 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 itse= lf > > 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. > Great! > > 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 wi= ll > > > 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 differe= nt > > 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 ow= n > > beast then I can see how including it wouldn't really make sense. But i= f > > 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. > Those are great reasons, and I totally agree with those goals. If we scope the problem down with the details higher up in this email, we have a way to turn this off (set the resolver to localhost), we avoid privacy leaks in cases where the traffic wasn't going out in the first place, we don't have to add more configuration knobs because we're reusing an existing one, and the amount of added code would be quite small. Limiting things to the default interface isn't a full multi-network solution, but for those I think it makes more sense to recommend running your own resolver on loopback (you'd need elevated privileges to make this work fully anyway). Coding wise, I think this would be pretty robust. The only breakage I foresee is cases where someone built a custom resolver that runs on a different machine and somehow handles .local differently than what the RFCs say. That config sounds like a bad idea, and a violation of the RFCs, but that doesn't mean there isn't someone somewhere who's doing it. So there's a non-zero risk there. But to me that's manageable risk. What do you think? Thanks, David --00000000000013825b061319e9a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2024 at 6:42=E2=80=AFP= M Rich Felker <dalias@libc.org>= ; wrote:
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 Reg= istry
> (RFC 6761) which created a process for reserving domain names for cust= om
> purposes, and ".local" was one of the initial entries into t= hat 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 perf= orm
> punycode conversion for .local instead of sending the UTF-8. So in pra= ctice
> 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<= br> > > multicast" means (what the user wants it to mean). Which int= erfaces
> > should be queried? Wired and wireless ethernet? VPN links or othe= r
> > sorts of tunnels? Just one local interface (which one to prioriti= ze)
> > or all of them? Only if the network is "trusted"? Etc.<= br> > >
>
> You're absolutely right. Most mDNS systems try all non-loopback no= n-p2p
> multicast-supporting interfaces, but sending to the default route inte= rface
> 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<= br> a privacy leak.

Totally agree. I was th= inking through this both in terms of RFCs and in terms of minimal code chan= ges, and had a potential idea. Conceptually, sending DNS to localhost is mu= sl's IPC mechanism to a more feature-rich resolver running in user-spac= e. So when that's happening, we don't want to mess with it because = that could cause a privacy leak. Conversely, when there's a non-loopbac= k IP configured in resolv.conf, then musl acts as a DNS stub resolver and t= he server in resolv.conf acts as a DNS recursive resolver. In that scenario= , sending the .local query over DNS to that other host violates the RFCs. T= his allows us to treat the configured resolver address as an implicit confi= guration mechanism that allows=C2=A0us to selectively enable this without i= mpacting anyone doing their own DNS locally.

> > When you do that, how do you control which interface(s) it goes o= ver?
> > I think that's an important missing ingredient.
>
> You're absolutely right. In IPv4, sending to a link-local multicas= t 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 p= ull 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,

Yeah we'd need lookup_name.c to include netlink.h = - it's not huge though, netlink.c is 50 lines long and statically linke= d anyway right?
=C2=A0
and
it's not clear how to do it properly for IPv4 (do scope ids work with v4-mapped addresses by any chance?)

Sco= pe IDs unfortunately don't work for IPv4. There's the=C2=A0SO_BINDT= ODEVICE socket option, but that requires elevated privileges. For IPv4 I= 9;d just use the default route interface.

Another issue you haven't mentioned: how does TCP fallback work with mDNS? Or are answers too large for standard UDP replies just illegal?

Good point, I hadn't thought of that. Th= at handling for mDNS is defined in [1]. In the ephemeral query mode that we= 'd use here, it works the same as for regular DNS: when you receive a r= esponse with the TC bit, retry the query with TCP. The slight difference is= that you send the TCP to the address you got the response from (not to the= multicast address that you sent the original query to). From looking at th= e musl code, we'd need a small tweak to __res_msend_rc() to use that ad= dress. Luckily that code already looks at the sender address so we don'= t need any additional calls to get it.


> > 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 quer= ies,
> > which is a lot less problematic.
>
> I'm not familiar with what you mean by unioning here, are you refe= rring 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).
<= div>
Ah right. Yeah for mDNS the split is clean, that's p= art of why they reserved .local for this.

> > So is there something wrong with the solution presented in the wi= ki
> > page? Because that is generally the answer we recommend: If you w= ant 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 data= base
> > 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 ad= ditional
> processes that can be failure points, when the stub can send these its= elf
> 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.

Great!
<= br>
> > Reason for that is that that is the most generic way to support a= ny
> > other name service besides DNS. It avoids the dependency on dynam= ic
> > loading that something like glibc's nsswitch would create, an= d would
> > avoid having multiple backends in libc. I really don't think = anyone
> > wants to open that particular door. Once mDNS is in there, someon= e will
> > add NetBIOS, just you wait.
>
>
> I'm definitely supportive of the slippery slope argument, but I th= ink
> there's still a real line between mDNS and NetBIOS. mDNS uses a di= fferent
> transport but lives inside the DNS namespace, whereas NetBIOS is reall= y 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 o= wn
> 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 smal= l
> 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.

Those are great reasons, and I totally agree with t= hose goals. If we scope the problem down with the details higher up in this= email, we have a way to turn this off (set the resolver to localhost), we = avoid privacy leaks in cases where the traffic wasn't going out in the = first place, we don't have to add more configuration knobs because we&#= 39;re reusing an existing one, and the amount of added code would be quite = small. Limiting things to the default interface isn't a full multi-netw= ork solution, but for those I think it makes more sense to recommend runnin= g your own resolver on loopback (you'd need elevated privileges to make= this work fully anyway). Coding wise, I think this would be pretty robust.= The only breakage I foresee is cases where someone built a custom resolver= that runs on a different machine and somehow handles .local differently th= an what the RFCs say. That config sounds like a bad idea, and a violation o= f the RFCs, but that doesn't mean there isn't someone somewhere who= 's doing it. So there's a non-zero risk there. But to me that's= manageable risk.

What do you think?
Thanks,
David
--00000000000013825b061319e9a2--