1
Diagnostic step 1
Enable persistent logging and capture: increase router log level, collect kernel dmesg, and rotate logs to remote syslog host before reproducing failure to preserve crash output (do not share private keys or credentials).
FULL AI ANALYSIS
Clients time out to IPv4-only sites after enabling DNS64/NAT64 on OpenWrt router (intermittent synthesis failures)
Generated Oct 13, 2026, 9:45:52 AM
Analysis summary
Symptoms show the problem occurs at the synthesis/translation layer: AAAA answers are not consistently available and when present, packets to the NAT64 prefix sometimes fail to be translated. Temporary recovery after restarting tayga/dnsmasq and router reboots suggests a resource exhaustion or a transient service crash. Kernel conntrack or nat table exhaustion, tayga crashes due to edge cases (e.g., TCP state collisions), MTU mismatches, or dnsmasq returning incorrect answers under load are all plausible. TLS failures after long stalls suggest broken intermediary state (partial TCP connections) rather than pure DNS.
Possible causes
tayga process crash or memory leak causing intermittent loss of NAT64 translation
90%conntrack table exhaustion on the router causing new flows to be dropped (translation requires conntrack entries)
80%dnsmasq/DNS64 returning no AAAA answers intermittently due to cache corruption or upstream rate-limiting
55%MTU/fragmentation on the synthetic IPv6 path causing TCP connections to stall (PMTUD black hole to NAT64 address range), especially for large TLS handshakes or static MSS settings on clients/ISP path
20%Suggested fixes
2
Diagnostic step 2
Monitor conntrack usage: run watch -n1 'cat /proc/sys/net/netfilter/nf_conntrack_count && cat /proc/sys/net/netfilter/nf_conntrack_max' during normal and failure periods to see if count approaches max; if high, temporarily increase nf_conntrack_max and note effect.
3
Diagnostic step 3
Instrument tayga: run tayga under systemd with Restart=no and use journalctl -f to observe crashes; enable core dumps to a safe location (ensure no sensitive memory is uploaded) and collect process logs for debugging before restarting.
4
Diagnostic step 4
Verify DNS64 behavior: from a client, repeatedly query AAAA for a known IPv4-only host against the router and an upstream public resolver (e.g., 'dig AAAA host @router' and '@1.1.1.1') to see if router is suppressing AAAA answers; compare TTLs and consistency.
5
Diagnostic step 5
Test translation and MTU: from a client, traceroute6 to a synthesized NAT64 address and tcpdump on router to inspect ICMP fragmentation/MTU issues; temporarily set MSS clamp on the router (e.g., via nftables/iptables) to 1220 and re-test large TLS sites to check for PMTUD issues without changing global MTU permanently (reversible).