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