DnsNameResolverBuilder directly so that users can modify specific settings with more freedom

Are you considering exposing Consumer<DnsNameResolverBuilder> after setting Armeria’s default configurations?

Are you considering exposing Consumer after setting Armeria’s default configurations?

Right, similar to how we are already exposing GraphQlServiceBuilder#runtimeWiring or ServerBuilder#childChannelPipelineCustomizer.

Alternatively, I think we can also expose Consumer<DnsNameResolverBuilder> in a less exposed location (e.g. Flags) where the default DnsNameResolverBuilder is applied first, and then resolver-specific configurations are applied like in the snippet you shared.

Continuously updating the API might be painful. However, the Netty API hasn’t changed frequently recently and there’s already a delegated builder for DNS resolver. So I’m slightly leaning toward adding setters to DnsResolverGroupBuilder for now.

How about considering introducing a customizer if a similar issue arises again in the future?

Alternatively, I think we can also expose Consumer in a less exposed location (e.g. Flags) where the default DnsNameResolverBuilder is applied first

We could also introduce a new MoreFlags or ExperimentalFlags as opposed to Flags

Im also looking at this exact issue, was hoping that the Builder could be exposed. Thanks for looking at this issue!

It seems like the other maintainers prefer that DnsNameResolverBuilder is not exposed directly on the grounds of:

• DnsNameResolverBuilder does not seem to change very often
• To avoid breaking changes due to third party libraries

Let me just expose datagramChannelStrategy, socketChannel* for this iteration