search

rancher / rio

Application Deployment Engine for Kubernetes
https://rio.io
Apache License 2.0
2.27k stars 228 forks source link

Support Different Domain providers in RDNS #556

Open Vad1mo opened 4 years ago

Vad1mo commented 4 years ago

The build in RDNS functionality is great to get started immediately, however it is not always possible to use .on-rio.iodomains especially in sensitive environments where you need to control domain.

Instead of deactivating RDNS for supporting custom domains it would be better for the user experience to extend RDNS to support other DNS provider.

Mature golang libraries already exist to make integration easier.

One of such library could be: https://github.com/StackExchange/dnscontrol or https://github.com/kubernetes-incubator/external-dns

StrongMonkey commented 4 years ago

Supporting other DNS providers could really be a question that should we manage user's credential in Rio cluster to be able to manage DNS records? Then this really give Rio the ability to manage external DNS, which I don't know if Rio should be able to manage that or that. @vincent99 @cjellick

Vad1mo commented 4 years ago

For me as a product creator in such cases the question would be: Can we provide the developer with a consistent user experience, no matter if .on-rio.io or any other DNS provider. I personally think that a consistent user experience is more valuable in the long run than delimitation of responsibility.

Saying that: What really would matter for me as a RIO user is an easy way to use other DNS provider like it is now with RDNS regardless of the way.

vincent99 commented 4 years ago

We provide the on-rio.io service because it makes that free and automatic. You can certainly run your own copy of the DNS service on your own domain and tell Rio to use that.

But I don't think there's significant demand for or benefit to adding an entirely different mode where you must configure Rio to use a particular provider/domain/credential* stored in the cluster and have it push changes up.

The primary things the the generated names are for is CNAMEing to your actual domain, or experimenting. If you're CNAMEing, most people do not really care what intermediate domain their site resolves through (e.g. half the world is yoursite.com -> your-site-12345.us-west-2.elb.amazonaws.com -> IPs).

*: Which has its own set of risks.. Many of the providers those DNS updater packages support have no way to create an API key that's good only for one particular zone, let alone a subset of a zone. So now you have keys that can edit any arbitrary DNS entry for your company sitting on the cluster where potentially lots of people can see it.

cjellick commented 4 years ago

@StrongMonkey regarding this bit: "You can certainly run your own copy of the DNS service on your own domain and tell Rio to use that." Is it currently possible to "tell Rio to use that"? If so, how do you configure that?

StrongMonkey commented 4 years ago

@cjellick it is not possible in the current release, need small tweak to make it configurable.

renebakx commented 4 years ago

So if I don't mind swapping out the build in RDNS service as a Domain name provider, for a self hosted version we can swap out the *.on.rio.io domain for a personal wildcard domain?

Cause that would be a very desirable feature. Not that we want to hide rio, but from a branding and product ownership point of view we rather have to full ownership on the domain name. :)

vincent99 commented 4 years ago

Yes apparently we're missing the setting to tweak the endpoint Rio uses to get the name, but you would run your own copy of the rdns-server, point the domain at it, and then that would give back names for your own domain.