microsoft / reverse-proxy

A toolkit for developing high-performance HTTP reverse proxy applications.
https://microsoft.github.io/reverse-proxy
MIT License
8.61k stars 846 forks source link

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

Open samsp-msft opened 1 year ago

samsp-msft commented 1 year ago

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:

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

samsp-msft commented 1 year ago

1698 covers some of this by exposing the methods.