Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS-SD #6

Open
oleksandr opened this issue Sep 3, 2014 · 15 comments
Open

DNS-SD #6

oleksandr opened this issue Sep 3, 2014 · 15 comments

Comments

@oleksandr
Copy link

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

@md5
Copy link

md5 commented Sep 3, 2014

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
Copy link
Author

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
Copy link

md5 commented Sep 3, 2014

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
Copy link
Contributor

richtr commented Sep 4, 2014

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
Copy link
Author

@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
Copy link
Member

armon commented Sep 4, 2014

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

@armon armon mentioned this issue Sep 7, 2014
@lsowen
Copy link

lsowen commented Sep 11, 2014

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: lsowen/mdns@armon:master...master

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

@oleksandr
Copy link
Author

@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
Copy link
Author

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
Copy link

lsowen commented Oct 20, 2014

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

brutella commented Jun 2, 2015

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

@armon
Copy link
Member

armon commented Jun 2, 2015

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
Copy link

@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):

  • "ZeroConf" is the name for three related layers of auto-configuration tooling (more below). See zeroconf.org for more info.
  • "Bonjour" is the trade name for Apple's implementation of ZeroConf.

The three layers of ZeroConf are:

  • Link-layer addressing: this allows devices on a network to get IP addresses without the help of a DHCP server or static addressing. If there's a DHCP server or static addresses set, this layer isn't necessary.
  • Multicast DNS: allows individual machines to publish DNS records to other machines on their subnet. This includes both names and service records. If the network has DNS and it's set up to allow any machine to publish name/service/etc records, then multicast DNS isn't necessary either.
  • DNS Service Discovery: allows individual processes to publish the service(s) they offer, and other processes to discover them.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants