DNS Firewall vs Traditional Firewall: Key Differences

Most organisations already run a network firewall, often a next-generation firewall (NGFW) at the perimeter and in the data centre. So when a DNS firewall is proposed, the first question is usually: don't we already have one of those?

The short answer is no. A DNS firewall and a traditional firewall share a name but work at different layers, see different information and make their decisions at different moments. Understanding those differences shows why they complement each other rather than compete.

What a traditional firewall does

A traditional firewall controls network traffic. It inspects packets and sessions and decides whether to allow them based on source and destination IP addresses, ports and protocols. Stateful firewalls track connections; next-generation firewalls add application identification, intrusion prevention and, where certificates and policy allow, decryption of TLS traffic for deeper inspection.

The firewall acts on a connection that is already being attempted. By the time it sees a packet, the device has already decided where to connect and has looked up that destination.

What a DNS firewall does

A DNS firewall works one step earlier. It sits in the DNS resolution path, usually as the recursive resolver your users and devices query, and checks every requested domain against threat intelligence and your policy before returning an answer.

If the domain is malicious or not allowed, the DNS firewall does not return the real address. Depending on policy it answers that the domain does not exist (NXDOMAIN), returns an empty answer (NODATA), or redirects the user to a warning page. Without an address, the connection never starts. Most DNS firewalls use Response Policy Zones (RPZ), an industry-standard format for distributing these block and allow rules.

Key differences at a glance

• Layer: a network firewall inspects packets and sessions; a DNS firewall inspects domain-name lookups.
• Timing: a network firewall acts when a connection is attempted; a DNS firewall acts before the connection, at the moment the destination is looked up.
• What it sees: a network firewall mainly sees IP addresses and ports; a DNS firewall sees the domain name, which carries far more meaning about intent and reputation.
• Encrypted traffic: a network firewall needs TLS decryption to see much of modern traffic; a DNS firewall decides on the name, without decrypting anything.
• Coverage off the network: a perimeter firewall protects traffic that passes through it; a DNS firewall can also protect roaming laptops through a lightweight endpoint agent.
• Signal for the SOC: DNS logs show exactly which device asked for which domain, often the earliest sign of an infection.
• Effort: a DNS firewall is light to deploy because it changes where devices send their DNS queries rather than sitting inline for every packet.

What a DNS firewall catches that IP rules miss

Attackers change IP addresses far more easily than they change their operating model, and many malicious sites share IP addresses with legitimate ones on cloud platforms and content delivery networks. Decisions based on the domain name are often more precise:

• Newly registered and look-alike domains used for phishing, often blocked by category before any blocklist names them.
• Fast-flux infrastructure, where one malicious domain rotates through many IP addresses.
• Domain generation algorithms (DGAs) that create thousands of throwaway command-and-control domains.
• DNS tunnelling, where data is hidden inside DNS queries themselves and never appears as a normal connection.
• Malicious content hosted on shared IP addresses, where blocking the IP would also block legitimate services.

Where a DNS firewall needs help

A DNS firewall is not a replacement for a network firewall. It cannot stop traffic that never uses DNS, such as malware that connects straight to a hard-coded IP address. It can also be bypassed if devices are free to use a different resolver, for example a public DNS over HTTPS service built into a browser. And it does not inspect the content of an allowed connection. Those gaps are exactly where the network firewall is strong.

Using them together

The strongest designs make the two controls reinforce each other:

• Use the network firewall to force all DNS through the DNS firewall: allow outbound DNS (port 53) and DNS over TLS (port 853) only to your approved resolvers, and block known public DNS over HTTPS endpoints.
• Let the DNS firewall stop the bulk of malicious destinations early, which reduces the load and the noise on the network firewall.
• Share intelligence in both directions: export DNS firewall threat feeds in RPZ format to other resolvers you run, and feed firewall findings back into DNS policy.
• Correlate DNS logs and firewall logs in your SIEM to see the full chain, from the lookup to the connection attempt.

Where DNS Armor Protect™ fits

DNS Armor Protect™ is a DNS firewall built in the GCC. Each query is evaluated against the security policy for its source: built-in threat, web-filter, application and geo feeds; machine-learning detection of DNS tunnelling; your own local rulesets for domain, IP and PTR matches; and any external RPZ feeds you subscribe to. Policies can run on a schedule, for example a stricter posture after hours.

It runs cloud-delivered, on-premises through the Local Resolver virtual appliance, or on roaming devices through the Endpoint Agent. Your feeds can be exported in RPZ format to BIND, Infoblox and other resolvers, and the Logs Connector streams DNS events to Sentinel, Splunk, QRadar, Elastic or ArcSight, so the DNS firewall and the network firewall can be read side by side.