Bitaxe – DNS Resolution Failed for Pool Hostname

Hardcode the pool IPv4 into the Stratum URL field as a diagnostic test. From a desktop on the same LAN, run `nslookup public-pool.io` (or your pool's hostname). Copy the IPv4 from the `Address:` line. In AxeOS at `http://<bitaxe-ip>/`, replace the hostname with the bare IPv4 (no `stratum+tcp://` prefix, no port appended — just `172.81.181.23`). Save. Cold power-cycle the Bitaxe for 30 full seconds. If shares land within 5 minutes, DNS is confirmed as the root cause. Move on to Tier 2 for a permanent fix.

Cold power-cycle the Bitaxe for 30 full seconds — pull the barrel jack or XT30, wait 30 seconds for capacitors to drain and the LWIP DNS cache to fully clear, then reconnect. Five seconds is not enough; the LWIP DNS table state persists in SRAM longer than expected. This single step fixes the 'DNS cache wedged after a router reboot' pattern that bites operators who restart network gear without restarting the Bitaxe.

Verify the pool hostname spelling and TLD letter-by-letter. Common typos: `public-pool.io` vs `publicpool.io`, `solo.ckpool.org` vs `solockpool.org`, `pool.braiins.com` vs `pool.braiins.io`. The AxeOS field does not validate the hostname before saving — a single wrong character produces NXDOMAIN every time.

Remove any `stratum+tcp://` prefix from the AxeOS Stratum URL field. AxeOS expects the bare hostname — `public-pool.io`, not `stratum+tcp://public-pool.io:21496`. The prefix is parsed as part of the hostname, DNS resolution fails on `stratum+tcp:`, and the symptom looks identical to a real DNS failure. The single most common operator error on first setup at D-Central's bench.

Switch to a known-good public pool as a sanity check. Temporarily change the Stratum URL to `public-pool.io` with port `21496`, no SSL, and a worker name `<your-btc-address>.bitaxe`. Public-Pool is permissive and DNS-clean. Cold-cycle the miner. If shares land at Public-Pool but not at your original pool, the issue is your specific pool's DNS or stratum endpoint, not the Bitaxe.

Change router DNS to Cloudflare (`1.1.1.1` and `1.0.0.1`) or Quad9 (`9.9.9.9` and `149.112.112.112`). Log into your router admin (typically `http://192.168.1.1`). Find DNS settings under WAN, Internet, or Network. Replace ISP defaults with Cloudflare or Quad9 primary + secondary. Save. Reboot the router, then cold-cycle the Bitaxe so it picks up the new DNS via DHCP. ISP DNS is the single most common cause of intermittent Bitaxe DNS failures.

Disable DNS-rebinding protection on the router or allow-list the pool hostname. Many consumer routers (UniFi, ASUS, Netgear, eero, OPNsense, pfSense) silently filter DNS responses where a public hostname resolves to an RFC1918 IP — which some pools do during failover. Find the setting under Security or Firewall. Either disable globally or allow-list your pool's hostname. Pi-hole / AdGuard / NextDNS users: check block lists for 'crypto,' 'mining,' or 'P2P' categories — disable or exempt the pool hostname.

Set a DHCP reservation for the Bitaxe with explicit DNS servers pushed in the reservation. Find the Bitaxe MAC in the router's DHCP table. Reserve a fixed IP and, in advanced DHCP options, push specific DNS servers (Cloudflare, Quad9) directly to that reservation. Bypasses any ISP-gateway-level DNS hijacking and ensures the Bitaxe always lands on the same IP — useful for monitoring scripts.

Verify with `nslookup` from the same LAN both before and after the router DNS change. Run `nslookup <pool-hostname> 192.168.1.1` (your router) and compare against `nslookup <pool-hostname> 1.1.1.1` (Cloudflare direct). If the router returns a different IP than Cloudflare, the router is rewriting DNS — fix the router config or bypass it via the DHCP-reservation push from step 8.

Check WiFi signal strength at the Bitaxe location. Flaky WiFi looks identical to DNS failure — DHCP gets a lease, the OLED shows an IP, but UDP DNS packets get lost in transit and `lwip_getaddrinfo` retries until it gives up. Check RSSI on the AxeOS dashboard — anything weaker than `-65 dBm` means relocate the Bitaxe closer to the AP, drop a 2.4 GHz repeater, or run Ethernet via a USB-Ethernet dongle (where supported). The ESP32-S3 is 2.4 GHz only — force a dedicated 2.4 GHz SSID if your AP is band-steering.

Reflash the latest stable AxeOS via the USB-C web-flasher at `https://bitaxeorg.github.io/bitaxe-web-flasher/`. Connect a USB-C **data** cable (charge-only cables will not enumerate) to a Chrome or Edge browser. Choose 'Erase Flash' before reflashing to wipe NVS and any wedged LWIP DNS state. Select the correct `.bin` for your chip variant: `BM1366` = Ultra, `BM1368` = Supra, `BM1370` = Gamma and GT, `BM1397` = Max. Hex / UltraHex use the `ESP-Miner-multichip` fork. Wrong `.bin` bricks the board.

Capture a serial boot log at `115200 baud`. USB-C data cable, serial terminal (PuTTY on Windows, `screen /dev/ttyACM0 115200` on Linux/macOS, Arduino Serial Monitor cross-platform). Reboot the Bitaxe. Save the first 60 seconds of output. Search for these lines: `wifi: connected`, `sntp:`, `lwip_getaddrinfo:`, `stratum_api:`. The error code on `lwip_getaddrinfo` tells you the failure class: `1` = no such host (NXDOMAIN), `11` = would-block / retry timeout (DNS too slow), `4` = name truncated (typo or buffer issue). Cross-reference Espressif's LWIP API docs.

Run a stratum proxy on your LAN to take public DNS out of the Bitaxe's path entirely. Options: `stratum-mining-proxy`, `cgminer --proxy`, or a Raspberry Pi running [public-pool's docker image](https://github.com/benjamin-wilson/public-pool). Point the Bitaxe at the proxy's bare IPv4. The proxy resolves the upstream pool hostname using the host OS's resolver (full IPv6 support, larger cache, proper retry logic), then forwards stratum to the Bitaxe over a bare-IP socket. If shares land via the proxy but not direct, the issue is 100% the Bitaxe's LWIP DNS resolver, not the pool, not credentials.

Test for IPv6-only AAAA records and force IPv4 at the resolver. Run `dig <pool-hostname> A @1.1.1.1` and compare to `dig <pool-hostname> AAAA @1.1.1.1`. If only AAAA returns answers, the hostname is genuinely IPv6-only on that path and the Bitaxe (no IPv6 in shipping firmware) cannot reach it. Two fixes: (a) hardcode an IPv4 found via Cloudflare's resolver, (b) use a different stratum endpoint from the same pool that has an A record. Most pools publish multiple endpoints — check the pool's connection page.

Audit your DNS-blocking layer for over-blocking. Pi-hole admin → Query Log; AdGuard Home → Filtering → Logs; NextDNS → Logs. Search for the pool hostname. If it shows blocked (red), check which list flagged it. Common offenders: 'crypto' categories on NextDNS, 'mining' subsections of OISD or hagezi blocklists. Allow-list the pool hostname explicitly. Also check for wildcard rules (`*.io`, `*.tech`) in custom block lists that might catch legitimate pools.

Stop DIY and contact D-Central support when (a) you have reflashed the latest stable AxeOS twice with 'Erase Flash' between attempts, hardcoded the pool IP, and switched router DNS to Cloudflare, and DNS still fails; (b) the serial log shows `lwip_getaddrinfo` errors even when AxeOS contains a hardcoded IPv4 (impossible mode pointing at corrupted flash or LWIP regression); (c) multiple Bitaxe units on the same network all fail DNS simultaneously while desktops resolve cleanly. The D-Central Bitaxe Troubleshooting Guide and Discord are the right escalation channels.

What D-Central does at this point: bench-side reproduction with identical Bitaxe variant, identical AxeOS build, controlled network with known-good DNS, full serial trace with optional `CONFIG_LWIP_DEBUG` build. If we reproduce the failure, we file a GitHub issue against bitaxeorg/ESP-Miner with the trace and a reproducer. D-Central is a regular contributor to the ESP-Miner project — maintainers triage our reports quickly because they come with hardware-grade reproduction notes.

Ship to D-Central if you want bench-grade diagnosis. Anti-static bag, double-box with 3 cm+ foam every side. Include a note: Bitaxe variant, AxeOS firmware version, pool hostname, screenshot of the AxeOS Stratum config, your router make/model, and what you have already tried. We test on a controlled bench network, isolate firmware-vs-network-vs-hardware, return with a full report. Most 'DNS-fail' tickets close without hardware repair because the issue is upstream — but bench reproduction proves it definitively. Turnaround typically 3–7 business days for diagnostic-only tickets.