Config providers such as a DNS based destination resolver are unnecessarily duplicative to implement

[samsp-msft]

There are scenarios like #2151 with Docker Swarm where the destination list needs to be dynamically resolved by DNS. This is different from what we support today in Destination configuration - although you can specify the destination host using DNS, it is expecting that to be a single host, and not a collection of hosts that needs to be used as the basis for load balancing.

In addition you want the host resolution to be dynamic, and constantly polling for changes to the DNS records as additional hosts can be added/removed. It could also be tied in with passive health checks, so that in the case of a failure, that can be a signal to poll the dns to see if the host is still listed, and if not what the alternatives are.

In this scenario, the DNS server with the addresses may not be the default for the host, and the DNS api built into .NET just uses the host platform's APIs for DNS resolution. This scenario may justify using a separate dns client such as DnsClient.NET which can be used to talk to the DNS server directly.

A DNS IProxyConfigProvider would implement the Cluster part of configuration and would populate the cluster properties based on an IConfiguration Section, except rather than having each destination explicitly enumerated, it would use DNS to resolve the host list, and poll/listen for dns changes and update the configuration as applicable.

However there are some problems with this concept:

• IProxyConfigProvider's can't overlap - they can supply unique objects, but they can't add extra info to each other
• IProxyConfigFilters can adjust config coming from another provider, but they can't invalidate and update configuration
• ConfigurationConfigProvider is sealed and most of its members are marked as private, so you can't just re-implement the CreateCluster method calling into the sub-routines that will parse out HttpClient, HealthChecks etc from IConfiguration.

We should fix one or all of the above to make this kind of scenario easier to implement.

[samsp-msft]

#1698 covers some of this by exposing the methods.