DNS Timeout on Stratum Hostname Resolution
Warning — Should be addressed soon
Symptoms
- Miner dashboard shows `0 accepted / 0 rejected` shares for 10+ minutes despite normal wattage at the wall
- Stratum log contains `DNS_TIMEOUT`, `getaddrinfo failed`, `lwip_getaddrinfo: 1`, `dns query timed out`, or `Temporary failure in name resolution`
- Antminer kern.log shows `cgminer: pool 0 ... DNS error` or `cgminer: dns lookup failed`
- Bitaxe / Nerd AxeOS Logs tab shows `lwip_getaddrinfo: 1` or `lwip_getaddrinfo: 11` paired with `stratum_api: connection failed`
- Whatsminer btminer dashboard shows `Pool dns failed` or `Pool 0 dns error`
- Avalon AUC log shows `pool dns timeout`
- `nslookup pool-host` from a desktop on the same network is slow (>2 s) or returns `;; connection timed out`
- `nslookup pool-host 1.1.1.1` returns instantly with a clean A record — confirming the issue is your default resolver, not the pool's authoritative DNS
- Hardcoding the pool's IPv4 address into the miner's pool URL field makes shares start submitting in <60 seconds
- Daily failure pattern: clean overnight, broken 18:00–23:00 local time (peak ISP DNS load)
- Multiple miners on the same network show identical `DNS_TIMEOUT` simultaneously — points at network-wide resolver, not per-miner config
- `nslookup pool-host` returns only AAAA (IPv6) records and no A (IPv4) record on the miner's network
- Failure started after an ISP modem swap, router firmware update, Pi-hole / AdGuard / NextDNS install, or IPv6 rollout
Step-by-Step Fix
Cold power-cycle the miner — 30 seconds at the breaker, then back on. Clears any wedged resolver cache or stuck stratum-client state. On Bitaxe / NerdAxe / NerdMiner, this also flushes the ESP32 LWIP DNS cache, which is the single most-effective fix for those platforms. Watch the miner status page for five minutes — `accepted` ticking up means you are done.
Restart the home router — 30 seconds unplugged, then back. Resolves stale DNS cache, leaked DHCP state, and the surprisingly-common 'router DNS process crashed after 47 days of uptime' condition. Free fix, frequently effective. If the miner reconnects within two minutes of the router coming back, the router was the culprit.
Change the router's DNS resolver to public servers. Log into router admin (typically `http://192.168.1.1`), find DHCP / DNS settings, set primary `1.1.1.1` (Cloudflare) and secondary `9.9.9.9` (Quad9). Optional alt: Google `8.8.8.8` / `8.8.4.4`. Save, reboot router, reboot miner. ISP DNS resolvers under peak load are the #1 cause of evening `DNS_TIMEOUT`; public resolvers run with sub-`50 ms` global SLAs.
Set DNS directly on the miner where the firmware allows it. Antminer (DCENT_OS / Braiins OS+ / LuxOS), Whatsminer, Bitaxe AxeOS, and recent Avalon all expose a manual DNS field under Network. Set `1.1.1.1` and `9.9.9.9`. Bypasses the router-served DNS entirely and is the cleanest fix on any miner that supports it. Save, reboot, retest.
Configure failover pools with at least one IP-only entry. Pool 1: preferred (hostname). Pool 2: solo backup (`solo.ckpool.org` or `public-pool.io`). Pool 3: hardcoded IP of the preferred pool — `nslookup pool-host` once, copy the A record, paste it into Pool 3's URL field. The miner self-heals when DNS flaps because it falls through to the IP-only entry.
Hardcode the pool's IPv4 address into Pool 1. Take the A record from `nslookup`, replace the hostname in the miner's primary pool URL with the bare IPv4 (e.g. `172.81.181.23` instead of `public-pool.io`). DNS is bypassed. The miner hashes through every DNS storm. Trade-off: if the pool migrates IPs, update manually — re-`nslookup` quarterly. For solo lottery mining where uptime matters more than convenience, this is the correct setup.
Disable IPv6 on the router's WAN side, or on the miner's network config if exposed. On any network where the ISP's IPv6 is half-broken, this kills the AAAA wait that times out the lookup before the A record arrives. Cleanest fix on consumer routers (Eero, ASUS, TP-Link, Netgear) is the WAN-side IPv6 toggle in admin settings. On miners that expose a v4-only toggle (Bitaxe AxeOS recent builds, DCENT_OS), use that. Restart, retest.
Lower router LAN MTU to `1400` if you suspect EDNS0 fragmentation. PPPoE links and tunneled connections under the MTU cap fragment large DNS responses; the fragments drop, the lookup times out. Most consumer routers expose MTU under WAN settings. `1492` for PPPoE, `1400` for tunneled / VPN-fronted, `1500` for native fiber. Save, reboot, recheck.
Add a router-side hosts file entry (DNSmasq / Pi-hole / OPNsense / pfSense). Edit `/etc/hosts` (or local DNS override field in admin UI) with `172.81.181.23 public-pool.io`. Every miner on the LAN now resolves the pool name to the hardcoded IP locally — DNS round-trip eliminated, sub-`5 ms` lookups, zero ISP dependency. Most-elegant network-wide fix and the one D-Central uses on its own bench.
Check for and disable any DNS filters you forgot about. Pi-hole, AdGuard Home, NextDNS, browser-level filters. Pause each, retest. Re-enable only the ones that don't break the miner. NextDNS specifically has a 'cryptocurrency' category that blocks pool hostnames — disable it on the profile your miners use.
Switch firmware where the platform supports it. Antminer: flash DCENT_OS — D-Central's open-source Antminer firmware, with structured stratum log and proper DNS error reporting (alternatives: Braiins OS+, LuxOS, Vnish — all expose better DNS diagnostics than stock Bitmain). Whatsminer: stay on the latest signed btminer build; DCENT_OS coverage for Whatsminer is on D-Central's roadmap but not yet shipping. Bitaxe / Nerd: build ESP-Miner from source with `CONFIG_LWIP_DNS_MAX_SERVERS=3` and verbose stratum logging — lets you see exactly which DNS server LWIP is querying and whether responses are getting cached.
Run a Wireshark / tcpdump capture during the failure window. Filter `port 53` for DNS and `tcp.port == 3333` (or your pool's port) for stratum. Capture 30 minutes during typical failure time. In Wireshark, filter `dns.flags.rcode != 0` to surface every error response, and check whether queries for your pool hostname have matching responses. If queries appear with no responses, you are losing packets upstream of your router.
Build a dedicated DNS forwarder on a Raspberry Pi. Install Unbound or `dnsmasq`, configure it to query Cloudflare / Quad9 directly over DoT (DNS-over-TLS), point your router's DHCP to serve that Pi as the LAN DNS. You now have a sub-`5 ms` cached recursive resolver on your network that is immune to ISP DNS load and DNS hijacking. Total setup time: 30 minutes; ongoing cost: a few watts.
Tune the miner's stratum reconnect timeout where the firmware allows it. DCENT_OS, Braiins OS+, and LuxOS expose configurable retry intervals. Increase the DNS-resolution timeout from the default `3 s` to `8 s`. Buys time for slow legitimate lookups (especially evening ISP DNS) without changing the actual fix — but converts loud `DNS_TIMEOUT` failures into silent slow connects, which can mask the real problem. Use only after the underlying DNS is healthy.
For Bitaxe / Nerd specifically: switch from WiFi to wired Ethernet via the official adapter (Hex / dock variants). ESP32 / ESP-IDF has documented WiFi-reconnect → DNS-cache-corruption bugs (ESP-Miner issue #252 and related). Wired Ethernet eliminates this class of failure entirely. D-Central pioneered the Bitaxe Mesh Stand and the first Bitaxe / Bitaxe Hex heatsinks; the wired-adapter accessory line is a natural extension.
Stop DIY when: every public DNS resolver fails from your network (issue is upstream, not you), packet capture shows queries leaving with no responses returning (ISP-side packet loss), miner-side DNS works on a hotspot from a phone but not on home WiFi (modem / router hardware issue), or `DNS_TIMEOUT` persists after a clean firmware reflash and Tier-3 network changes. At that point you are chasing carrier-grade NAT, ISP-side DNS hijacking the consumer can't see, or a miner NIC / control-board fault. Open a D-Central support ticket at https://d-central.tech/contact/.
D-Central remote / bench process. Remote: walk through your packet capture, ISP DNS test against your hostname, and pool-side endpoint check on a screen-share. Bench: full firmware reflash from clean image, NIC verification (link / negotiation / packet loss against a controlled DNS server), and 24-hour burn-in against a known-good pool before return. Typical turnaround: 3-7 business days remote, 5-10 business days hardware. Canada / US / international.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
