Why Client Facing DNS Firewalls are Critical to Network Security
What if DNS queries went to a CLIENT-facing firewall first? You’d have full knowledge of the query: person, device, context. A big step in network security.
Key takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.The article explains the limitations of traditional internet-facing DNS firewalls and advocates for client-facing DNS firewalls as a more effective security control. It describes how traditional DNS firewalls miss up to 80% of queries due to caching, lack client and device context, and only evaluate single queries against blacklists, which weakens forensics and lateral-movement detection. Deploying DNS firewalls on the client side captures every query (public and private), preserves context for user/device/network-aware policies, and enables least-privilege, pattern-based protections without imposing significant network performance overhead.
Why do traditional DNS firewalls fail to provide full network visibility?
Traditional DNS firewalls are typically deployed at the perimeter and only see DNS queries that recurse out to the internet, so they miss queries answered from caches or internal servers. Because over 80% of queries are cached, a perimeter DNS firewall is blind to the majority of DNS activity. Additionally, these firewalls focus on destination domains and lack client- and device-specific context, which prevents identification of who made a query, where the client is located, and the sequence of queries needed for detecting lateral movement or building forensic timelines.
How does a client-facing DNS firewall improve security compared to an internet-facing DNS firewall?
A client-facing DNS firewall receives queries before they traverse the DMZ or are satisfied by intermediate caches, enabling logging of every client-specific query for both public and private namespaces. With visibility into the source IP, client identity, device type, and query patterns, it supports richer contextual policies such as least-privilege access per user, device, app, or service. This enables proactive blocking, better detection of lateral movement through historical query sequences, and more useful forensic data, while innovations in data capture let these checks occur without imposing significant network performance penalties.
What kinds of policy and operational benefits are enabled by client-side DNS data?
Client-side DNS data enables policies that are aware of client identity, location, and device, allowing administrators to implement least-privilege DNS access based on user, device, application, or service. Operators can create pattern-based rules because they have chronological, client-specific query context, which supports early detection of anomalous behavior and lateral movement. Operationally, comprehensive and formatted DNS logs improve forensic investigations and threat hunting, and with modern capture techniques the client-facing evaluation can occur while leveraging cached records so network performance is not unduly impacted.
Ask any CISO what a perfect world looks like and you’ll no doubt hear, “Full network visibility to secure the enterprise with no possibility of breach.” But we don’t live in a perfect world.
What security professionals really want is real-time data on all network activity: every client, every query, every device, every app and service, every pattern – to prevent breaches from known and unknown threats.
Staggering stats expose the difficult truth about IT security threats in a recent IBM report which pegs the numbers at 206 days to detect a breach and another 50 to contain it. It’s no wonder security professionals seek the promise of ultimate control.
One of the many tools in the arsenal security engineers use to defend the network is a traditional DNS firewall. This approach needs to evolve to thwart the efforts of increasingly sophisticated hackers who know that every successful breach begins with a DNS internet query.
This 5-minute whiteboard session by BlueCat Networks CTO, Andrew Wertkin, on DNS firewalls and innovation in client-facing DNS firewalls, may be the most valuable five minutes you spend to protect your network.
Traditional DNS Firewalls
Traditional DNS firewalls can only do so much to protect the enterprise. Here’s why:
They are only capable of capturing DNS queries that actually recurse out to the internet.
The DNS firewall only sees a query and response from the DNS server, normally in the DMZ, that either forwards to DNS services (google, ISP), or queries public DNS directly. It then compares that query/response against a blacklist of known entities harmful to the organization. Policies that may be in place only block queries already identified as unacceptable.
Nothing more.
IT security professionals readily admit the shortfalls of traditional internet-facing firewalls as:
- Not client-specific – cannot identify who made the initial query (person or device) without some arduous work-around or data correlation
- Check only one query at a time, without context to the queries that became before or after
- Not particularly useful for forensics, with limited knowledge of lateral movement, especially when severs before the last hop cache the results from the first client that queried the domain
- Respond to public, internet-bound traffic only
- Do not see every query – including those cached and queries to internal servers
Very importantly, internet facing DNS firewalls do not have all of the necessary context to drive real policy. Policy is mostly focused on the destination domain of the query or the response. It lacks any information on the specific client, the network or location of that client, or the device type of that client.
Consider the security exposure to network infrastructure when a firewall can’t detect where the original query is coming from, who that individual is, or what device or app is being used to make the request.
DNS grapples with another major security hurdle. Over 80 percent of DNS queries are cached – so if any caching occurs before the DNS firewall, it is immediately blind to 80 percent of the queries. If caching is delayed, network performance can suffer.
There is a better way.
Client-Facing DNS Firewalls
What if there was a DNS firewall on the CLIENT side of the DMZ?
What if all queries went to the client-facing DNS firewall first?
What if all queries were logged, regardless of caching, and regardless if queries are for private or public namespaces?
What if you could create rich contextual policies that allow you to apply least privilege access models to DNS?
Client-facing DNS firewalls can apply proactive security policy with full knowledge of the query.
These are just a few of the security data deficiencies resolved with a client-facing DNS firewall:
- Know the source of every IP address of every query
- Know each client-specific query
- Create policies around query patterns – only achievable with visibility into client-specific queries
- Track lateral movement – seeing every client’s query in historical context
- Address both public and private queries – not limited to internet-facing queries
Client-facing DNS firewalling is smart.
It enables full visibility into network queries, leverages cached records and logs activity data. Client-facing DNS data empowers enterprise security with intelligence to preemptively bar unwarranted activity by setting specific policies for least-privileged access by user, device, app or service – flagging any query or use pattern that falls outside pre-set security parameters.
To be useful, the DNS data must be comprehensive and formatted – without compromising network performance. Innovations in DNS data capture allow a client-facing query to be sent while simultaneously evaluating its security profile, without onerous overhead to the network.
The time is now to get proactive about network security. DNS data, readily available, can provide insight and intel to set essential activity boundaries for network protection and peace of mind.
Published in:
Growth by Content is what I do. I’m fuelled by conversations, coffee and sarcasm.
Related content
Automate your DDI modernization path by migrating with Micetro
Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.
How to map your network with user-defined links in Integrity X
Map your network with user-defined links in Integrity X to define and manage custom relationships, such as dual-stack and NAT environments.
Your journey to intelligent NetOps begins at Cisco Live
Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.
Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)
Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.