3 ms·

SkyDNS is pretty nice, but I'm not sure I see a huge value in layering DNS on top of etcd for microservices, unless you also standardize the SRV format being us

SkyDNS is pretty nice, but I'm not sure I see a huge value in layering DNS on top of etcd for microservices, unless you also standardize the SRV format being used. Why not just use etcd directly? After all, the format has a proprietary format/structure that no tool (outside the SkyDNS sphere) knows about. So you've already invented a new protocol on top of DNS. You're not able to leverage any existing tool/library out there that resolves names via DNS, because they can't use your information. (SkyDNS can of course be used to look up A/CNAME records, which I totally agree is nice, but as more of a backwards-compatibility layer kind of thing.) You do get some value from libc's name resolution, and you can institute a policy across your apps that they resolve subdomains relative to the domains listed in resolv.conf, so for one app to talk to another, they just look up "fnord", which resolves to "fnord.dc-east.production.example.com" or whatever. But I'm still not sure I see a lot of value over a client library that talks directly to etcd. You're going to want a client library anyway, to deal with those SRV records.

fastest963 11y ago
You bring up good points. The big advantage I see is the ability to fallback to standard tools if you don't want to use SRV. If I want to debug something I can just type "dig SRV myservice.mydomain" and see the results. I can also just use standard DNS libraries to do just regular A lookups if you don't care about priorities. For anyone else that does, we've released a bunch of libraries so they don't have to do anything to start using it. I also wouldn't say that SRV records are proprietary, they're an official record-type (that many DNS providers support). Personally, I just don't see why anyone should be creating their own format when some other established and compatible one exists. DNS is already widely used for domain/website discovery, why should that not be extended to inter-datacenter discovery? That's obviously rhetorical for this conversation, but that's what we asked ourselves.
- lobster_johnson 11y ago
  Ah, you're right — for some reason I was under the impression that the format of a SRV record was specific to the protocol, but apparently it isn't. My thinking was confused by the fact that SkyDNS apparently doesn't use the standard name format, as specified by the RFC: _Service._Proto.Name TTL Class SRV Priority Weight Port Target [1] https://tools.ietf.org/html/rfc2782 https://tools.ietf.org/html/rfc2782
  - bketelsen 11y ago
    SkyDNS supports whatever naming scheme you want to use. You set the names yourself. That means it can be compliant with RFC2782 if you choose, or the names can be semantic -- like Kubernetes uses, with each position in the name implying a semantic meaning "servicename.kubenamespace.domain" Disclaimer: I invented SkyDNS.
  - ecnahc515 11y ago
    As bketelsen says, you can use any name format, but that specific format isn't strictly enforced. In Kubernetes, that is the format used when using the DNS addon (which is powered by SkyDNS).
KaiserPro 11y ago
I know this might sound odd, but ETCD and DNS look pretty similar. They are both hierarchical distributed key:value databases (well if you ignore SRV and TXT records...) Both have a system for time limiting keys. However etcd comes with a REST protocol built in, and higher latency. I'm not saying that DNS is better than ETCD.

fastest963 11y ago

You bring up good points. The big advantage I see is the ability to fallback to standard tools if you don't want to use SRV. If I want to debug something I can just type "dig SRV myservice.mydomain" and see the results. I can also just use standard DNS libraries to do just regular A lookups if you don't care about priorities. For anyone else that does, we've released a bunch of libraries so they don't have to do anything to start using it. I also wouldn't say that SRV records are proprietary, they're an official record-type (that many DNS providers support). Personally, I just don't see why anyone should be creating their own format when some other established and compatible one exists. DNS is already widely used for domain/website discovery, why should that not be extended to inter-datacenter discovery? That's obviously rhetorical for this conversation, but that's what we asked ourselves.

lobster_johnson 11y ago
Ah, you're right — for some reason I was under the impression that the format of a SRV record was specific to the protocol, but apparently it isn't. My thinking was confused by the fact that SkyDNS apparently doesn't use the standard name format, as specified by the RFC: _Service._Proto.Name TTL Class SRV Priority Weight Port Target [1] https://tools.ietf.org/html/rfc2782 https://tools.ietf.org/html/rfc2782
- bketelsen 11y ago
  SkyDNS supports whatever naming scheme you want to use. You set the names yourself. That means it can be compliant with RFC2782 if you choose, or the names can be semantic -- like Kubernetes uses, with each position in the name implying a semantic meaning "servicename.kubenamespace.domain" Disclaimer: I invented SkyDNS.
- ecnahc515 11y ago
  As bketelsen says, you can use any name format, but that specific format isn't strictly enforced. In Kubernetes, that is the format used when using the DNS addon (which is powered by SkyDNS).

KaiserPro 11y ago

I know this might sound odd, but ETCD and DNS look pretty similar. They are both hierarchical distributed key:value databases (well if you ignore SRV and TXT records...) Both have a system for time limiting keys. However etcd comes with a REST protocol built in, and higher latency. I'm not saying that DNS is better than ETCD.