I'm not sure what you mean about "actual DNS" but I'm going to assume you mean A records and not SRV records. A records are available for all services as well with this set up we just preferred to use SRV so we can get port information as well as weighting. If you want to stick to just A records that's definitely an option.
I read this as just "actual DNS". An actual DNS server, that serves the records you need, like SRV records. Eg. djbdns[1]. It's not like using DNS SRV for service discovery is some crazy thing; Kerberos uses it, and by extension Windows AD[2].
Other "recent" uses of SRV is XMPP server discovery.
Anyway, SkyDNS might be great -- but is it tested/aimed at being better/faster than other battle-tested DNS servers? Everyone needs to host DNS in some way -- can they standardize on one server, and just use SkyDNS? Should they?
Or is the main thing just wrapping a REST api around DNS? [ed: like [3,4]]
Even if I need/should use a non-standard (non-authorative, not connected to the Internet root) DNS infrastructure for service discovery, do I need to turn off caching if I want to use SkyDNS for it?
A lot of these kind of questions leap to mind.
To draw a parallel, one can use nginx for TLS termination, reverse-proxy and as a host for static assets -- often it'd be good to set them up as different services, even if they run the same software. It a) allows easy switch if needed (maybe HAProxy turned out to be a better load balancer), and easy scalability. But all else being equal, without any major differences in performance (order of magnitude), or feature set -- having two instances of one piece of software is likely simpler than having one instance each of two pieces of software.
So, in that light, "What's wrong with actual DNS"? :-)
Well an actual DNS server, Whats wrong with authoritative DNS? just use DNS NOTIFY to update slaves on record change.
That way TTL is not a problem, unless you have SSSD or nslcd doing caching on the client.
It'll remove a massive layer of complication, and will mean that you can have redundant service discovery even if your ETCD/skydns fails.
It'll certainly scale much, much higher than skydns. if you don't want to create your own DNS, Use Dyn. It has a REST interface, a very nice SLA. if you query the servers directly you also don't have to worry about TTLs
Right, if you know how to set it up or have infrastructure in place... But most developers don't have time to read 600+ pages on how to run bind server OR simply have ops team that is very conservative at what goes in the DNS land.
failing that, bind is not difficult to learn. If you have an artificial divide between your devs and you, then you have far bigger issue. If you can't convince them of the merit of using DNS then there really is no hope.
the whole point of DNS is that you can delegate subdomains, so you can neatly isolate zones from each other
Plus saying something looks hard is a terrible justification for not trying something. I know bind isn't trendy, but it works and is simple. Failing that, there are at least 3 companies out there with REST APIs and 100% uptime SLAs.
