starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #1335] Ability to call setsockopt on resolver's underlying DNS client #652

New issue

Open

opened 2026-03-15 23:40:36 +03:00 by kerem · 18 comments

kerem commented

2026-03-15 23:40:36 +03:00

Owner

Originally created by @zonyitoo on GitHub (Dec 29, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1335

Is your feature request related to a problem? Please describe.

I was making a proxy server and using trust-dns to resolves remote servers' domain names. To distinguish proxy servers' outbound connections, I set SO_MARK option on sockets.

But there is no way to set SO_MARK on trust-dns-resolver's internal connection, which specifically is:

github.com/bluejekyll/trust-dns@58b9ec9885/crates/resolver/src/name_server/connection_provider.rs (L106-L206)

Without the ability to set SO_MARK or other related options, like SO_BINDTODEVICE, data sent from trust-dns-resolver will cause infinity loops:

CLIENT -> PROXY (trust-dns lookup_ip) -> PROXY (trust-dns lookup_ip) -> ...

Describe the solution you'd like

Provide limited options like SO_MARK, SO_BINDTODEVICE to ResolverOpts
Allow customizing the connecting process without rewrite the whole GenericConnectionProvider.

Describe alternatives you've considered

Copy connection_provider.rs and customize my own version of ConnectionProvider

Originally created by @zonyitoo on GitHub (Dec 29, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1335 **Is your feature request related to a problem? Please describe.** I was making a proxy server and using trust-dns to resolves remote servers' domain names. To distinguish proxy servers' outbound connections, I set `SO_MARK` option on sockets. But there is no way to set `SO_MARK` on trust-dns-resolver's internal connection, which specifically is: https://github.com/bluejekyll/trust-dns/blob/58b9ec98853fd46c50b1bb50195911bd104758b7/crates/resolver/src/name_server/connection_provider.rs#L106-L206 Without the ability to set `SO_MARK` or other related options, like `SO_BINDTODEVICE`, data sent from trust-dns-resolver will cause infinity loops: ``` CLIENT -> PROXY (trust-dns lookup_ip) -> PROXY (trust-dns lookup_ip) -> ... ``` **Describe the solution you'd like** 1. Provide limited options like `SO_MARK`, `SO_BINDTODEVICE` to `ResolverOpts` 2. Allow customizing the connecting process without rewrite the whole `GenericConnectionProvider`. **Describe alternatives you've considered** Copy `connection_provider.rs` and customize my own version of `ConnectionProvider`

kerem added the

enhance

crate:resolver

labels

2026-03-15 23:40:36 +03:00

kerem commented

2026-03-15 23:40:47 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 5, 2021):

I think we could provide a way to register hooks that would give access for this? Maybe we should reconsider the ConnectionProvider interface all together?

@bluejekyll commented on GitHub (Jan 5, 2021): I think we could provide a way to register hooks that would give access for this? Maybe we should reconsider the ConnectionProvider interface all together?

kerem commented

2026-03-15 23:40:52 +03:00

Author

Owner

@zonyitoo commented on GitHub (Jan 5, 2021):

A simple solution, add several member functions for ConnectionProvider

pub trait ConnectionProvider: 'static + Clone + Send + Sync + Unpin {
    /// The handle to the connect for sending DNS requests.
    type Conn: DnsHandle<Error = ResolveError> + Clone + Send + Sync + 'static;

    /// Ths future is responsible for spawning any background tasks as necessary
    type FutureConn: Future<Output = Result<Self::Conn, ResolveError>> + Send + 'static;

    /// The type used to set up timeout futures
    type Time: Time;

    /// UdpSocket
    type Udp: UdpSocket + Send;

    // TcpStream
    type Tcp: Connect;

    /// The returned handle should
    fn new_connection(&self, config: &NameServerConfig, options: &ResolverOpts)
        -> Self::FutureConn;

    /// Create a new UdpSocket
    fn new_udp_connection(&self, config: &NameServerConfig, options: &ResolverOpts) -> Self::Udp;

    /// Create a new TcpSocket
    fn new_tcp_connection(&self, config: &NameServerConfig, options: &ResolverOpts) -> Self::Tcp;

    /// TLS, HTTPS, MDNS, ...
}

It helps because I just only need to copy impl<R> ConnectionProvider for GenericConnectionProvider<R> rather than the whole file.

Some extra options have to be stored in the instance of ConnectionProvider and RuntimeProvider, such as mark, iface, that have to be set before connect() but after bind().

