starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #2188] Not convenient to call bind_with_addr to make a AsyncResolver #912

New issue

Open

opened 2026-03-16 00:51:10 +03:00 by kerem · 6 comments

kerem commented

2026-03-16 00:51:10 +03:00

Owner

Originally created by @hainesc on GitHub (Apr 20, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2188

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Maybe I have missed something, but AFAIK, it is not convenient to call bind_with_addr when I want to make dns resolver with a specific network interface.

Now I can write as below:

let (config, options) = trust_dns_resolver::system_conf::read_system_conf()?;

// but how can I set bind addr for config here. Since `set_bind_addr` is a method of `NameServerConfigGroup`, but `name_servers` in ResolverConfig is not public.

let provider = ...
let resolver = trust_dns_resolver::new_with_conn(config, options, provider)

I don't like copy the code how trust_dns_resolver::system_conf::read_system_conf() does and set bind addr there.

Describe the solution you'd like
A clear and concise description of what you want to happen.

And I think make a method named set_bind_addr for ResolverConfig will be a simple solution.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

https://github.com/hickory-dns/hickory-dns/blob/main/crates/resolver/src/config.rs#L827

Originally created by @hainesc on GitHub (Apr 20, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2188 **Is your feature request related to a problem? Please describe.** A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Maybe I have missed something, but AFAIK, it is not convenient to call bind_with_addr when I want to make dns resolver with a specific network interface. Now I can write as below: ``` let (config, options) = trust_dns_resolver::system_conf::read_system_conf()?; // but how can I set bind addr for config here. Since `set_bind_addr` is a method of `NameServerConfigGroup`, but `name_servers` in ResolverConfig is not public. let provider = ... let resolver = trust_dns_resolver::new_with_conn(config, options, provider) ``` I don't like copy the code how trust_dns_resolver::system_conf::read_system_conf() does and set bind addr there. **Describe the solution you'd like** A clear and concise description of what you want to happen. And I think make a method named `set_bind_addr` for ResolverConfig will be a simple solution. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. **Additional context** Add any other context or screenshots about the feature request here. https://github.com/hickory-dns/hickory-dns/blob/main/crates/resolver/src/config.rs#L827

kerem added the

cleanup

crate:resolver

has workaround

labels

2026-03-16 00:51:10 +03:00

kerem commented

2026-03-16 00:51:21 +03:00

Author

Owner

@hainesc commented on GitHub (Apr 20, 2024):

If that is acceptable, I can make a PR ASAP.

@hainesc commented on GitHub (Apr 20, 2024): If that is acceptable, I can make a PR ASAP.

kerem commented

2026-03-16 00:51:26 +03:00

Author

Owner

@hainesc commented on GitHub (Apr 20, 2024):

@hainesc commented on GitHub (Apr 20, 2024): Related issue: https://github.com/hickory-dns/hickory-dns/issues/2087

kerem commented

2026-03-16 00:51:31 +03:00

Author

Owner

@djc commented on GitHub (Apr 22, 2024):

bind_addr is a public property of NameServerConfig so by itself that seems easy enough to change. I guess it might be okay to expose a groups_mut() accessor on ResolverConfig and a servers_mut() accessor on NameServerGroup?

@djc commented on GitHub (Apr 22, 2024): `bind_addr` is a public property of `NameServerConfig` so by itself that seems easy enough to change. I guess it might be okay to expose a `groups_mut()` accessor on `ResolverConfig` and a `servers_mut()` accessor on `NameServerGroup`?

kerem commented

2026-03-16 00:51:36 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 18, 2024):

We could definitely make NameServer and NameServerGroup configuration more ergonomic. I haven't revisited these interfaces in a while, there are probably better patterns that could be adopted.

@bluejekyll commented on GitHub (May 18, 2024): We could definitely make NameServer and NameServerGroup configuration more ergonomic. I haven't revisited these interfaces in a while, there are probably better patterns that could be adopted.

kerem commented

2026-03-16 00:51:42 +03:00

Author

Owner

@GICodeWarrior commented on GitHub (Jul 9, 2024):

I will try and summarize my current understanding of the situation and then summarize a few options.

Current Situation

Sometimes it's useful to build a configuration based on the system configuration (i.e. system_conf::read_system_conf()) with some modifications. (e.g. custom bind address, timeout, protocol, etc.)
Modifying the configuration can be difficult or impossible without initializing a new configuration entirely. For example:
- Bind address is configured on the NameServerGroup held by ResolverConfig
- Timeout is configured on ResolverOpts
- Protocol is configured on instances of NameServerConfig within the NameServerGroup held by ResolverConfig
Given the multiple layers of nesting and current mutability constraints, it's difficult to modify an existing configuration.

Some Improvement Options

These are still high level thoughts and not mutually exclusive. Based on your feedback I can make a more narrow/specific proposal if useful.

Mutable nested accessors - add accessors where necessary to grant mutable access to nested configuration structures (Possibly least invasive)
Top-level mutators - add functions to grant mutation of specific nested configuration parameters (e.g. set_bind_addr on ResolverConfig that pushes the address into each NameServerConfig within the NameServerGroup)
Less nesting - combine some configuration structs to reduce access complexity (e.g. move NameServerGroup functionality into ResolverConfig and/or move ResolverOpts into ResolverConfig)
Builder pattern - redesign the configuration to use the builder pattern
- https://doc.rust-lang.org/1.0.0/style/ownership/builders.html
- To facilitate variants of the system configuration, ResolverConfigBuilder could include a from method or static method accepting an existing ResolverConfig to copy options from

Please let me know your thoughts.

@GICodeWarrior commented on GitHub (Jul 9, 2024): I will try and summarize my current understanding of the situation and then summarize a few options. ### Current Situation 1. Sometimes it's useful to build a configuration based on the system configuration (i.e. `system_conf::read_system_conf()`) with some modifications. (e.g. custom bind address, timeout, protocol, etc.) 2. Modifying the configuration can be difficult or impossible without initializing a new configuration entirely. For example: * Bind address is configured on the `NameServerGroup` held by `ResolverConfig` * Timeout is configured on `ResolverOpts` * Protocol is configured on instances of `NameServerConfig` within the `NameServerGroup` held by `ResolverConfig` 3. Given the multiple layers of nesting and current mutability constraints, it's difficult to modify an existing configuration. ### Some Improvement Options These are still high level thoughts and not mutually exclusive. Based on your feedback I can make a more narrow/specific proposal if useful. 1. Mutable nested accessors - add accessors where necessary to grant mutable access to nested configuration structures (Possibly least invasive) 2. Top-level mutators - add functions to grant mutation of specific nested configuration parameters (e.g. `set_bind_addr` on `ResolverConfig` that pushes the address into each `NameServerConfig` within the `NameServerGroup`) 3. Less nesting - combine some configuration structs to reduce access complexity (e.g. move `NameServerGroup` functionality into `ResolverConfig` and/or move `ResolverOpts` into `ResolverConfig`) 4. Builder pattern - redesign the configuration to use the builder pattern * https://doc.rust-lang.org/1.0.0/style/ownership/builders.html * To facilitate variants of the system configuration, `ResolverConfigBuilder` could include a `from` method or static method accepting an existing ResolverConfig to copy options from Please let me know your thoughts.

kerem commented

2026-03-16 00:51:47 +03:00

Author

Owner

@djc commented on GitHub (Jul 9, 2024):

That sounds about right!

On your options:

Mutable nested accessors: I think this would be a straightforward improvement on the current state
Top-level mutators: this doesn't feel like a great idea, because it would more tightly couple all of the configuration types and create a sprawl of configuration API; your example of having a set_bind_addr() that implicitly updates all NameSserverConfig also feels a little too magic
Less nesting: I think that might be a good idea? To me the more obvious API would have ResolverOpts be part of ResolverConfig (perhaps by flattening it) and maybe also dissolve the NameServerConfigGroup type. Another aspect here is how we configure TLS, which might also want some refactoring (you can find earlier issues/PRs from @daxpedda about this -- for example, it would be nice to get rid of the static TLS configs).
Builder pattern: could potentially make sense, but I think we should probably reorganize the configuration a bit first.

@djc commented on GitHub (Jul 9, 2024): That sounds about right! On your options: 1. Mutable nested accessors: I think this would be a straightforward improvement on the current state 2. Top-level mutators: this doesn't feel like a great idea, because it would more tightly couple all of the configuration types and create a sprawl of configuration API; your example of having a `set_bind_addr()` that implicitly updates all `NameSserverConfig` also feels a little too magic 3. Less nesting: I think that might be a good idea? To me the more obvious API would have `ResolverOpts` be part of `ResolverConfig` (perhaps by flattening it) and maybe also dissolve the `NameServerConfigGroup` type. Another aspect here is how we configure TLS, which might also want some refactoring (you can find earlier issues/PRs from @daxpedda about this -- for example, it would be nice to get rid of the static TLS configs). 4. Builder pattern: could potentially make sense, but I think we should probably reorganize the configuration a bit first.

kerem referenced this issue

2026-03-16 02:25:28 +03:00

[PR #912] [MERGED] switch default Rust back to stable, add min version check #1788