TCP fallback is not always used and forcing it is not ergonomic about trust-dns HOT 3 CLOSED

This looks like 3 different issues:

The library should fall back to TCP when EINVAL is returned on UDP writes. (This also likely applies to QUIC connections.)

This makes sense to me. Want to send a PR? I think we have some code for fallback already so probably just involves adding io::ErrorKind::InvalidData in a match arm somewhere.

Ideally it would be possible to force TCP with a simple call when configuring the resolver, such as: Resolver::from_system_conf().force_proto(Protocol::Tcp).

I'm not sure this use case is important enough that we'd want to have specific API for it, but we recently discussed in #2188 that mutating the configuration returned from from_system_conf() is generally pretty annoying, so I think we could discuss how we could improve on that.

It would also be nice if the library would let the host OS choose the ephemeral source port. Either by-default for from_system_conf resolvers or it should be easy to enable. It's quite possible that the host OS is configured to allow a range better (or more suitable in some setups) than what the library uses. Source port ranges and usage can also used for fingerprinting, this would reduce the effectiveness of such approaches.

I don't know that we can readily get this information? We use the resolv-conf crate on Linux, and from a quick look it doesn't to yield this information. It otherwise sounds reasonable, though.

from trust-dns.

This looks like 3 different issues:

Possibly 😅

This makes sense to me. Want to send a PR?

I'm unfortunately not familiar enough with Rust to contribute such changes.

I'm not sure this use case is important enough that we'd want to have specific API for it

Fair enough. It would be sufficient if ResolverConfig would have something like get_name_servers, then one could mutate those entries and replace them later with set_name_servers. There's already add_name_server, so those two would likely be generic enough.

I don't know that we can readily get this information?

I don't think there's an OS-agnostic way of getting this information. This shouldn't however be an obstacle in leaving it to the OS, which is not difficult, unless there's a strong need for otherwise.

from trust-dns.

I was just looking at this. First, I'm going to simplify the ResolveError, rather than having it wrap IO errors itself, it will always use the interior ProtoError for that, it simplifies some logic. Second, rather than being specific about the IO error, perhaps we always retry on TCP on any IO error... Thoughts?

I figure any IO error on UDP is worth promoting to TCP. That said, I think the complexity here, and the reason we're getting test failures in the other PR is there might be multiple UDP name servers to try before going to TCP. I'm trying to see if there is a good way to do with this scenario.

from trust-dns.