Naming products can be tricky. A name, at its best, clearly articulates the function of something and can even invoke a sense of its qualities through the association the name draws to mind. But then there is the other side where the name tells us nothing about the product. Even worse, in my opinion, are those names that bring to mind strong associations, but those associations are either incomplete or misleading about the actual function of the product. A good example of this is “DNS Firewall”, an unfortunate moniker that came into being a number of years ago to describe DNS servers providing protection from certain types of malware attacks.
The problem isn’t with the DNS side of the name, that couldn’t be more accurate. The problem is with the “Firewall” portion and the paradigms that are associated with it. When most people think of a firewall, they correctly think of a box that sits on the edge of the “trusted” network and acts as a gateway and control point for any traffic flowing into or out of that network. It has been at the core of the traditional fortress approach to security strategy since the 1980’s and continues to play a vital role in network security to this day. Even the name “firewall” itself is originally derived from a physical structure used to provide a protective barrier between a portion of a building that is burning and the rest of the structure. The images that “firewall” brings to mind all centers around the notion of a protective shell around a vulnerable core. As a result, if a product includes “firewall” in its name, it tends to inherit this same type of image; a controlled barrier around a soft center.
Some Background Context
To understand why this firewall reference is an issue, we need to take a step back for some context. The Domain Name System, or DNS, is essentially a distributed name lookup for networks that handles the translation of human consumable names such as www.empowerednetworks.com into their equivalent machine consumable IP addresses (188.8.131.52 at the time this was written). As such, almost every communication process that occurs between devices on a network begins with a call to a DNS server.
Because of the foundational role that DNS plays in network communications, essentially being the first stop at the control plane for the initiation of communication, it also has the potential to act as a control point for those communications. I suspect that this is where “DNS Firewall” came from in the first place. In much the same way that a firewall device is in the path of all network packets, allowing it to inspect and control what packets get through, DNS sits in the network communication control path where it can similarly inspect requests and, potentially, control the response to them.
The Changing Problem Space
So what’s the problem? Well, the threat landscape has changed over the last number of decades and, with it, so has the concept of a safe, trusted network space. This isn’t anything new. Any security practitioner worth their salt will be aware that if your security strategy is based on a belief that a strong outside barrier obviates the need for interior protection, you’re probably already in trouble. The existence and popularity of a zero trust approach with layered defense in depth makes it clear that the industry understands there are no truly safe zones.
Back to the “DNS Firewall” question. If you’re one of the DNS providers that sits on the edge of the network, maybe exclusively cloud based, and provide external facing recursive DNS, the association that DNS Firewall makes with a protective hard shell is probably OK with you. You want people to associate your exterior line of defense with a positive protection message. If, on the other hand, you’re a full featured security focused DDI provider (think Infoblox for instance), the moniker “DNS Firewall” really sells you short.
More Than Just a Barrier
In a full stack DNS security solution, the reputational based components, such as RPZ implementation matched with high quality threat feeds, are not just deployed at the edge but are intended to be plumbed into all the internal recursive DNS servers. The pervasive application of reputation based approaches, combined with additional complementary behavioural technologies throughout the environment, allows better triangulation during issue identification. The ubiquitous application of these DNS security capabilities is firmly based in a zero trust model that is a far cry from the “protect the edges” view of the past.
Associating yourself with a designation that clearly brings to mind a desirable concept (i.e. firewall associating to impenetrable barrier) can be good if you are trying to enhance perceptions of your product. But when the capabilities you offer extend so far beyond those associated perceptions, as is the case with Infoblox DNS security offerings, the association can actually hurt you. I’m pretty sure that this was one of the considerations that Infoblox had in mind when they decided to move away from “DNS Firewall” as a product name/descriptor in favour of “BloxOne Threat Defense”.
So back to the question in the title; When is a firewall not a firewall? Hopefully, by now, you already know the answer to that.