DNS Resolve Failures Blocking Bitmern Solo

DNS Resolve Failures Blocking Bitmern Solo

The stratum string looks perfect — host, port, WALLET.worker, password x — but the board never connects. Firmware logs scream “cannot resolve host,” “host not found,” or a stale IP that never answers. That is not an outbound firewall deny (TCP can be open once DNS works), and it is not a typo in the URL fields you already triple-checked.

If your Bitaxe or home ASIC will not show accepts on Bitmern Solo because the coin hostname will not resolve (or resolves to a dead cached address), run an ordered DNS checklist: confirm the stratum string is already correct, flush or renew DNS on the path the miner uses, try an alternate LAN resolver without inventing a product DNS requirement, verify btc.bitmernsolo.com (and other per-coin hosts) resolve from the same LAN, then prove the first accepts on the matching coin tab. BTC easy-start uses :3132 — never treat :3102 as the Bitaxe / home default. Username WALLET.worker, password exactly x. This post does not invent Bitmern Solo DNS product features or mandate a specific public DNS brand.

This is the DNS / hostname-resolve path. Outbound TCP blocked after the name resolves: firewall blocking stratum. Wrong host / https paste / port typo: stratum URL mistakes. Session connects then flaps: reconnect loops fix. Link type vs radio noise: Ethernet vs Wi-Fi. Field wiring: connect ASIC.

Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Fee context stays light here — the job is making the hostname resolve so the board can open stratum.

DNS fail ≠ firewall ≠ wrong URL ≠ reconnect loops

Four patterns get mixed up:

1. DNS resolve failure — hostname never resolves, resolves to nothing useful, or a bad cache points at a dead IP. Stratum string can look correct in the UI; the board never lands a session. That is this post.
2. Outbound firewall / path block — name resolves; TCP to host:port is denied or filtered. Use firewall blocking stratum.
3. Wrong stratum URL — https paste, wrong coin host, :3102 treated as home default, trailing slash, typo domain. Use stratum URL mistakes.
4. Reconnect loops — host/port already correct; session connects, drops, reconnects. That is reconnect loops.

Do not invent a Bitmern Solo “DNS product,” a required public resolver, or a claim that the pool “always uses this DNS.” The product facts that matter: per-coin hosts (for BTC, btc.bitmernsolo.com), BTC easy-start :3132, username WALLET.worker, password x.

What usually looks like “pool down” when DNS is the culprit

Common resolve failures on Bitaxe-class and small ASIC desks:

1. Broken LAN resolver — router DNS stuck, ISP resolver flaky, or Pi-hole / ad-block list swallowing mining hostnames by accident.
2. Stale negative cache — a failed lookup was cached; the board keeps “host not found” long after upstream DNS is fine.
3. Guest Wi-Fi / isolated DNS — board associates; DNS queries never leave the guest VLAN cleanly (often paired with path issues — also check Ethernet vs Wi-Fi and firewall blocking stratum).
4. Bridge PC / USB Ethernet with different DNS — laptop browser resolves bitmernsolo.com; the miner’s DHCP DNS does not.
5. Typo that looks like DNS — btc.bitmernsolo.co vs .com, extra spaces, unicode lookalikes — treat as stratum URL mistakes first, then return here if the correct host still fails to resolve.
6. VPN / proxy DNS hijack — tunnel forces a resolver that cannot see the coin host (see tomorrow’s VPN angle or disable the tunnel while diagnosing).

Separate these from outbound TCP deny after a good resolve (firewall blocking stratum) and from flaps after a known-good connect (reconnect loops).

Ordered fix checklist

Run top to bottom. Stop when the matching coin tab shows the worker under the expected label, fresh accepts move, and firmware is no longer stuck on “cannot resolve.”

1. Confirm the stratum string is already correct

Symptom: You have never verified host/port/user/pass; “DNS” is a guess.

Action: First pass stratum URL mistakes. For BTC easy-start:

stratum+tcp://btc.bitmernsolo.com:3132
WALLET.worker
password: x

Never treat :3102 as the Bitaxe / home default. Host must match the coin (btc.bitmernsolo.com for BTC; other coins use their matching per-coin hosts). Only after the string is clean do you treat empty accepts as a resolve / path problem.

2. Open the matching coin tab before you blame DNS

Symptom: You watch LTC (or another coin) while the board points at BTC — or the reverse — and conclude “DNS” or “pool down.”

Fix: Open the same coin the miner is pointed at. A BTC-pointed board will not populate LTC worker cards.

3. Prove the hostname resolves from the same LAN

Symptom: Firmware logs “cannot resolve” / “host not found”; browser on another device still opens the marketing site.

Fix: From a laptop on the same LAN (and preferably the same SSID / VLAN) as the miner, resolve the exact coin hostname the board uses — for BTC, btc.bitmernsolo.com. Exact tools vary by OS (nslookup, dig, Resolve-DnsName, etc.). The point is: “does this LAN return usable A/AAAA records for the stratum host?” If the laptop also cannot resolve it, the failure is upstream of the Bitaxe (router DNS, filtered guest DNS, or a broken resolver), not a bad wallet string.

Do not invent a Bitmern Solo product requirement for a specific diagnostic tool or a guaranteed DNS SLA.

4. Flush / renew DNS on the path the miner uses