@zonyitoo commented on GitHub (Jan 5, 2021): A simple solution, add several member functions for `ConnectionProvider` ```rust pub trait ConnectionProvider: 'static + Clone + Send + Sync + Unpin { /// The handle to the connect for sending DNS requests. type Conn: DnsHandle<Error = ResolveError> + Clone + Send + Sync + 'static; /// Ths future is responsible for spawning any background tasks as necessary type FutureConn: Future<Output = Result<Self::Conn, ResolveError>> + Send + 'static; /// The type used to set up timeout futures type Time: Time; /// UdpSocket type Udp: UdpSocket + Send; // TcpStream type Tcp: Connect; /// The returned handle should fn new_connection(&self, config: &NameServerConfig, options: &ResolverOpts) -> Self::FutureConn; /// Create a new UdpSocket fn new_udp_connection(&self, config: &NameServerConfig, options: &ResolverOpts) -> Self::Udp; /// Create a new TcpSocket fn new_tcp_connection(&self, config: &NameServerConfig, options: &ResolverOpts) -> Self::Tcp; /// TLS, HTTPS, MDNS, ... } ``` It helps because I just only need to copy `impl<R> ConnectionProvider for GenericConnectionProvider<R>` rather than the whole file. Some extra options have to be stored in the instance of `ConnectionProvider` and `RuntimeProvider`, such as `mark`, `iface`, that have to be set before `connect()` but after `bind()`.

kerem commented

2026-03-15 23:40:57 +03:00

Author

Owner

@djc commented on GitHub (Jan 5, 2021):

I don't really like the ConnectionProvider interface, it feels very complex. What goal was it supposed to solve again?

I would think more about something like r2d2/bb8's ConnectionCustomizer trait:

https://docs.rs/bb8/0.7.0/bb8/trait.CustomizeConnection.html

(Not sure it needs to be async for our intended usage.)

@djc commented on GitHub (Jan 5, 2021): I don't really like the `ConnectionProvider` interface, it feels very complex. What goal was it supposed to solve again? I would think more about something like r2d2/bb8's `ConnectionCustomizer` trait: https://docs.rs/bb8/0.7.0/bb8/trait.CustomizeConnection.html (Not sure it needs to be async for our intended usage.)

kerem commented

2026-03-15 23:41:02 +03:00

Author

Owner

@zonyitoo commented on GitHub (Jan 5, 2021):

CustomizeConnection is good, but on_acquire will not work for SO_MARK and SO_BINDTODEVICE, which have to be called before connect() and after bind().

On the otherhand, for some use cases, a TcpStream have to call bind() on a specific IpAddr before connect() (also works for UdpSocket), which is a platform independent way to specify which interface should be used for sending network packets.

@zonyitoo commented on GitHub (Jan 5, 2021): `CustomizeConnection` is good, but `on_acquire` will not work for `SO_MARK` and `SO_BINDTODEVICE`, which have to be called before `connect()` and after `bind()`. On the otherhand, for some use cases, a `TcpStream` have to call `bind()` on a specific `IpAddr` before `connect()` (also works for `UdpSocket`), which is a platform independent way to specify which interface should be used for sending network packets.

kerem commented

2026-03-15 23:41:07 +03:00

Author

Owner

@djc commented on GitHub (Jan 5, 2021):

Sorry, I didn't mean it that literally. More like:

trait CustomizeConnection {
    fn on_tcp_connect(&self, conn: &mut TcpStream) -> Result<(), Error>;
    fn on_udp_connect(&self, conn: &mut UdpSocket) -> Result<(), Error>;
}

@djc commented on GitHub (Jan 5, 2021): Sorry, I didn't mean it that literally. More like: ```rust trait CustomizeConnection { fn on_tcp_connect(&self, conn: &mut TcpStream) -> Result<(), Error>; fn on_udp_connect(&self, conn: &mut UdpSocket) -> Result<(), Error>; } ```

kerem commented

2026-03-15 23:41:13 +03:00

Author

Owner

@djc commented on GitHub (Jan 5, 2021):

(To make sure we do the right thing, we could have several hooks, e.g. before_bind() or after_connect()?)

@djc commented on GitHub (Jan 5, 2021): (To make sure we do the right thing, we could have several hooks, e.g. `before_bind()` or `after_connect()`?)

kerem commented

2026-03-15 23:41:18 +03:00

Author

Owner

@zonyitoo commented on GitHub (Jan 5, 2021):

