On 7/10/23 19:40, Tomasz Torcz wrote:
I guess it can be disabled. It never gained any popularity.
Unfortunately we have only opinions, not numbers to back this argument.
I share that view however. Since Windows 10, every windows should
respond to mDNS also. Apple systems respond only to mDNS.
> I think mDNS has less
> problematic implementation in avahi, but that has to be enabled explicitly.
> I think that is desired especially on servers.
Actually, the coexistence of Avahi and system-resolved is an
interesting topic, underdocumented in my opinion. It would be nice
(but disabling LLMNR should not depend on) to have some FAQ on that.
- both avahi and resolved seem to have resolving capacity for mDNS
Current ability
of released systemd-resolved is to resolve hosts only
AFAIK. Maybe SRV entries too?
- only avahi can announce mDNS services (is this correct?)
Yes,
I think so. Probably until PR #22532 is merged.
- how do apps needing mDNS resolver work? Like CUPS. Do those apps
talk
to avahi? To resolved? Are they using nss to resolve mDNS?
They are using
nss-mdns plugin, which in turn uses avahi-daemon, when
used from getaddrinfo() call, if they want just addresses. If they want
list of services, avahi libraries are used by client applications like
CUPS. Via DBus calls it obtains current cached entries from the
avahi-daemon cache.
Of course nss-resolve plugin could do similar thing for addresses. But I
am not sure how it should work for applications linking to avahi-libs.
- how to those apps register resources (like printers) to announce?
With
avahi? With resolved?
Applications have to use some API to request service
announced, unless
it is statically defined in avahi configuration.
- should avahi be disabled when using resolved with
MulticastDNS=true
(or =resolve)?
I read on some Microsoft article that multiple mdns stacks are
common on
single host. I guess it might be true also for Google Chrome browser.
There is continuous querying PR #22532 [1] in progress, which may add
abilities to do also service browsing. Not sure how is handling by
clients expected to work and how (in)compatible they would be.
It adds mdns-browse-services command, similar to avahi-browse command I
assume.
- what exactly MulticastDNS=true mean?
It means
systemd-resolved will send queries for .local domain (resolver
part) and also answer to queries received from the network (responder
part). Of course firewall might restrict it.
- which app should bind to port 5353/UDP
I am not sure whether
multiple stacks listening on mdns port can work. I
think only one should listen. I would prefer Avahi, as it already has
known behaviour and widely used bindings.
- etc.
1.
https://github.com/systemd/systemd/pull/22532
--
Petr Menšík
Software Engineer, RHEL
Red Hat,
https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB