under systemd avahi-daemon doesn't stay disabled when .local is detected

[Sami Haahtinen]

When avahi daemon detects .local unicast domain, the daemon is disabled. When a user tries to resolve a domain name through nss, the daemon starts up.

The root cause is most likely in systemd that starts the daemon when an application tries to access the socket through the systemd managed socket file.

This behavior wasn't observed in 14.10 or earlier releases, thus the assumption towards systemd socket activation.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: avahi-daemon 0.6.31-4ubuntu4
ProcVersionSignature: Ubuntu 3.19.0-10.10-generic 3.19.2
Uname: Linux 3.19.0-10-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.17-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 7 09:51:43 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-11-16 (506 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: avahi
UpgradeStatus: Upgraded to vivid on 2015-03-18 (19 days ago)

[Sami Haahtinen (ressu)]

This bug affects the final release of 15.04 and is a regression in regards to 14.10 behavior.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Pitt (pitti)]

Indeed, this should be fixed in /usr/lib/avahi/avahi-daemon-check-dns.sh . When running under systemd ([ -d /run/systemd/system ]) then the .socket needs to be stopped too, not just the .service.

[Trent Lloyd (lathiat)]

I was re-visiting this recently, I'm fairly sure we can get rid of this requirement to stop avahi with a .local by reconfiguring nsswitch.conf to remove the [NOTFOUND=RETURN].

Do you know where the initial discussion determining why to do this was had?

My general understanding is that because of the [NOTFOUND=RETURN] in nsswitch.conf, if avahi is started then .local domains wont resolve as mdns returns NOTFOUND for any .local then causing the lookup to short circuit and return failed.

If we remove this flag, it should fall through to DNS and work as expected, though possibly with an increased timeout.

Generally mDNS only has single depth hostnames that you lookup via regular dns, e.g. host1.local -- sub.host1.local is generally not allowed by the spec for normal hostnames. In contrast, most .local domains are active directory/windows or other domains where they usually have 3 levels, e.g. host.network.local -- if the timeout is an issue we could very likely fall through on multi label hosts if it's not in the cache.

[Sami Haahtinen (ressu)]

The 3rd level is a good indicator that we really want a proper DNS name. I did investigate this very briefly back when this problem first occurred.

I also think that the nsswitch alteration is a good solution in the short term. The issue on the long term is that people with .local domain will see a decrease in performance in name resolution. I'm not sure how the nss module works internally, as in how fast it returns after an invalid request, so I don't know what the actual effect is.

[Martin Pitt (pitti)]

@Trent: I really don't have any context from the original rationale left. So in the absence of better data, we should indeed follow Debian -- if there are no major bug reports about that, this can't be completely broken. Does Debian do the [NOTFOUND=RETURN] thing? I suppose not?

Please do grab the bug if you have some time to investigate/handle this, I'm afraid I'm swamped. Thanks!

[Martin Pitt (pitti)]

Sorry, I keep having no time for this, please grab.