Ping 60 and ping‑restart 180 are a good fit for this Unbound‑over‑VPN setup because they match your DNS timing and Unbound’s tolerance for upstream “hiccups” while keeping the tunnel stable.
infra-cache-min-rtt: 60
Unbound treats anything below about 60 ms as “fast”, but this also means it expects some latency and variability from upstream servers. A 60‑second VPN ping interval doesn’t interfere with this; it simply keeps the tunnel alive, while the DNS layer is tuned to tolerate realistic WAN RTTs and short spikes.
infra-cache-max-rtt: 180000
This allows Unbound to keep knowledge about server responsiveness for up to 180 seconds (and beyond, in ms). If your VPN “ping restart” is 180 seconds,
Within that 3‑minute window, Unbound can still consider a server usable and simply see temporary slowness.
After 3 minutes of no replies, the VPN will restart, which aligns with Unbound deciding that path is effectively unusable and trying again over the re‑established tunnel.
Why 60 / 180 works well for DNS over VPN
60‑second ping keeps the tunnel NAT state alive.
Your DNS traffic is not constant; a 60‑second keepalive avoids idle timeouts on home routers/ISPs without wasting bandwidth, so Unbound’s queries do not suddenly fail after short idle periods.
3‑minute restart matches “real” failures, not brief glitches.
Many short WAN or VPN blips last a few seconds to a minute. A 180‑second restart lets Unbound ride out transient issues
serve-expired: yes and serve-expired-ttl: 86400
So clients still get answers from cache while the tunnel is flaky.
outbound-msg-retry: 5 and max-query-restarts: 11
Unbound will retry queries and switch servers before giving up, which fits well inside that 3‑minute restart window.
The combination avoids thrashing.
If ping‑restart were too short (e.g., 30–60 seconds), the tunnel might be torn down and rebuilt repeatedly during a few lost packets, exactly when Unbound is already retrying and serving expired data. 180 seconds gives Unbound time to use its recovery features before the VPN itself is reset.
In practice, that 60‑second keepalive plus 180‑second restart line up with your Unbound timeouts and retry behavior
Short VPN or upstream issues are masked by cache and retries, keeping DNS “smooth” for users.
True, longer‑term failures trigger a tunnel restart around the time Unbound would consider the path bad anyway, avoiding long hangs without causing excessive reconnects.
VPNs often impose MTU limits (e.g., 1400-1450 bytes post-encryption), causing packet fragmentation or blackholing for oversized DNSSEC-validated responses. Your tcp-mss: 1200 and outgoing-tcp-mss: 1150 pair with EDNS to clamp sizes, favoring UDP where possible (do-udp: yes) but falling back to TCP seamlessly (incoming-num-tcp: 950). Paired with pad-responses and pad-queries, it mitigates padding-oracle attacks and ensures consistent VPN tunnel performance without leaks.
EDNS (Extension Mechanisms for DNS) extends traditional DNS protocol limits, allowing bigger packets for DNSSEC signatures and other data without fragmentation. In your config, edns-buffer-size: 1200 caps outgoing queries conservatively to reduce drops on MTU-sensitive VPN tunnels (common with WireGuard/OpenVPN overhead), while max-udp-size: 2505 handles larger inbound responses from authoritative servers. This prevents truncation issues where standard 512-byte DNS UDP fails under load.
