Skip to content

DNS Client Query Filtering

Improving Client Application Access Control

For zero trust architectures, the Client Query Filtering feature creates a security barrier at the earliest point, helping prevent lateral movement of attacks.

Client Query Filtering (CQF) Solution Benefits

CQF offers granular filtering (microsegmentation) combined with allow/deny listing to provide a powerful checkpoint for App access control.

Icon global accurate Visibility purple
More Granular Filtering

Improve network segmentation down to the individual client.

Icon anticipate Problem purple
Better Application Access Control

Enable DNS-based client access control to vital apps and infrastructure.

Icon firewall purple
Early Security Barrier

Detect anomalies at the earliest point in the flow to reduce exposure risk.

Icon ideas purple
New Business Opportunities

Enable new B2B2C offers (e.g. parental control for telcos).

Icon world purple
Stronger Security Ecosystem

Allow immediate modifications through API and standard DNS zone manipulations.

How to improve Application Access control with DNS Client Query Filtering (CQF) Video

Using authentication alone leaves the door open to malware. A better way is to filter control at client level, using microsegmentation and deny/allow listing. DNS offers this possibility, providing an early security barrier.

 

Discover practical tips and strategies to bolster security and streamline user access. From fine-tuning permissions to optimizing query filtering, this video is your guide to a robust access control setup. It covers use cases around internet access restriction, parental control, and IoT security. Join us as we delve into the intricacies of Client Query Filtering and empower your Zero Trust strategy. Don't miss out โ€“ watch now and elevate your network's security to the next level!

Picture Graph of Cqf Lists

CQF brings an easy way of managing application access control as a new facet to DNS filtering, with security based on the source client information mapped to the requested domain, rather than filtering based only on the domain. A dedicated filtering policy can therefore be applied to specific clients requesting access to specific applications. This brings DNS security to a higher level, by combining client and destination information with allow and deny lists, therefore enabling application security enhancement.

 

The main components required by CQF in order to perform rich DNS filtering are:

  1. A list of client identifiers and tags
  2. A list of domains to analyze
  3. The operation to perform, either allow, deny or apply countermeasure.

 

Each DNS request is compared with the content of the list of applications and domains for applying the relevant policy. The lists are either local to each DNS Guardian server and managed manually - which is useful for testing purposes - or centralized and managed globally, which is ideal for security policy enforcement. The domain list is a standard RPZ zone that can be maintained in the SOLIDserver through GUI actions and API calls, but can also be subscribed to from a threat intelligence provider. Distribution of each list to all the Guardian DNS servers is performed through standard replication mechanisms, scalable and in real time allowing automation scenarios with the security ecosystem and with OSS/BSS solutions.

 

The filtering process is the heart of the CQF feature and enables rich security usages. Having the ability to use and manipulate large amounts of information in the lists provides a real advantage when it comes to applying security to multiple groups of clients which are complex to identify. This management is made possible by the high performances of the DNS Guardian engine and its integration in the whole DDI ecosystem of the SOLIDserver.

Request A Demo of CQF

See Client Query Filtering in action with a demo of DNS Guardian.

Access control to applications can be performed at multiple levels in accordance with the security policies in place within the organization. For most, the main level in place nowadays is Authentication and Authorization at the application level through credentials - probably no application is accessible without user screening.

 

But is that really enough? Can a user with no access to an application get access to the login page? If self registration is not an option for this application, which is mainly the case in organizations, then why expose access to its infrastructure from the network?

 

There are some very important applications that require specific access and run on a dedicated infrastructure with no sharing of main components. Filtering at the network level is an option to consider, whereby routing access lists and firewall rules are an implicit solution. However, by adding filtering at the DNS level, you raise the security level even higher. This leaves no possibility to resolve the application technical IP addresses, no network level and no credentials, so is a far better approach to security in a Zero Trust environment.

 

By having the ability to dynamically update the CQF lists with either application or client entries, security is automatically raised to the appropriate level, limiting the application's exposure and data visibility to unknown or non authorized users.

Flowchart of Cqf Dns Firewall Solution

Key Resources

For further information on EfficientIP security solutions which improve Application Access control and enable zero trust models, take a look at these additional resources:

DNS DNS Security
Augmenting Zero Trust: Why Using DNS Allow Lists is a No-Brainer
Explore
Ddi video generic icon
Videos
Improving Application Access Control using Client Query Filtering
Explore
Datasheets
DNS Guardian: Real-time Behavioral Threat Detection
Explore

Assess Your DNS Risk

In order to help you better understand the usage context and behavior of your DNS clients, EfficientIP offers a free assessment involving expert analysis of real DNS traffic.

Cta Learn More Button for Free Assessment of Existing Dns