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 3640424F87 for ; Fri, 8 Mar 2024 05:47:45 +0100 (CET) Received: (qmail 16352 invoked by uid 550); 8 Mar 2024 04:43: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 16319 invoked from network); 8 Mar 2024 04:43:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709873252; x=1710478052; 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=aGmNdhKHIT0kzW1zs1ML7RhxSt5Ajjky0wz/OWb1ArI=; b=WQdVtHi0VufWH4BYB138BVgpHlOu0Qpdar1fN9YUVogdK0PbFp9yCA5A3LKNQHX/Ie Ta6otQ4lvWwjQ9Yzxe7AS49apGwkRhJ/eTPwZDZz2H9RHDJlesvMonIq5VrP7cQ1ttXM W1Mgo1T1j9Xe6pcYInFq2RjF+o/kzdTsgLn9LyzrVzCSh3NN0OeMtPQohrykyH329hzn UFfMjJgKSX6jmMDTCn9OVtKYeH4yTlEhqL0qRr/eh7kxRSozzHHIRK0ZLsncezByHM4x 2wQaDf6XtD9OATa4IacBzYgPYvSfNvDnWPoM73NevInfzKx/1T1sUnhaM/H9kP+2Q6uH pCCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709873252; x=1710478052; 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=aGmNdhKHIT0kzW1zs1ML7RhxSt5Ajjky0wz/OWb1ArI=; b=xEULOzMrhP6ng2ihXKAB9chkUS5Z/yDUbZ9wCCq2RBRhfA7c9yZ4aj61VvsxduV7yq B1j8dLmfcY3G22vQfGmfgVpNa6RQZfJfSe8tk1jE3HuL0Mg+Z7F6ZdiNl3x7Tnn8LZsP efapMTdp93mHiaSM0nqs1ehOSU4b6JIEuUdVHtSX8/xtRu1YYu4Qbg24rgC9yFl0gqpq iVhc5cd5lwk/ViGSSE517PjmwGEoRWmLWzI/obEQXmgNNyP9NYOjl4T3Kl9e8K7GEC70 pNDAyLr1R36qsK2dsN5puG7+vfR5YLklfDSfUeOTOTa/6wioX8Hcj0JospZuTjpEdQRN PXHw== X-Gm-Message-State: AOJu0Yyeps1lvZG8L8IyajVYtfjT3wIc5HFsmiDdARp5zUFIlyOJ5f2a 7RKsgpXnROgffZ2UnSXFTYIt3oTi8X65N364fU4mRIt3AMCtWiqPETA9pEJpqKrjnRpmO/N4cXw 0M3fw/wHDSMh7DQsyIriLdwPVu5KWiItx X-Google-Smtp-Source: AGHT+IHffmfFup8fkXbw18B7OKl6lhIM+4wgzbBVxZK0jdrFRiFnkuDLGRcXbI7UCPq9STbR4HQg56elWW7E82bOEXQ= X-Received: by 2002:a17:906:aac2:b0:a3e:9def:5c8d with SMTP id kt2-20020a170906aac200b00a3e9def5c8dmr13154098ejb.28.1709873252322; Thu, 07 Mar 2024 20:47:32 -0800 (PST) MIME-Version: 1.0 References: <20240306161544.GH4163@brightrain.aerifal.cx> <20240307024316.GI4163@brightrain.aerifal.cx> <20240308000818.GJ4163@brightrain.aerifal.cx> <20240308025204.GK4163@brightrain.aerifal.cx> <20240308034740.GL4163@brightrain.aerifal.cx> In-Reply-To: <20240308034740.GL4163@brightrain.aerifal.cx> From: David Schinazi Date: Thu, 7 Mar 2024 20:47:20 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000d0d5d206131ee3c1" Subject: Re: [musl] mDNS in musl --000000000000d0d5d206131ee3c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. How would you feel about the following potential configuration design? * Add a new configuration option "send_mdns_unicast" * When true, use the current behavior * When false, send the query on all non-loopback non-p2p interfaces * Have send_mdns_unicast default to false I was thinking through how to pick interfaces, looked up what other mDNS libraries do, and pretty much all of them don't allow configuring interfaces, whereas Avahi exposes allow-interfaces and deny-interfaces. I'm leaning towards not making this configurable to reduce complexity. I think that anyone interested in that level of config is probably using Avahi anyway. Additionally this design has two nice properties: the default behavior is RFC-compliant, and it means that for my use-case I don't need to change the config file, which was a big part of my motivation for doing this inside of musl in the first place :-) David On Thu, Mar 7, 2024 at 7:47=E2=80=AFPM Rich Felker wrote: > On Thu, Mar 07, 2024 at 07:34:33PM -0800, David Schinazi wrote: > > Hmmm. The cleaner option with the new config option and support for > > querying on all interfaces probably reaches a level of complexity where > > running a resolver on localhost might be best. And I honestly agree wit= h > > your point that overloading the config option isn't great design. So > > perhaps "not doing it at all" is the answer then. I'll think about it > some > > more, and discuss it with some mDNS experts at the next IETF meeting in= a > > couple weeks. I'll report back if someone has a clever idea that wouldn= 't > > violate the design principles we've discussed in this thread. But if > not, I > > want to say thanks for thinking through this with me. > > I don't think the conclusion of this thread is necessarily "don't". > The right form of config option, especially if there's consensus on > what it should look like, is a very viable path, and the IP_PKTINFO > thing you found makes the implementation a lot simpler. > > Having input from experts on the mDNS side would be most welcome and > sounds like a good next step to figuring out if this makes sense. > > Rich > --000000000000d0d5d206131ee3c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. How would you feel about the following potential c= onfiguration design?
* Add a new configuration option "send_mdns_u= nicast"
* When true, use the current behavior
* Wh= en false, send the query on all non-loopback non-p2p interfaces
*= Have send_mdns_unicast=C2=A0default to false

I wa= s thinking through how to pick interfaces, looked up what other mDNS librar= ies do, and pretty much all of them don't allow configuring interfaces,= whereas Avahi exposes=C2=A0allow-interfaces and deny-interfaces. I'm l= eaning towards not making this configurable to reduce complexity. I think t= hat anyone interested in that level of config is probably using Avahi anywa= y.

Additionally this design has two nice propertie= s: the default behavior is RFC-compliant, and it means that for my use-case= I don't need to change the config file, which was a big part of my mot= ivation for doing this inside of musl in the first place :-)

=
David

On Thu, Mar 7, 2024 at 7:47=E2=80=AFPM Rich Felker &l= t;dalias@libc.org> wrote:
On Thu, Mar 07, 2024 at= 07:34:33PM -0800, David Schinazi wrote:
> Hmmm. The cleaner option with the new config option and support for > querying on all interfaces probably reaches a level of complexity wher= e
> running a resolver on localhost might be best. And I honestly agree wi= th
> your point that overloading the config option isn't great design. = So
> perhaps "not doing it at all" is the answer then. I'll t= hink about it some
> more, and discuss it with some mDNS experts at the next IETF meeting i= n a
> couple weeks. I'll report back if someone has a clever idea that w= ouldn't
> violate the design principles we've discussed in this thread. But = if not, I
> want to say thanks for thinking through this with me.

I don't think the conclusion of this thread is necessarily "don= 9;t".
The right form of config option, especially if there's consensus on
what it should look like, is a very viable path, and the IP_PKTINFO
thing you found makes the implementation a lot simpler.

Having input from experts on the mDNS side would be most welcome and
sounds like a good next step to figuring out if this makes sense.

Rich
--000000000000d0d5d206131ee3c1--