I think I tracked it down. The SRV query appears to belong to the repository agent (pfSense-repoc). It's trying to find the closest or most available update mirror. I ran the following: pkg -d update The results showed pfSense stuck in a loop checking for system updates. Netgate's repository servers (pfsense-plus-pkg01 and pkg00) were actively rejecting your firewall's built-in client certificate at the application layer, throwing an HTTP 400 Bad Request. Because of this failure, the pkg tool mistakenly attempted to resume partial downloads using bad byte ranges, causing it to endlessly cycle between mirrors and throw erratic errors. Additionally, this update routine caused the firewall to query netgate.com as a relative name, resulting in the netgate.com.foo.org that I saw in the BIND logs. I resolved this as follows: rm -rf /var/db/pkg/repos/* Wipe out the corrupted metadata cache and clear the broken partial download states that were driving the infinite loop. pfSense-upgrade -cc Clean the internal upgrade utility cache. This forced the firewall to dump the stale SSL session tokens and request a fresh mutual TLS (mTLS) authentication challenge from Netgate's registration backend. -- Best regards

@Gertjan Pfsense has the ability in theory to be the first firewall to compartmentalize docker os signatures apart from the host machines and actually control traffic in that manner:) wouldn't that be cool? Again, invasive nation state actors only attack walls at their weakest areas.