Intermittent DDNS failures silently broke MCP tool visibility for AI sessions
QuoLu traced months of mysterious "Tool Not Found" errors in Claude and ChatGPT to intermittent DDNS resolution failures on dynv6.net, which caused MCP tools to silently disappear at session start, and resolved the issue by migrating to Cloudflare Tunnel.
Score breakdown
Intermittent DNS failures — previously a minor human annoyance fixed by a page reload — become session-level outages for AI agents, because a single failed lookup at session start permanently removes the tool from the agent's context for that entire conversation.
- 01Intermittent DDNS failures on dynv6.net caused `dig` to return NXDOMAIN or SERVFAIL before resolving normally minutes later.
- 02AI sessions resolve the MCP server hostname, perform a TLS handshake, and fetch the tool list at startup — a single DNS failure at that moment makes the tool invisible for the entire session.
- 03The server logs showed no crashes, and sometimes no connection attempt was logged on the client side, making the cause invisible.
QuoLu describes a months-long debugging mystery: Claude and ChatGPT would intermittently report that MCP tools "cannot be found," yet the home server appeared healthy — the app was running, the port was listening, and health checks were passing. Restarting the AI session would fix the problem temporarily, making the failure easy to dismiss. The key insight is that AI sessions are fundamentally different from human browser interactions: when a session begins, the AI resolves the server's hostname, completes a TLS handshake, fetches the tool list, and loads it into context — all in one shot. If any step fails, the tool is invisible for the entire session with no visible error on the server side, and sometimes no connection attempt logged on the client side either.
After ruling out the network, TLS, and the server itself, QuoLu turned to DNS.
After ruling out the network, TLS, and the server itself, QuoLu turned to DNS. Because the home server lacks a static IP, it relied on DDNS via dynv6.net. Occasional `dig` queries were returning NXDOMAIN or SERVFAIL — possibly due to provider-side issues, upstream cache problems, or rate limiting — before resolving normally minutes later. These transient failures aligned perfectly with AI session boundaries, causing tools to silently vanish.
The fix was migrating to Cloudflare Tunnel, which establishes a permanent outbound connection from the home server to the Cloudflare edge. The server's name is held in Cloudflare DNS rather than DDNS, eliminating the need for a static IP, port forwarding, or DDNS update scripts. Two additional problems were resolved as side effects: the `/etc/hosts` maintenance burden caused by SoftBank's 10G line not supporting hairpin NAT was eliminated (since both internal and external traffic now routes through Cloudflare), and irregular inbound connection blocks that had been a minor annoyance on the SoftBank line also went away.
Key facts
- 01Intermittent DDNS failures on dynv6.net caused `dig` to return NXDOMAIN or SERVFAIL before resolving normally minutes later.
- 02AI sessions resolve the MCP server hostname, perform a TLS handshake, and fetch the tool list at startup — a single DNS failure at that moment makes the tool invisible for the entire session.
- 03The server logs showed no crashes, and sometimes no connection attempt was logged on the client side, making the cause invisible.
- 04The failure pattern had persisted for months and was dismissed because restarting the session temporarily fixed it.
- 05Migrating to Cloudflare Tunnel removed the need for a static IP, port forwarding, and DDNS update scripts.
- 06Cloudflare Tunnel also eliminated the need to maintain `/etc/hosts` entries as a hairpin NAT workaround on SoftBank's 10G line, which does not support hairpin NAT.
- 07Irregular inbound connection blocks on the SoftBank line were also resolved after the migration.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 14, 2026 · 09:08 UTC. How this works →