Use case(s) - what problem will this feature solve?

In cases where DNS is used by workloads for peer discovery, it may be necessary to make dynamic changes to allow traffic to flow from one failure domain to another. In such cases, thegRPC default polling interval of 30 minutes is too slow to allow for flexible traffic movement - it could instead be configurable for users who require more precise control over their traffic flow.

Proposed Solution

Extendresolver.BuildOption to include additional configuration.

type BuildOption struct {    ...    // PollingInterval is the minimum amount of time to wait    // between name resolution attempts.    PollingInterval time.Duration}

This creates an implicit contract for Builder implementations to respect the provided configuration. Since I'm not familiar with what implementations of Builder exist beyond DNS, I'll defer to the maintainers to decide whether this is a good idea.

The usage would need to include some way to bubble this configuration up to the Client, for example:

func WithResolverPollingInterval(time.Duration) DialOption

This isn't a great API, but 🤷‍♂I'm open to suggestions.

Alternatives Considered

Extendinternal/resolver/dns to expose additional constructor options and re-export them inresolver/dns.

type BuilderOption func(*dnsBuilder)func WithPollingInterval(time.Duration)func WithScheme(string)func NewBuilder(...BuilderOption) resolver.Builder

Usage would be something like:

resolver.Register(dns.NewBuilder(    dns.WithScheme("customdns"),    dns.WithPollingInterval(time.Minute),))

This approach is kind of nice because the polling configuration can be isolated to thedns package. On the other hand, users mustRegister() the custom Builder inside aninit() function, which generally occurs before any configuration can been loaded, which creates a bit of an awkward API surface.

Thanks for your consideration!