DNS-SD support for etcd server and client discovery

[andrepearce]

What would you like to be added?

Implementation of DNS-SD as defined by RFC 6763, so that server and clients nodes can be discovered when advertised using DNS-SD. Refer to section 4.1 of RFC 6763 for the key differences between the current DNS discovery approach etcd supports and using DNS-SD.

Why is this needed?

It is a more standards based approach towards performing service discovery that supports both unicast and multicast DNS transparently to etcd.

[andrepearce]

If we agree this would be of value, I am happy to work on it for us.

[ahrtr]

etcd should have already support bootstraping an etcd cluster using DNS service discovery. FYI. config.go#L184-L185

But unfortunately, I do not see any formal document related to this. Please read the following related issues:

• https://github.com/etcd-io/etcd/issues/13948
• https://github.com/etcd-io/etcd/issues/13691
• https://github.com/etcd-io/etcd/issues/11335

[ahrtr]

Probably we should add document on this.

[andrepearce]

I agree there is a lack of documentation in this area around what etcd does support. However, irrespective of that, I have had a look at those issues and also the current etcd discovery code implementation and I don't believe the DNS discovery implementation is actually aligned with "true" DNS-SD, as discussed in RFC 6763.

Specifically, the DNS-SD RFC talks about "A client discovering the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form ".", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs."

etcd (the client in this case) as far as I am aware does not follow this approach, and instead queries for an SRV record directly, as opposed to using a PTR record to discover the available SRVs. I am making this statement based on the code wrapping and eventually invoking the following lookupSRV call. https://github.com/etcd-io/etcd/blob/026794495f66edfc72b4d8c55b6f6b9d23f2064b/client/pkg/srv/srv.go#L52

[ahrtr]

I do not get time to read the RFC you mentioned, please read https://github.com/etcd-io/etcd/blob/cff96fe3a4416c1ce017e4de5d479ecd57d46ecb/etcdctl/ctlv3/ctl.go#L75-L76 and https://github.com/etcd-io/etcd/blob/026794495f66edfc72b4d8c55b6f6b9d23f2064b/client/pkg/srv/srv.go#L101 . Does it meet your requirement?

[andrepearce]

Unfortunately no, neither of those meet the requirements of DNS-SD. Primarily because neither actually query for a PTR record to fetch available SRVs, they instead query for an SRV record directly using the config flags you linked above to construct the name of the SRV. I believe what etcd implements in the way of DNS discovery service is called "traditional DNS SRV", as opposed to DNS-SD. I got the term "traditional DNS SRV" as this is what is is referred to as in RFC 6763.

[andrepearce]

I would at the very least suggest taking a read of the introduction and section 4.1 (which is only a paragraph long) of the RFC I linked and it should hopefully highlight the difference in DNS-SD and what is implemented by etcd.

[ahrtr]

Thanks for the explanation. It may not be a priority for now.

Do you have a real use case? If yes, could you elaborate?

[andrepearce]

Yes, currently there is no good way to setup etcd with service discovery on a multicast based environment. You either have to settle with using a static setup (i.e. no discovery) or implement some custom "DNS proxy" that can translate from the multicast discovery world to the way that etcd expects.

This ultimately raises unnecessary challenges for enterprises spawning a cluster on-prem that is backed by mDNS. Adding this support for DNS-SD essentially allows us to transparently support service discovery in both a unicast and multicast setup. In other words, etcd wouldn't need to care whether your environment is backed by unicast or multicast for service discovery, and there would be no custom DNS proxy or anything like that needed, it would just simply work. This really makes the etcd service discovery mechanism solid and well adaptable.

I also think this is quite a low hanging fruit for us in terms of uplifting our current implementation to align with the DNS-SD RFC. In essence we simply need to introduce one more layer of abstraction on top of our existing SRV discovery logic to query for a PTR record first before querying for SRV records. We could do this in a way that would prevent existing solutions relying on the current DNS discovery approach to stop working.

As I mentioned, I can work on this for us, I will just need advice/input on how best we should go about seeding this capability from our config flags, but we can discuss those details later I guess.

[andrepearce]

Can we re-label this so it reflects the work more accurately ? (i.e. it's not really a documentation task)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[Aditya-Sood]

hi @andrepearce @ahrtr is this issue still open for contribution?