For TLS, HTTPS, mDNS, you may need more like before_tls, .... :(

@zonyitoo commented on GitHub (Jan 5, 2021): For TLS, HTTPS, mDNS, you may need more like `before_tls`, .... :(

kerem commented

2026-03-15 23:41:23 +03:00

Author

Owner

@zonyitoo commented on GitHub (Jan 5, 2021):

How about customizing the underlying connection, for example, send queries via an UnixDatagram or UnixStream.

PS: This is not a common use case, just for discussion.

@zonyitoo commented on GitHub (Jan 5, 2021): How about customizing the underlying connection, for example, send queries via an `UnixDatagram` or `UnixStream`. PS: This is not a common use case, just for discussion.

kerem commented

2026-03-15 23:41:28 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 5, 2021):

The explicit goal of ConnectionProvider was to allowed for a completely mocked version to allow for unit testing without establishing io for test scenarios. It allows us to test various situations easier than constructing those scenarios over actual socket based connections.

I’m happy for us to consider it’s replacement/enhancement, but keeping the testability is my primary goal, so however we change it, I want to maintain that feature.

@bluejekyll commented on GitHub (Jan 5, 2021): The explicit goal of `ConnectionProvider` was to allowed for a completely mocked version to allow for unit testing without establishing io for test scenarios. It allows us to test various situations easier than constructing those scenarios over actual socket based connections. I’m happy for us to consider it’s replacement/enhancement, but keeping the testability is my primary goal, so however we change it, I want to maintain that feature.

kerem commented

2026-03-15 23:41:33 +03:00

Author

Owner

@zonyitoo commented on GitHub (Aug 22, 2021):

After half a year I am back here and ping @bluejekyll again about this feature.

I am building a VPN service, which will require all requests sent by this program could be routed properly to its destination interface. I have solved all the other connections except trust-dns-resolver's.

I have tried some ideas on the current source code but it felt so ugly. Do you have any suggestion about how to fulfill this goal?

@zonyitoo commented on GitHub (Aug 22, 2021): After half a year I am back here and ping @bluejekyll again about this feature. I am building a VPN service, which will require all requests sent by this program could be routed properly to its destination interface. I have solved all the other connections except trust-dns-resolver's. I have tried some ideas on the current source code but it felt so ugly. Do you have any suggestion about how to fulfill this goal?

kerem commented

2026-03-15 23:41:38 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 31, 2021):

This is partially addressed in #1586

@bluejekyll commented on GitHub (Dec 31, 2021): This is partially addressed in #1586

kerem commented

2026-03-15 23:41:43 +03:00

Author

Owner

@XOR-op commented on GitHub (Dec 20, 2022):

This is partially addressed in #1586

This fix does not work for Linux, which has a Weak ES Model by default (see here).

@XOR-op commented on GitHub (Dec 20, 2022): > This is partially addressed in #1586 This fix does not work for Linux, which has a Weak ES Model by default (see [here](https://unix.stackexchange.com/questions/258810/linux-source-routing-strong-end-system-model-strong-host-model)).

kerem commented

2026-03-15 23:41:48 +03:00

Author

Owner

@XOR-op commented on GitHub (Mar 5, 2023):

@zonyitoo With the latest commits, this issue should be addressed.

@XOR-op commented on GitHub (Mar 5, 2023): @zonyitoo With the latest commits, this issue should be addressed.

kerem commented

2026-03-15 23:41:53 +03:00

Author

Owner

@zonyitoo commented on GitHub (Mar 5, 2023):

Great! Could you add a sample code in "examples"?

@zonyitoo commented on GitHub (Mar 5, 2023): Great! Could you add a sample code in `"examples"`?

kerem commented

2026-03-15 23:41:58 +03:00

Author

Owner

@XOR-op commented on GitHub (Mar 6, 2023):

Great! Could you add a sample code in "examples"?

You can check out my new PR for more details.

@XOR-op commented on GitHub (Mar 6, 2023): > Great! Could you add a sample code in `"examples"`? You can check out my new PR for more details.

kerem commented

2026-03-15 23:42:03 +03:00

Author

Owner

@zonyitoo commented on GitHub (Mar 6, 2023):

Awesome, looking forward for the next release!

@zonyitoo commented on GitHub (Mar 6, 2023): Awesome, looking forward for the next release!

kerem commented

2026-03-15 23:42:08 +03:00

Author

Owner

@zonyitoo commented on GitHub (Mar 12, 2023):

@bluejekyll When would it be the next release?

@zonyitoo commented on GitHub (Mar 12, 2023): @bluejekyll When would it be the next release?

kerem commented

2026-03-15 23:42:14 +03:00

Author

Owner

@lilydjwg commented on GitHub (Apr 11, 2024):

@bluejekyll bind address is different than bind interface, because interface address changes, especially with IPv6. I can catch the "Cannot assign requested address" error and recreate the client with a new address, but I can't tell the client to bind to a different address for the next connection because it's no longer preferred.

Or am I mistaken? Does hickory-dns do the reconnect thing, or is it me? I'll check.

Update: I now recreate udp clients and only reuse tcp & http2 ones (until they errors). Still I can't get the socket so I have to select an address myself.

@lilydjwg commented on GitHub (Apr 11, 2024): @bluejekyll bind address is different than bind interface, because interface address changes, especially with IPv6. I can catch the "Cannot assign requested address" error and recreate the client with a new address, but I can't tell the client to bind to a different address for the next connection because it's no longer preferred. Or am I mistaken? Does hickory-dns do the reconnect thing, or is it me? I'll check. Update: I now recreate udp clients and only reuse tcp & http2 ones (until they errors). Still I can't get the socket so I have to select an address myself.

kerem referenced this issue

2026-03-16 11:58:19 +03:00

[PR #3278] [MERGED] Get Android's DNS servers #3706