The Debian approach seems reasonable, assuming it can be made reliable enough for Chrome OS usecases.

See:

http://anonscm.debian.org/cgit/pkg-utopia/avahi.git/tree/debian/avahi-daemon.if-up
http://anonscm.debian.org/cgit/pkg-utopia/avahi.git/tree/debian/avahi-daemon-check-dns.sh

Probably we'd keep avahi quiesced until DNS probing can guarantee that no .local exists. Then send a dbus message to avahi to start it up. If network conditions change (or a periodic probe detects .local on unicast DNS), tell avahi to stop. 

See more caveats at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433945

Also, Apple describes how Mac OS responds in these situations:
https://support.apple.com/en-us/HT201275

We should ensure Avahi is working properly here (with upstream fixes if necessary).

The 2 conditions where Mac OS uses unicast resolution of .local:
1. Host names that contain two or more labels in addition to local (foo.bar.local)
2. Resolution of SOA record for the top level domain ".local"

I don't know if #1 is necessary, but #2 sounds good.

We should periodically probe for ".local" SOA from unicast and shut down avahi whenever it is detected.

An alternative is to patch nss-mdns to do the SOA resolution. That might be a better way.

I am trying to improve upstream to fix this issue. See https://github.com/lathiat/avahi/issues/64

No movement on the upstream side of things right now. Until that makes some progress, I will look into proposing patches for the version of nss-mdns in third_party.

Awesome, thanks! I think this qualifies as 'Started'. Feel free to unassign yourself if desired.

Working on the fix here:
https://github.com/lathiat/nss-mdns/issues/7

I have patches that are worth testing. I would like to get these integrated upstream, but that is moving slowly.

I'm not sure of the way to keep local Chrome OS patches for nss-mdns. Would it need to be imported into a third_party location?

I think first you need to move sys-auth/nss-mdns from third_party/portage-stable to third_party/chromiumos-overlay, then add your patches to a files/ directory and modify the ebuild to apply the patches. There are many other ebuilds w/ patches you can look at.

Adding vapier@ to correct me or provide more details

I think if the patches are actively moving upstream, we typically don't mind just leaving the ebuild in portage-stable (i.e., don't need to move it to chromiumos-overlay).

it depends on the upstream.  if it's in Gentoo, then doing it in portage-stable is fine.  if it's not, then copying to chromiumos-overlay is better.  especially if we're talking about version skew (upstream added it to their git repo, but doesn't make a release, and Gentoo continues to make new -r# fixes).

So upstream has moved to https://github.com/lathiat/nss-mdns (similarly to avahi). The new upstream maintainer granted me write permissions to the repository, then went silent. I was hoping he would review my code, but this has not happened.

Fortunately GitHub has now rolled out new review tools that makes it easier for anyone to do a review.

I'm looking for a volunteer or two to review my pull requests, which I will then push into upstream. This is the first one:
https://github.com/lathiat/nss-mdns/pull/1

To get to the review tool, make a comment or go to the "Files changed" tab and hit "Review changes".

Thanks to vapier for reviewing the last one.

Here are the next review requests:
https://github.com/lathiat/nss-mdns/pull/15
https://github.com/lathiat/nss-mdns/pull/14

Volunteers needed again. Thanks!

LGTMed them both. Not sure if there's a more official way than just commenting "LGTM"

Thanks adlr. LGTM works.

Finally, here is the main functionality change:
https://github.com/lathiat/nss-mdns/pull/16

I am going to take a little time and refactor a bit and add a few tests.

I closed pull request 16 and opened https://github.com/lathiat/nss-mdns/pull/18.

The tricky part was refactoring to allow for unit testing, but the rest was easy.

If anyone would like to do a review, I'd appreciate it.

I pushed the code to nss-mdns. I will coordinate with Gentoo upstream to get the code there. When that happens, I'll update this issue.

Here is what I plan to do before the new release:
https://github.com/lathiat/nss-mdns/milestone/1

I am not working on this right now. If anyone working on CUPS stuff would like to fix this, I am happy to help.

All the parts are in upstream nss-mdns git, but neither me nor the current maintainer has had time to make a release.

