Implement new MDNS spec

[Stebalien]

That is, libp2p/specs#80. We'll need to:

1. Use https://github.com/miekg/dns to handle parsing/formatting DNS records.
2. See https://github.com/grandcat/zeroconf/blob/85eadb44205c14827ae7cbb129bc7eed4488dd25/connection.go#L38-L97 for how to listen for multicast packets. However, we'll need to use https://github.com/libp2p/go-reuseport/blob/b72b23b78b80078df1a7991f6ca39942cb8cc5e1/interface.go#L47-L49 to fix multiple MDNS applications.

Unfortunately, none of the existing golang mdns solutions work for us as:

1. They all have race conditions.
2. None of them use reuseport.
3. All of them are very DNS-SD focused and go through a lot of effort to make sure we get things like A and AAAA records.
4. We need to use the system's mDNS responder when possible, as running multiple mDNS responders on the same machine is pretty broken.

We could try to patch these however, we'll likely end up with something better if we just write something ourselves.

[jbshirk]

I've been getting this too, since latest upgrade

go-ipfs version: 0.4.20-
Repo version: 7
System version: amd64/darwin
Golang version: go1.12.4

13:22:59.785 ERROR mdns: mdns lookup error: failed to bind to any unicast udp port mdns.go:139
13:23:09.783 ERROR mdns: mdns lookup error: failed to bind to any multicast udp port mdns.go:139

It typically happens about every hour or hour and a half. My gut feeling is that in my case it may be due to the terrible Arris cable modem (Comcast) which is notorious for crashing, restarting, or spontaneous DNS and/or WiFi failures. FYI.

maintainer note: moved to ipfs/kubo#6359, this issue isn't a bug report

[kpp]

They all have race conditions.

I can fix data races. This is not a big deal. See whyrusleeping/mdns#5. Also I discovered hashicorp/mdns#66 , so we can merge these two and get a data race free implementation.

[Stebalien]

@kpp that would be awesome. We'd still want to switch to a new library for the other reasons but having a race-free go-ipfs would be nice.

[kpp]

I wrote to hashicorp/mdns, let's see if they still want to maintain the lib.
hashicorp/mdns#75

[ravenlandpush]

Please fix this, this 'bug' is encountered in situations even when there is a single IPFS daemon running on port 4001 with no other daemon sharing it.

Although restarting go-ipfs resolves the error, it stands to reason if port 4001 is seen as 'filtered' or if ipfs-go is capable of detecting that it cannot bind to the port, it should take some action like reforking itself so that it is bound, instead of just sit their polling the error for eternity doing nothing.'

I could write something to fix this by logging to a file with nohup or something but , much like ipfs pin jobs, this is not a 'solution' to the cause, it's a patch to the problem. What is the best proposition to fix this at present?

Surely there is better approach, or a way to fix this, its fairly critical is it not? If some ipfs servers are likely literally sitting offline unbeknownst of this issue or what it means. Is there not a failsafe way to ensure that port gets re-used in ipfs configuration?

Best wishes,
Adam

[Stebalien]

(copying my reply from the go-ipfs issue)

This issue will not prevent your daemon from listening on port 4001. It will only prevent mdns from working properly.