Skip to content

feat: add hostname resolution for upstream connections#286

Open
average-gary wants to merge 1 commit intostratum-mining:mainfrom
fossatmara:feat/hostname-in-config
Open

feat: add hostname resolution for upstream connections#286
average-gary wants to merge 1 commit intostratum-mining:mainfrom
fossatmara:feat/hostname-in-config

Conversation

@average-gary
Copy link
Contributor

Add shared async DNS resolution utility (resolve_host, resolve_host_port) in stratum-apps/src/config_helpers/resolve.rs that resolves hostnames at connection time rather than config parse time, enabling DNS changes to be picked up on reconnection.

Updated applications:

  • Translator (tProxy): UpstreamEntry stores raw host string, resolves via resolve_host() before each TcpStream::connect()
  • JD Client: New UpstreamEntry struct replaces (SocketAddr, ...) tuple, both Upstream and JobDeclarator resolve hostnames at connection time
  • Pool/JDC Template Provider: setup_connection uses resolve_host_port() instead of SocketAddr::parse() for the SetupConnection message

All address fields remain backward compatible with IP addresses (fast path parsing, no DNS lookup). Config examples updated with hostname documentation.

Testing in real world:

$ RUST_LOG=info cargo run --release -- -c local-hostname-test.toml
Finished `release` profile [optimized] target(s) in 3.28s
     Running `/Users/garykrause/repos/sv2-apps-hostname/miner-apps/target/release/translator_sv2 -c local-hostname-test.toml`
2026-02-20T19:31:43.525271Z  INFO translator_sv2: Starting Translator Proxy...
2026-02-20T19:31:43.525454Z  INFO translator_sv2: Initializing upstream connection...
2026-02-20T19:31:43.525465Z  INFO translator_sv2: Trying upstream 1 of 1: <redacted>.us-east-2.elb.amazonaws.com:34254
2026-02-20T19:31:43.525496Z  INFO translator_sv2: Connection attempt 1/3...
2026-02-20T19:31:44.527579Z  INFO translator_sv2::sv2::upstream::upstream: Trying to connect to upstream at <redacted>.us-east-2.elb.amazonaws.com:34254
2026-02-20T19:31:44.527591Z  INFO stratum_apps::config_helpers::resolve: Resolving hostname '<redacted>.us-east-2.elb.amazonaws.com' via DNS...
2026-02-20T19:31:44.624279Z  INFO stratum_apps::config_helpers::resolve: Resolved '<redacted>.us-east-2.elb.amazonaws.com' -> <redacted>:34254
2026-02-20T19:31:44.692903Z  INFO translator_sv2::sv2::upstream::upstream: Connected to upstream at <redacted>:34254
2026-02-20T19:31:44.823730Z  INFO translator_sv2::sv2::upstream::common_message_handler: Received: SetupConnectionSuccess(used_version: 2, flags: 0x00000004)
2026-02-20T19:31:44.823754Z  INFO translator_sv2::sv1::sv1_server::sv1_server: Starting SV1 server on 0.0.0.0:34255
2026-02-20T19:31:44.823838Z  INFO translator_sv2::sv1::sv1_server::sv1_server: Translator Proxy: listening on 0.0.0.0:34255
...

@lucasbalieiro
Copy link
Collaborator

lucasbalieiro commented Feb 20, 2026

Nice! I haven't looked at the code in depth. But I think this closes: #89

Add shared async DNS resolution utility (resolve_host, resolve_host_port)
in stratum-apps/src/config_helpers/resolve.rs that resolves hostnames at
connection time rather than config parse time, enabling DNS changes to be
picked up on reconnection.

Updated applications:
- Translator (tProxy): UpstreamEntry stores raw host string, resolves
  via resolve_host() before each TcpStream::connect()
- JD Client: New UpstreamEntry struct replaces (SocketAddr, ...) tuple,
  both Upstream and JobDeclarator resolve hostnames at connection time
- Pool/JDC Template Provider: setup_connection uses resolve_host_port()
  instead of SocketAddr::parse() for the SetupConnection message

All address fields remain backward compatible with IP addresses (fast
path parsing, no DNS lookup). Config examples updated with hostname
documentation.
@average-gary average-gary force-pushed the feat/hostname-in-config branch from cb4bf3e to 1d41811 Compare February 23, 2026 15:52
@lucasbalieiro
Copy link
Collaborator

I have successfully implemented this into the docker setup, to avoid using static IPs, in my first review interactions. It worked well so far.

Still need a more in-depth review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants