hashicorp / mdns

Simple mDNS client/server library in Golang
MIT License
1.17k stars 208 forks source link

DNS-SD #6

Open oleksandr opened 10 years ago

oleksandr commented 10 years ago

Any plans to add DNS-SD support (http://tools.ietf.org/html/rfc6763) ?

md5 commented 10 years ago

I was under the impression that this library already implements DNS-SD over mDNS (i.e. it will serve SRV and TXT records that allow service discovery). That being said, the records that are being returned currently not in the expected format. See #4.

oleksandr commented 10 years ago

Thanks for pointing out! I've noticed this just playing around with this library and built-in OSX's 'dns-sd' commands and noticed that everything registered with 'dns-sd -R' is not visible by listener using this lib. Same with 'dns-sd -B' - it can't see the registration from the lib. Adding extra logging options has shown that the lib responds to queries but the format is not accepted by 'dns-sd -B/-Z'.

md5 commented 10 years ago

I've also had trouble getting the library to play nice with dns-sd and avahi-browse, but I hadn't pinned down the problem yet. I've largely been blaming my novice-level Go skills and wasn't ready to raise an issue yet.

richtr commented 10 years ago

I managed to get this library to play nicely with dns-sd -B with my fork at https://github.com/richtr/mdns (the full diff is available in #4).

dig can be useful for debugging at the DNS level. You can register a new mDNS service via this lib and then run the following from Terminal to query all DNS entries for that service:

dig -p 5353 @224.0.0.251 _myservice._tcp.local. any

If you compare the DNS records this library returns compared to e.g. AirPlay (_airplay._tcp.local.) DNS-SD records then perhaps you will arrive at the same proposed fixes as #4.

To ensure full mDNS + DNS-SD spec compliance we should probably try to hook this up to the 'Bonjour Conformance Test' available at https://developer.apple.com/bonjour/index.html but I haven't yet figured out an easy way to do that. Any ideas?

oleksandr commented 10 years ago

@richtr Testing it at the moment. Thank you for suggestions! I think hooking to conformance test would be a win. Putting this on my todo... I will keep you posted.

armon commented 10 years ago

@richtr Any interest in merging the changes in upstream? I apologize of not having enough time to dedicate to this project.

lsowen commented 10 years ago

Hi,

I just now saw that you are already working on this issue, but I have made some changes to a branch to attempt to accomplish DNS-SD compliance. I have reworked client.go so that it:

  1. Listens on multicast
  2. Caches all mdns traffic while the client 'server' is active (will need to implement TTLs and cache expiration)
  3. Replays cache when client.Query is called (this is important because DNS-SD implementations "pre-reply" with SRV and TXT records, and won't re-reply with them for at least 1 second after the original PTR query)

The DNS-SD implementation is only half-baked at the moment, but I think it is pretty clean. You can see the full changes here: https://github.com/lsowen/mdns/compare/armon:master...master

An example of using the current DNS-SD interface: https://gist.github.com/lsowen/4f51a27cc58cf56884b4

oleksandr commented 10 years ago

@richtr I was playing with your fork and noticed that regardless that dig -p 5353 @224.0.0.251 _myservice._tcp.local. any shows similar records to what is registered with dns-sd -R the dns-sd -B still does not "see" the registration from a custom server. The recent @armon version after merging @richtr PR behaves the same. It seems that DNS-SD is not yet properly implemented.

oleksandr commented 9 years ago

It took a bit longer to allocate some time and play around with mDNS/DNS-SD... To me it appears that changing the current mdns package for DNS-SD requires too many efforts (although I might be wrong). I tried to put completely revised DNS-SD functionality somehow resembling current package here: https://github.com/oleksandr/bonjour The server-side code is pretty clumsy, but I've managed to make it working both sides with built-in dns-sd command on my OSX.

So my suggestion would be to leave mdns package as it is to have a pure mdns functionality and have dns-sd implemented separately. Comments, help, suggestions are welcome!

lsowen commented 9 years ago

The only reason I re-worked it is because the package was already partially doing DNS-SD, so I exposed raw mdns and got DNS-SD lookups working.

oleksandr commented 9 years ago

Yes, the lookups is easy to add to existing package. I was not happy with registration. One of the issues - multicasting responses from the server (current mdns server sends responses directly to the sender of the query).

joshcarter commented 9 years ago

Browsing this thread and #7 it's clear that there is confusion between mDNS and DNS-SD. DNS-SD is frequently used over multicast DNS, so that's understandable.

Looking at the readme for this project, which is currently Google's top result for the search "golang dns service discovery," the authors intended a library that serves the same role as DNS-SD, but it's oddly non-compliant with actual DNS-SD. The readme should really have a warning to this effect, as (like others here) I've lost half a day trying to figure out why I can't get this library to interact with either Mac OS X or Avahi.

So, which is the right library to follow? I've checked out the work by @oleksandr, @lsowen, and @richtr, all of which looks great, but I can't tell which is going to stay active going forward. Ideally @armon would pick one to merge and keep this library the authoritative version. (Another option is wrapping libdns_sd, which might be easier overall and guarantee compatibility.)

Thanks @armon and everyone in this thread. Let me know if I can help in any way.

brutella commented 9 years ago

I'm actively using @oleksandr's bonjour library. After this merge it works good enough on OS X with dns-sd.

armon commented 9 years ago

We originally made this library to leverage multicast to help Serf auto discover, not planning to use any formal specification. The community has helped to push it towards DNS-SD, but I don't know how close we are to actually implementing it. If there is a community fork that does fully implement it, I'm happy to merge towards that. Our current issue is that we don't have much time to maintain this and it is a relatively low priority relative to our many other projects. Also major changes to this cause incompatibilities to Serf which breaks customer installs.

joshcarter commented 9 years ago

@armon I understand your requirements didn't include inter-operability with the ecosystem that exists around DNS-SD. Could you at least add a note to the readme warning of the incompatibility? As I mentioned, this library is currently the top Google hit for those of us searching for Go DNS-SD.

For the possible benefit of others following this thread, a note on terminology, as explained in the "Zero-Configuration Networking" book by Steinberg and Cheshire (highly recommended):

The three layers of ZeroConf are:

The three layers of ZeroConf stack on one another: addressing, naming, and services. It's not mandatory to use all three. For most of us, service discovery is the essential bit we're looking for.