Symptom: Hostname worked yesterday; today every lookup fails or returns a stale dead IP; other sites still load.

Fix: Renew DHCP on the miner (or power-cycle so it re-requests DNS). Flush DNS cache on any bridge PC or router that sits in the path. Re-apply pool settings after renew. Re-check resolve from the same LAN, then watch firmware logs for a clean connect instead of “host not found.”

5. Try an alternate LAN resolver (without inventing a product DNS rule)

Symptom: Router / ISP resolver is flaky; Pi-hole or local filter lists intermittently NXDOMAIN mining hosts; same board works on another upstream.

Fix: Point the LAN (or the miner’s DHCP options, if your firmware exposes them) at a known-working resolver you control or trust on that network — then retest. This guide does not invent a Bitmern Solo requirement to use a named public DNS brand, and it does not claim any public DNS is “official.” The ops goal is a resolver that returns the real coin host addresses.

If guest isolation or outbound filters are also in play, clear those with firewall blocking stratum in parallel.

6. Rule out VPN / proxy DNS hijack while diagnosing

Symptom: Resolve fails only when a VPN or proxy is up on the router, bridge PC, or “always-on” tunnel; works when the tunnel is off.

Fix: Disable the VPN/proxy on the path the miner uses, renew DNS, and retest. Do not invent Bitmern Solo “VPN-compatible” product claims. If the tunnel is required elsewhere, split the miner onto a path that can resolve and open stratum cleanly (details in the VPN/proxy post once live).

7. Username and password shape (still required)

Required:

WALLET.worker
password: x

Traps that scramble attribution while you chase “DNS”: missing dot, spaces, wrong wallet prefix vs the registered receive address, password not exactly x, or watching the wrong worker suffix.

Field wiring: connect ASIC. AxeOS fields: AxeOS setup.

8. Primary slot only while diagnosing

Symptom: Primary points at Bitmern Solo; secondary still points at an old pool; Bitmern Solo never sees steady work after DNS is fixed.

Fix: Put Bitmern Solo on the primary (or only) pool slot. Clear or disable failover slots that point elsewhere while you diagnose. Host must match the coin. Save and apply. Flaps after DNS and path are open: reconnect loops.

9. Prove outbound TCP after resolve works

Symptom: Hostname now resolves; accepts still empty; logs show connect timeout instead of “host not found.”

Fix: You left the DNS lane. Continue with firewall blocking stratum — prove outbound TCP to btc.bitmernsolo.com:3132 (or your coin’s host:port) from the same LAN.

10. Prove first accepts on the Bitmern Solo dashboard

Open the matching coin tab. Confirm:

• Worker row present under the expected WALLET.worker label
• Fresh accepts moving (not stuck empty)
• Hashrate reading believable while the board hashes
• Current Effort leaving a stuck empty reading when attribution works

Card reading stays in the dashboard guide. Here you only verify DNS + connect landed work on the account.

When firewall, wrong URL, reconnect loops, or Wi-Fi is the real story

If the name resolves and TCP is denied, switch to firewall blocking stratum. If host/port/user/pass were never validated, use stratum URL mistakes. If the session connects then flaps, use reconnect loops. If TCP sometimes works but radio is noisy, use Ethernet vs Wi-Fi. First-time fields: connect ASIC.

What this post will not invent

• No Bitmern Solo “DNS product features” or required public DNS brand
• No claim that :3102 is the home Bitaxe default (easy-start is :3132)
• No ISP DNS SLA, “always use this resolver,” or “first accept within N seconds” promise
• No luck formulas, dollar EV, or find-time promises from a successful resolve
• No competitor fee comparisons

Fee reminder only if you need it: flat 1% on finds; you keep 99%. A working DNS path is an ops signal, not a fee.

Soft next step

Lock a correct stratum string (btc.bitmernsolo.com:3132 for BTC easy-start, WALLET.worker / x), make sure the coin hostname resolves on the same LAN as the board, clear stale DNS / broken resolvers, then confirm first accepts on the matching coin tab before you chase deeper firewall or hardware issues.

Start mining

Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.

FAQ

Is a DNS failure the same as a firewall block?

No. DNS means the hostname never becomes a usable address (or a bad cache points nowhere useful). Firewall means the name resolves but outbound TCP to host:port is denied. Use firewall blocking stratum once resolve works.

What BTC port should a home Bitaxe use first?

:3132 on btc.bitmernsolo.com. Never treat :3102 as the Bitaxe / home default.

What username and password does Bitmern Solo expect?

Username WALLET.worker (wallet prefix must match the registered receive wallet for that coin). Password exactly x.

Does Bitmern Solo require a specific public DNS provider?

This guide does not invent that product claim. Use any resolver on your LAN that correctly returns the coin host addresses. Do not treat a brand endorsement as a product requirement.

Can guest Wi-Fi break DNS even if the password is right?

Yes. Isolated guest SSIDs often break DNS or outbound paths while phones still browse. Move to the primary LAN or Ethernet; also see Ethernet vs Wi-Fi.

Where do reconnect loops fit?

If the hostname resolves, TCP opens, and the session connects then flaps, use reconnect loops.

Where do I confirm the fix on Bitmern Solo?

Matching coin tab → worker row → fresh accepts → believable hashrate. Guide: dashboard workers / shares / effort.