Open oleksandr opened 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.
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'.
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.
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?
@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.
@richtr Any interest in merging the changes in upstream? I apologize of not having enough time to dedicate to this project.
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:
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
@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.
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!
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.
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).
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.
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.
@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.
Any plans to add DNS-SD support (http://tools.ietf.org/html/rfc6763) ?