Granular controls and bug fixes for internal DNS

[jmwample]

Changes

• Add controls to allow a configuration change that prevents hickory from using IPv6 nameservers.

  • When IPv6 is disabled, the internal resolver should not use IPv6 resolvers.
  • Using these controls clears the cache of the internal resolver on change

  use nym_http_api_client::dns::{HickoryDnsResolver, HostnameIpLookupStrategy, NameServerIpVersionPolicy};
  
  let mut resolver = HickoryDnsResolver::default();
  
  // Configure the resolver to use only Ipv4 nameservers and to resolve
  // addresses to Ipv4 (A)  records only.
  resolver.set_ipv4_only();
  
  // More explicit controls for setting the nameserver policy for IP version and lookup target
  resolver.set_hostname_ip_version_lookup_strategy(HostnameIpLookupStrategy::A_then_AAAA);
  resolver.set_nameserver_ip_version_strategy(NameServerIpVersionPolicy::Ipv4AndIpv6);

• Add a toggle that allows the order in which the static table is checked to be configured by the downstream user of the library. The behavior of the shared resolver can be modified as well using this control.

  let mut resolver = HickoryDnsResolver::default();
  // tell the resolver to check the static table before using the internal resolver. 
  resolver.set_check_static_fallback_first(true);

• Initialize that static table uesd by the (default) shared resolver properly

Explanations

IPv6

In the VPN client there are settings specifically intended to control how the library interacts with the IPv6 network stack. This is because some platforms do weird things and actually throw errors if IPv6 is used, so preventing the client from attempting IPv6 can be important in some cases.

This is a challenge with the custom DNS resolver as the hickory-resolver crate that we use provides no controls to indicate that an outgoing lookup should use only IPv4 nameservers or only IPv6 (or both).

Also there is an issue of randomness even when IPv6 doesn’t cause explicit problems where the resolver selecting nameservers to do a resolution could select IPv6 nameservers (because they are configured) even when the IPv6 network will be unreachable - i.e. the networking stack supports IPv6 but the device isn’t connection with an IPv6 address.

Static table check

The static lookup fallback added in #6178 checks the configured table after the inner resolver fails, however this has the issue that you will likely already have waited for the timeout making the subsequent use for the addresses also likely to timeout.

We can change this so that the check in the static table is done first, but the static addresses are currently VERY static, and making all clients relient on them not changing in order to access things like the API makes me nervous.

See NET-713 & NET-742

---

This change is 

[jmwample]

Hmmm. Some of the DNS related tests seem either flakey or like they are interleaving in a way that is doing bad things to the shared resolver.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
nym-explorer-v2	Ready	Preview	Comment	Dec 1, 2025 10:00pm

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
docs-nextra	Ignored	Preview		Dec 1, 2025 10:00pm
nym-node-status	Ignored	Preview		Dec 1, 2025 10:00pm

[jmwample]

After changing the default to use IPv4 Only nameservers the errors in the tests run as part of the github actions have gone away. However, I do not fully understand the errors so I can't say for sure that this fixed the issue and that we didn't just get lucky this time.

It seems like when the resolver chooses IPv6 in the tests in the gh action runner it times out instead of returning a network unreachable error. Which then causes other things to time out. which breaks the things I am actually trying to test.

If this is the case though, how did we not run into this issue before?