starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #2197] TCP fallback is not always used and forcing it is not ergonomic #917

New issue

Closed

opened 2026-03-16 00:53:24 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 00:53:24 +03:00

Owner

Originally created by @TaaviE on GitHub (Apr 26, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2197

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

Originally created by @TaaviE on GitHub (Apr 26, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2197 **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

kerem closed this issue

2026-03-16 00:53:29 +03:00

kerem commented

2026-03-16 00:53:35 +03:00

Author

Owner

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

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.

@djc commented on GitHub (Apr 26, 2024): 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.

kerem commented

2026-03-16 00:53:40 +03:00

Author

Owner

@TaaviE commented on GitHub (Apr 26, 2024):

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.

@TaaviE commented on GitHub (Apr 26, 2024): > This looks like 3 different issues: Possibly :sweat_smile: > 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.

kerem commented

2026-03-16 00:53:45 +03:00

Author

Owner

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

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.

@bluejekyll commented on GitHub (May 18, 2024): 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.

kerem referenced this issue

2026-03-16 02:52:36 +03:00

[PR #1026] [MERGED] Cleanup unimplemented for RData parser #1881

kerem referenced this issue

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

[PR #1026] [MERGED] Cleanup unimplemented for RData parser #1890