What is a DNS proxy on a firewall, and why use it instead of pointing clients directly at Google's 8.8.8.8?
A DNS proxy is a DNS server that resolves what it knows locally and forwards everything else to upstream DNS. The firewall makes an ideal DNS proxy because it can answer for internal names (which Google can't) and cache results for everyone behind it. Pointing clients at 8.8.8.8 directly means they can't resolve fileserver.lan.
* Resolve-or-forward: static entries and cache answer locally; only unknown names go upstream. *
The four problems DNS proxy solves:
| Problem | DNS proxy solution |
|---|---|
| Internal names unknown to public DNS | Static entries on the FW (e.g., fileserver.lan → 192.168.100.50) |
| Bandwidth wasted on duplicate queries | Caching: same query answered from local cache |
| Hard to enforce DNS policy | Central control point for blocking/logging DNS |
| External DNS provider can see internal lookups | Internal queries never leave the network |
The cache and forward dance:
Client asks: "Where is www.google.com?"
↓
DNS proxy on FW:
1. Check local static entries: not found
2. Check cache: not found (first time)
3. Forward to upstream (e.g., ISP DNS or 8.8.8.8)
4. Cache the answer
5. Return to client
↓
Client asks again 5 minutes later: "Where is www.google.com?"
↓
DNS proxy: cache hit! Return immediately. (much faster)
Client asks: "Where is fileserver.lan?"
↓
DNS proxy:
1. Check static entries: FOUND → return 192.168.100.50
2. (Never queries Google — it would say "no such domain")
Why you add a static entry for the file server:
"Für interne Geräte können statische Einträge erfasst werden. Anfragen zu diesen Einträgen können von der Firewall selbst beantwortet werden."
Static entries let internal hostnames resolve without running a separate DNS server. For the SMB scenario here, this is enough; larger orgs run dedicated AD DNS or BIND.
The "Inheritance Source" pattern (again, for DNS):
When the FW's upstream DNS comes from DHCP (from the ISP), the proxy can inherit that upstream DNS. This lets DNS queries from internal clients eventually reach the ISP's DNS servers — but the FW intercepts first to handle internal names and cache responses.
Why not just configure clients to query the FW directly without "proxy"?
A DNS proxy is a DNS server, just one that forwards what it doesn't know. The "proxy" terminology emphasizes the forward-and-cache behavior. Functionally identical to running BIND in forwarder mode.
The security angle — DNS as a control plane:
DNS proxies are increasingly used for security policy enforcement:
- Block queries to known malware C2 domains
- Filter ads/trackers (Pi-hole pattern)
- Detect data exfiltration via DNS tunnels
- Log all queries for incident response
Tip: A common misconfiguration: clients are pointed at 8.8.8.8 and the firewall's DNS proxy. Result: the proxy is bypassed for half the queries → no caching benefit, no internal names. Always configure DHCP to push only the firewall's DNS (or use Inheritance Source so the FW itself is the only DNS hop clients know).
Go deeper:
DNS Proxy Overview (Palo Alto PAN-OS) — the canonical docs on the firewall acting as a DNS server: cache → static FQDN entries → forward upstream, exactly the resolve-or-forward dance described above.