DNS for the firewall operator

A firewall is often a DNS server. OPNsense ships with Unbound, a validating recursive resolver. The firewall operator has to understand DNS at three levels: how a recursive query actually flows, how the firewall’s own resolver interacts with upstream servers, and what DNSSEC is and is not.

Recursive resolution in one minute

A client asks its resolver “what is app.example.com?”. The resolver, if it does not already know, walks the DNS hierarchy:

Client → Recursive Resolver (OPNsense Unbound)
              |
              | asks: who is the .com nameserver?
              v
              Root → ".com NS = a.gtld-servers.net"
              |
              | asks a.gtld-servers.net: who is example.com?
              v
              .com NS → "example.com NS = ns1.example.com"
              |
              | asks ns1.example.com: what is app.example.com?
              v
              Authoritative → "app.example.com A 203.0.113.50"
              |
              v
        Recursive Resolver returns 203.0.113.50 to client

The recursive resolver caches every answer for the duration of the record’s TTL. The next client asking for app.example.com within the TTL gets the cached answer.

$ drill app.example.com

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: ...
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; app.example.com.   IN  A
;; ANSWER SECTION:
app.example.com.    300   IN  A   203.0.113.50
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 32 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)

The flags at the top of drill’s output are diagnostic gold:

The ad flag is the one to look for when DNSSEC is enabled — it tells you the chain of trust verified all the way to the root.

DNSSEC: validation, not encryption

DNSSEC does not encrypt DNS. DNSSEC validates DNS: it proves that the answer the resolver returned is the answer the authoritative server published, and that the authoritative server is who it claims to be.

If DNSSEC is enabled on the resolver and the answer does not validate (because the parent zone has not signed the child, or because the answer was tampered with en route), the resolver returns SERVFAIL. It does not return “I think the answer is this but I’m not sure”. DNSSEC is a hard yes or no.

The failure mode to remember: turning on DNSSEC validation breaks zones that are not signed. If a client asks corp.internal (an unsigned internal zone), the resolver may return SERVFAIL even though the zone exists. The safe rollout is to enable DNSSEC validation with a list of trust anchors; OPNsense ships with the root trust anchor preconfigured.

Split-horizon DNS

A common production pattern: hosts on the LAN get a different answer for app.example.com than hosts on the Internet. The LAN gets the private IP (10.0.0.50); the Internet gets the public IP (203.0.113.50).

This is split-horizon DNS. OPNsense’s Unbound supports it via overrides (also called “host overrides”): the operator adds a record that says “for any client asking the firewall, return this address”.

Split-horizon is the alternative to NAT reflection (which OPNsense also supports but with caveats). NAT reflection rewrites the source IP of an internal client so the firewall can DNAT the response back to the same internal host; it is fragile and breaks when the application uses TLS with certificate validation.

DNS for the firewall itself

OPNsense uses DNS for two things: resolving the names it needs to do its job (NTP pool names, plugin update checks, syslog destination names, API calls to cloud services) and serving DNS to clients.

If the firewall cannot resolve DNS, services that need DNS will break. The most common production failure is: the firewall’s upstream DNS server (set under System → Settings → General) is unreachable, and every service that needs DNS retries, slowing the firewall to a crawl.

The mitigation is redundant upstream DNS. Point the firewall at two resolvers (your ISP’s, a public resolver like 1.1.1.1, or both). Unbound will round-robin between them; if one is unreachable, the other serves.

Quick-reference: DNS commands