Repository navigation
Conversation
The socks subcommand resolves exit-node destination hostnames with the
local resolver and only sends the resulting IP through the tunnel.
That doesn't work well when the client and the exit node see different
DNS:
- Names that exist only on the exit node's network (intranet or VPN
split-DNS names) can't be resolved at all from the client side.
- On hosts whose resolver answers every name with a fake IP for a
transparent proxy (common in sandboxes and some corporate
networks), the proxy dials the fake IP through the exit node,
where it means nothing.
Add a --dns flag (with a TAILCAT_SOCKS_DNS environment variable
default, like --derpmap-url's TAILCAT_DERPMAP_URL) listing DNS servers
to resolve those hostnames with instead. The servers are queried with
Go's resolver over TCP connections made with the client's DialTCP, so
the queries travel through the exit node and names resolve as they do
on its network. The servers are tried in order, each bounded by a
4-second timeout so a dead server leaves time in the SOCKS dial budget
to fall back to the next; a definitive NXDOMAIN is returned without
asking the rest. The local hosts file still applies first, and the
RFC 6761 localhost names always resolve to loopback. Errors name the
server actually queried rather than the local resolv.conf one.
--dns requires a <tc-addr> argument, and a bad value is a usage error
reported before connecting. Without the flag, hostnames resolve
locally exactly as before.
Signed-off-by: imcom <jinyu.bjut@gmail.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The socks subcommand resolves exit-node destination hostnames with the local resolver and only sends the resulting IP through the tunnel. That doesn't work well when the client and the exit node see different DNS:
Add a --dns flag (with a TAILCAT_SOCKS_DNS environment variable default, like --derpmap-url's TAILCAT_DERPMAP_URL) listing DNS servers to resolve those hostnames with instead. The servers are queried with Go's resolver over TCP connections made with the client's DialTCP, so the queries travel through the exit node and names resolve as they do on its network. The servers are tried in order, each bounded by a 4-second timeout so a dead server leaves time in the SOCKS dial budget to fall back to the next; a definitive NXDOMAIN is returned without asking the rest. The local hosts file still applies first, and the RFC 6761 localhost names always resolve to loopback. Errors name the server actually queried rather than the local resolv.conf one.
--dns requires a argument, and a bad value is a usage error reported before connecting. Without the flag, hostnames resolve locally exactly as before.