[GH-ISSUE #1005] Resolver & Client: allow to set bind address or other socket options #587

New issue

Closed

opened 2026-03-15 23:19:35 +03:00 by kerem · 1 comment

kerem commented

2026-03-15 23:19:35 +03:00

Owner

Originally created by @zh-jq on GitHub (Feb 1, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1005

It will be good to bind socket to specific ip address on machines with many ip addresses (may in different ISP) before connect/send to upstream. And it will be useful to be able to set SO_MARK while working with nftable rules.
There is from_std method for tokio UdpSocket and TcpStream which allow us to setup more options. Will it possible for resolver/client to accept functions generate std UdpSocket and TcpStream which can be used by (tokio) from_std?

Originally created by @zh-jq on GitHub (Feb 1, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1005 It will be good to bind socket to specific ip address on machines with many ip addresses (may in different ISP) before connect/send to upstream. And it will be useful to be able to set SO_MARK while working with nftable rules. There is from_std method for tokio UdpSocket and TcpStream which allow us to setup more options. Will it possible for resolver/client to accept functions generate std UdpSocket and TcpStream which can be used by (tokio) from_std?

kerem

2026-03-15 23:19:35 +03:00

closed this issue
added the
enhance

crate:resolver
labels

kerem commented

2026-03-15 23:19:51 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 1, 2020):

This is something that I've wanted to do in the library for quite a while. There are a few options here. One would be to add some ResolverOpts for the SO_MARK, and then maybe add a field to NameServer to express which outbound interface to use, and allow that to be specified on a per NameServer basis. I kinda would prefer that.

The other option would be for you to override the ConnectionProvider interface and provide a custom implementation, and that could be done without upstream changes. You may want to look at the socket2 crate which has a lot of additional methods for configuring sockets. Also, it would be good to make sure that the bind method from Tokio is used, as that is properly Async, which would be better than blocking on bind from a std socket.

@bluejekyll commented on GitHub (Feb 1, 2020): This is something that I've wanted to do in the library for quite a while. There are a few options here. One would be to add some ResolverOpts for the SO_MARK, and then maybe add a field to `NameServer` to express which outbound interface to use, and allow that to be specified on a per NameServer basis. I kinda would prefer that. The other option would be for you to override the `ConnectionProvider` interface and provide a custom implementation, and that could be done without upstream changes. You may want to look at the `socket2` crate which has a lot of additional methods for configuring sockets. Also, it would be good to make sure that the `bind` method from Tokio is used, as that is properly Async, which would be better than blocking on bind from a std socket.

kerem referenced this issue

2026-03-16 02:11:38 +03:00

[PR #587] [MERGED] Matching of CAA Tag value should be done case insensitively #1532