Augmenting Zero Trust: Why Using DNS Allow Lists is a No-Brainer

You can’t control what you can’t see, as the saying goes. One of the main pillars of Zero Trust Foundations is Granular Visibility and Control on the traffic. This means being able to differentiate the sources of the traffic (microsegmentation) and their related destinations. From there, security wise, one can decide what has to be done, allowing or denying source-destination combinations.

Regarding granular visibility, DNS by nature sees all traffic intents at the earliest possible point in the IP traffic flow, actually even before application data flow on the network. By default DNS serves all requests from any source to any known destinations. What if we use this integral capability of DNS to decide whether some source-to-destination’ combinations would be granted or not, as a security measure? DNS security already uses deny lists as part of DNS Filtering (Response Policy Zone) to deny access to inappropriate domains (malware, etc.). Why not use DNS allow lists as part of a Zero Trust strategy to specifically grant certain users access to only specific applications? In Security, Allow Strategies use a mechanism called an Allow List which explicitly allows some identified object access to a particular privilege, service, application while by default the rest are denied.

Why Authentication and Firewalls are Not Sufficient for Granular Visibility and Control

Let’s have a look at traditional tools/solutions used for Zero Trust strategies. Using Authentication will prevent access to an application but not to the infrastructure hosting it. As an analogy, you might not have the key to the front door of the house but might try an open backdoor or window to get inside anyway. So, not only does user authentication arrive late in the security process, letting the user send his traffic that should be denied across the network but this also “leaves the door open” to attacks on the infrastructure. It’s necessary as you don’t want to leave your door unlocked and opened anyway but this is not sufficient to efficiently protect your applications.

As we mentioned, DNS Filtering (RPZ) using deny listing, can block access to some domains (malware, etc.) but this will do it for all clients. Although it is useful and necessary for domains that must never be accessed by anyone, whatever the reason (security, legal, performance, etc.), this can’t be used as a means to differentiate access to applications from a client standpoint.

Ultimately, routers and firewalls can do the job but as they are usually positioned at the edge of the network between the WAN and the LAN, if you want to protect access to your internal applications while also differentiating all your clients, you need to position a firewall function behind each port of your network, behind each client and each application. This is theoretically possible but is complex and hefty to manage, might lack flexibility if you need to adapt your network to new business imperatives and will undoubtedly become costly at the end. So there again, although firewalls are indispensable to protect the communications between sites, they are not the best option to protect what’s inside your networks.
So all in all, each of the existing solutions used as part of Zero Trust strategies are lacking some capabilities to efficiently provide Application Access Control at client level.

Allow Lists: a Good Start to Control & Secure Application Access

As we stated, by its very nature and purpose, DNS sees all traffic intents between clients and applications, domains, resources. DNS will serve all requests from any client toward any destinations, denying access to unwanted domains and sites for all clients with DNS Filtering. In any case, by default, DNS does not exploit the requesting client information to decide if the request should be served or not. And yet filtering DNS requests based on the requesting clients would complement traditional Zero Trust solutions to help them overcome their obvious limitations. The use of DNS allow listing at the client level will be applied early in the process, preventing the unwanted traffic to be sent across the network. It will differentiate internal and external applications without having to deploy any new security infrastructure on the network and can be done rapidly. It will differentiate all client types, users, machines, IoT and all the combinations of client-to-application traffic, wherever they are all located and regardless of the network (LAN, WAN, Wireless) between them.

DNS Allow Lists: Your first line of defense for Zero Trust

Zero Trust does not rely on a single set of solutions or technologies. On the contrary, the more security layers, the stronger the security and protection of your Apps, Users and Data. Application Access Control in a Zero Trust framework can be easily activated by using EfficientIP DNS Client Query Filtering (CQF). This will complement your existing solutions by expanding the capability to filter access to any applications and resources at the client level leveraging DNS allow lists; making DNS your first line of defense.