Comment 7 for bug 1641328

Hi Mark!

Thank you for pointing me to this bug. I spent some time looking into this.

It seems that there is currently no established mechanism for ordering NSS modules into nsswitch.conf automatically. Instead every package is doing its own parsing mangling of the file on install. libnss-resolve is appending "[!UNAVAIL=return]" which causes the mdns4_minimal entry to get shadowed, depending on installation order of the packages involved (libnss-mdns and libnss-resolve).

A workaround was implemented in Debian in https://anonscm.debian.org/cgit/collab-maint/nss-mdns.git/commit/?id=44550bcc6b49116f927dea52395867ff47d7d3b9 (tests in https://anonscm.debian.org/cgit/collab-maint/nss-mdns.git/commit/?id=0e9b82b91cd9bf9464cf63df2c3f1cbbec3553e0) which appears in Zesty (17.04) which will explain why Zesty appears to work correctly. Though this is still a hack, I think it should work in both ordering cases, so in the short term this should be fixed from a user's perspective.

In the long term, Debian have a bug open (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846944) to fix the hack. It may be that mDNS resolution moves to libnss-resolve, or that some kind of configuration wrapper is arranged to improve on the ad-hoc mangling of nsswitch.conf.

So, for Ubuntu:

This is fixed in Zesty onwards.

The workaround for Yakkety (as you explained) is to edit /etc/nsswitch.conf and bring "mdns4_minimal [NOTFOUND=return]" in front of "resolve [!UNAVAIL=return]".

We could propose an update for Yakkety (16.10). But we have to do it carefully - if there is a bug in the update, we could break DNS resolution for all users. However, Debian have already written the essential "swap it round" code so that will already have had some real world testing. But Yakkety has only two months left before it EOLs, and the workaround for affected users is fairly trivial. So is it worth trying? Opinions welcome.

For bug triage, there are effectively two bugs. 1) The fact that it doesn't work for users in Yakkety; and 2) the bigger picture fix for the hack or move of mDNS resolution to libnss-resolve. I see this bug as having been reported for the first issue, and the Debian bug as tracking the second. So I'll mark the systemd task as Invalid, as the fix for this bug was in libnss-mdns (and we can track any SRU for libnss-mdns here). I'm not linking the Debian bug, as that's the separate second issue. If we want to track that in Launchpad, we should file a separate bug for it, so as not to mix up the separate statuses of the two issues.