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

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

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

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.

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.

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.

@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!

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