If Gentoo picks up the git patches (see https://github.com/lathiat/nss-mdns/issues/4) then you should just be able to roll the package in Chrome OS.

I don't know gentoo well enough but it looks like they have a live ebuild now:
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-auth/nss-mdns/nss-mdns-9999.ebuild

This seems to build from git and would pull in the new code to solve this problem.

What needs to be done to build nss-mdns from git in Chrome OS?

we don't do live git ebuilds like that in CrOS precisely because we don't want random upstream changes breaking our builds

but if there's a specific git sha1 in the upstream mdns git repo you want to pull from, you can write an ebuild easily enough to do that:
  SRC_URI="https://github.com/lathiat/nss-mdns/archive/47edc38926ed03adb38b835a0cda450e5158042f.tar.gz"

then again, if you have access to the repo, why not just start throwing tags into it ?  tags are cheap, and making a "release" is just pushing a new tag.

Makes perfect sense. I just checked the issues backlog and it looks like I should just make a release. Thanks.

if the cognitive load for picking a version is high, you could always mix datestamp versions into it.  0.11.20180117.  or just change it to "1" and just start incrementing it all the time :).

I have made a release and commented on the Gentoo bugs pointing them at it:
https://github.com/lathiat/nss-mdns/releases/tag/v0.11

When Gentoo updates, I think we can just uprev, correct?

yep

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/20d8b94ef8d699eedccac7d2ca2264b1e3ba1f28

commit 20d8b94ef8d699eedccac7d2ca2264b1e3ba1f28
Author: Adam Goode <agoode@chromium.org>
Date: Tue Jul 24 04:04:59 2018

nss-mdns: upgraded package to upstream

Upgraded sys-auth/nss-mdns to version 0.13 on amd64, arm, x86

BUG= chromium:626377 
TEST=boot, `avahi-set-host-name computers`, `getent hosts computers.local`

Change-Id: I570dc64636094f4c0d625620a2bb3a04cbd78eb5
Reviewed-on: https://chromium-review.googlesource.com/1146056
Commit-Ready: billybob thorton <notfirstyourlast1@gmail.com>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/20d8b94ef8d699eedccac7d2ca2264b1e3ba1f28/sys-auth/nss-mdns/Manifest
[delete] https://crrev.com/21d3467a99b5dcb2d8a59112ae3ef9f850611b28/sys-auth/nss-mdns/nss-mdns-0.10-r2.ebuild
[add] https://crrev.com/20d8b94ef8d699eedccac7d2ca2264b1e3ba1f28/metadata/md5-cache/sys-auth/nss-mdns-0.13
[add] https://crrev.com/20d8b94ef8d699eedccac7d2ca2264b1e3ba1f28/sys-auth/nss-mdns/nss-mdns-0.13.ebuild
[modify] https://crrev.com/20d8b94ef8d699eedccac7d2ca2264b1e3ba1f28/sys-auth/nss-mdns/metadata.xml
[delete] https://crrev.com/21d3467a99b5dcb2d8a59112ae3ef9f850611b28/sys-auth/nss-mdns/files/nss-mdns-0.10-avahi-socket.patch
[delete] https://crrev.com/21d3467a99b5dcb2d8a59112ae3ef9f850611b28/metadata/md5-cache/sys-auth/nss-mdns-0.10-r2

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ead92f55c446e7ac1f3ffc93dedcef8a229be9bc

commit ead92f55c446e7ac1f3ffc93dedcef8a229be9bc
Author: Adam Goode <agoode@chromium.org>
Date: Tue Jul 24 19:44:23 2018

Re-enable mDNS resolution for glibc

nss-mdns 0.13 will automatically avoid conflicting with unicast
.local TLD resolution. It implements the same heuristics as
macOS as documented at https://support.apple.com/en-us/HT201275.

This reverts commit 90d73bd671f5c9b3cd4a487cce4bd49b7c084dc1.

BUG= chromium:626377 
TEST=boot, `avahi-set-host-name computers.local`,
     `getent hosts computers.local`, see result,
     add SOA record to unicast DNS for `local`,
     `getent hosts computers.local`, see no result

Change-Id: I377b3dc4198d20574adc0e9fc9fe4b5cec0ff23a
Reviewed-on: https://chromium-review.googlesource.com/1146201
Commit-Ready: Adam Goode <agoode@chromium.org>
Tested-by: Adam Goode <agoode@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/ead92f55c446e7ac1f3ffc93dedcef8a229be9bc/profiles/targets/chromeos/package.use

Closing this as Verified. Re-open if you continue to see this issue.