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 https://github.com/nymtech/nym/pull/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