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 PM Rich Felker <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 where
> > running a resolver on localhost might be best. And I honestly agree with
> > 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
>