TCP fallback is not always used and forcing it is not ergonomic

[TaaviE]

Describe the bug
There are systems that block all outgoing UDP with their firewall. In such cases bind succeeds but sendto on those sockets returns -1 (EINVAL).

This results in a ResolveError { kind: Proto(ProtoError { kind: Io(Os { code: 22, kind: InvalidInput, message: "Invalid argument" }) }) , but the resolver does not fall back to TCP.

To Reproduce
Add ip protocol udp drop to the host's prerouting rules, run one of the examples.

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

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).

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.

System:

• OS: Linux
• Architecture: x86_64
• rustc version: 1.77.2

Version:

• Crate: resolver
• Version: v0.24.1

[djc]

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.

[TaaviE]

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.