components-contrib
components-contrib copied to clipboard
dapr
[Proposal] common DNS interface
Describe the proposal
As well known, CSPs usually have their own DNS components, if a CSP wants to introduce Dapr, they would like to implement here. One DNS for one CSP introduced brings more maintenance cost.
Why not provide a common DNS interface for this case, just need to config DNS address then any CSP can use own DNS server?
/cc @yaron2 @artursouza
Are you talking in terms of DNS for dapr while specifying in CSP headers?
I am not sure what do you mean about CSP headers, my point is that create an easier way to use DNS from CSP rather than implement it in components-contrib.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
I am concerned about pushing Dapr down to layer 4. Can someone provide an example of a scenario where this would benefit cloud native developers? This can help ground the discussion to concrete points.
@artursouza maybe the title mislead you :(
Many CSPs/software provide their own name resolution, like
- https://github.com/polarismesh/polaris
- https://github.com/hashicorp/consul
Now we have some DNS implemented, but like other components, implement needs much time. If we can directly use third-party DNS with abstract calls, developers will benefit from it. What I propose maybe not be an API, more like pluggable DNS components.
@daixiang0 - The name resolutions components provide this abstaction over DNS. How is this different from implementing a Name Resolution component as there exists for Consul today? https://github.com/dapr/components-contrib/tree/master/nameresolution/consul
My thought is that no need to implement it into Dapr, just use this to call remote DNS by config.
Would it be feasible to tell Dapr to use a Key/Value file similar to the hosts file in Windows so it can locate each Service?
Dapr-App-Location file
App1 app1.mydomain.com
App2 app2.mydomain.com
App3 app3.mydomain.com
In our case we are hosting everything in AWS ECS and we are unable to use Service Invocation building block due to this limitation (mDNS does not work and we don't want to configure yet another service like Consul).
AWS ECS Service Discovery already provides the DNS resolution capability that we need but we can't use it.
@fbridger. Implementing a Name Resolution component for AWS ECS service discovery really is the way to go IMO. https://github.com/dapr/components-contrib/issues/1197 Would you want to take a look implementing this, since the Name Resolution API is very simple.
You could have a static file Name Resolution component like a host file but given the required dynamic name of name resolution if is not that useful IMO.
If you mean AWS ECS service discovery, please track #1197.
For now, DNS still does not have a common interface.