XireTech · Technical white paper

The Moment of Intent

Why DNS-layer security grew from a feature into a platform, how it compares with ZTNA, SASE and CASB, and what it would take for it to count as an AI-era control.

1Every connection starts with a question

We say a browser "goes to" a website. Nothing goes anywhere. A process asks the operating system for a socket, the operating system needs an address, and the address comes from a name. State is set, copied from hop to hop, and acted on. The whole exchange has four checkpoints, and each sees more than the one before it:

1. Resolve. A name becomes an address. The question is small and fast, and almost every application asks it.
2. Connect. A socket opens to an IP address and port. The network now knows where, but not why.
3. Session. TLS is negotiated and identities are exchanged. Who is talking to which service becomes visible to anyone positioned to look.
4. Payload. The actual content: a prompt, a file, a form. Seeing this requires decrypting traffic in the middle, which is expensive.

DNS-layer security works at the first checkpoint. It sees intent before a connection exists, at very low cost per decision, across every application that resolves names. It leaves the content of the conversation that follows to the layers built for it, which is exactly what keeps it fast enough to sit in front of everything.

Control the question and you get a say in everything that follows.

2Is it really an omnipresent tunnel tree?

Look at the whole architecture, client included, and the picture is hard to miss. Every protected device, wherever it is, keeps a governed path to the nearest node of a global network. Each device has its own branch, the branch moves with the device, and policy governs all of it. From the console it behaves like a firewall that follows people around.

The answer is yes, for one of the two planes. Every network security system handles two kinds of traffic:

• The intent plane: the decisions. May this device reach that name?
• The data plane: the traffic itself, once the decision is made.

With its client, DNS-layer security is a tunnel tree for the first plane, and it lets the second travel direct. That split explains almost everything about it: why it's cheap, why it's everywhere, and why the client matters as much as the network.

The mesh: what Anycast does

Anycast is a routing technique, not a transport. The same IP address is announced from many locations, and internet routing (BGP) sends each query to the nearest one. DNSFilter describes its resolver network as a "Dual Anycast" network of more than 200 servers in about 70 cities across more than 45 countries, where queries "resolve on the nearest anycast DNS resolver."¹ That puts a decision point close to every user, everywhere. Three things complete it, and they can only be done from the device:

• Steering. Making sure every question reaches the mesh, including from applications that would otherwise use another resolver, encrypted DNS (DoH or DoT) to an outside provider, or a hard-coded IP address.
• Attribution. Telling the resolver which device, user or process asked, so policy can be personal rather than per network.
• Integrity. Keeping those settings in place on a device where malware, a curious user or an autonomous agent might try to change them.

The tree: what the client adds

The endpoint client turns the mesh into a tree. DNSFilter's description of its Roaming Client names the first two jobs directly: it ensures "all device DNS requests go to DNSFilter," and it "embeds the device identity in the DNS requests."² With the client in place, every question a device asks, on any network, travels a governed branch to the nearest node, carrying the identity of whoever asked. The branch re-roots as the device moves; policy, not location, decides what comes back. The third job, integrity, is where much of the deep engineering lives: the tree is strongest when every question uses it.

One detail the public pages cited here don't settle: whether those questions travel encrypted between client and resolver. If they do, the tunnel label fits the intent plane even more literally.

The data: where the traffic goes

Once the answer comes back, the application connects straight to its destination, at full speed. The traffic itself doesn't need to flow through the mesh, and that's by design: carrying only decisions is what keeps the system light enough to sit in front of every connection on every device.

Where a network can't be trusted, the architecture now reaches into the second plane as well. DNSFilter now offers SecureTransit, an add-on to its Windows Roaming Client that wraps device traffic in an encrypted WireGuard or IKEv2 tunnel on untrusted networks such as public Wi-Fi and hotels. Their documentation is careful about scope: it "is not a full VPN product," and it "runs alongside DNS filtering without affecting filtering policies or reporting."³ Where it's switched on, the data plane gets a tunnel too.

3Alongside ZTNA, SASE and CASB

These terms are often used as if they competed for one slot. They work best as layers. Each sits at a different checkpoint in Figure 2. ZTNA (zero-trust network access) replaces the VPN for reaching private applications: it brokers a session per application, per identity, instead of placing a device on a network. A secure web gateway and a CASB (cloud access security broker) inspect web and SaaS sessions, usually by decrypting them, so they can apply data controls inside a conversation. SASE (secure access service edge) is the converged package of these with networking, delivered from the cloud. Its security half is often sold as SSE.

Comparison by architecture class, not by vendor. Specific products blur these lines; many SASE suites include a DNS layer, and DNS-layer vendors add proxies and tunnels.

Does it undercut them?

The two planes from section 2 are the cleanest way to see it. ZTNA, secure web gateways and CASB work in the data plane: traffic flows through their infrastructure, which gives them depth at a cost per decision. DNS-layer security works in the intent plane: it routes the decisions and lets the data travel direct.

On cost and reach, it does undercut them, and that matters most in the mid-market and MSP-managed segment, which will never deploy, staff or pay for full TLS inspection on every device. For those organizations a DNS-layer control with a strong endpoint client delivers a large share of practical protection (malware delivery, phishing, command-and-control callbacks, unwanted categories) at a fraction of the cost and friction. The category's history points the same way: DNS-layer protection has repeatedly become the on-ramp to broader security services. The first gate is the natural place for a platform to grow from.

The deeper controls stay useful for what they were built for: reading content and telling accounts apart inside a session. That's a division of labor, not a contest. DNS-layer security is the gate every connection passes first, and that's what makes it the right place for a platform to start.

4Is it an AI-era approach?

The timing favors it. AI agents work at machine speed and scale, and every one of their connections still starts with a name. At the moment of resolution, a thousand requests per second from an agent and one click from a person cost the control the same: one decision per question. DNSFilter's network page says it is "powered by machine learning" and offers AI-categorized content policy,¹ which is how a categorization engine keeps up with domains that appear and disappear by the hour.

The AI era also changes the question the control has to answer, and that's where the most interesting work is.

The question evolves

The classic DNS-layer question is is this destination bad? Reputation answers it well for malware and phishing. Agents add a new kind of traffic: calls to legitimate, well-reputed endpoints such as a model provider's API, a code host, a storage bucket or a vector database. There's nothing malicious about the domain. What matters is who is calling it, how often, and on whose behalf.

Anyone who has built web protection on an endpoint will recognize the pattern. Network-level filters once couldn't separate subdomains that shared an IP address, and DNS solved that by reading names. With AI services, a personal account and a company workspace often sit behind the same name, so the next distinction lives one level up, in the account and the actor. Each generation of the problem moves the decision closer to who, and the endpoint client is the component positioned to supply it.

Four signals for the AI era

1. Actor. Which device, user, process or agent asked. The client already attaches device identity to each question;² extending that down to the process and the agent is the natural next step, and it makes the client the center of the product.
2. Destination class. Not only "good or bad" but "what kind": model APIs, agent frameworks, data stores, collaboration SaaS. A classification problem at machine speed, which is the kind of problem an ML-driven categorization engine is built for.
3. Behavior. Rate, novelty, time of day and fan-out. An agent that suddenly resolves forty new storage endpoints in a minute looks different from a person reading the news, even when every domain is clean.
4. Sanction. Whether this actor is approved to use this class of destination. Where the answer depends on the account inside a session, the intent plane can hand the decision to a session-level control. Knowing when to hand off is part of the design.

Put together, those signals make DNS-layer security the earliest, cheapest and widest source of evidence about what software is trying to reach, tied to which software is trying. That's an AI-era control.

5Why the work matters: the engineering frontier

A gate at the first checkpoint earns its value at the edges. These are the problems that make the work worth doing:

• Encrypted DNS. Browsers and operating systems increasingly default to DoH or DoT. Keeping resolution in the tree while respecting legitimate privacy features and the user's experience takes careful design.
• Direct-IP traffic. Anything that never asks for a name never reaches the resolver. Covering it calls for network-level enforcement on the device, a discipline that sits right next to DNS.
• Client integrity. Tamper resistance, self-protection and honest reporting when the client is impaired, across Windows, macOS, mobile and servers.
• Process attribution. Mapping a query to the process that caused it, reliably and cheaply, on every operating system the client supports.
• The boundary of the device. Printers, cameras, TVs and other unmanaged devices share home networks with protected laptops. Drawing that boundary clearly is part of the product.
• Precision at scale. At console scale, a wrong block on a shared service reaches thousands of people at once. Precision is a feature customers feel within minutes.

6Conclusion

With its client, DNS-layer security is an omnipresent tunnel tree for intent: a mesh of decision points close to every user, a governed branch from every device, deciding at the one checkpoint every connection has to pass while the data travels direct. It's the gate in front of the rest of the stack, and for much of the market it's the only gate they'll ever deploy. The AI era plays to its strengths. The step from device identity to actor attribution is the next chapter, and the companies that write it will own the moment of intent.

Author's note

I spent years on the endpoint side of this problem: building web protection on the Windows network stack, and taking it from a consumer product to a managed console, where DNS filtering became the answer to subdomains that packet-level filtering couldn't tell apart. Watching a company build a platform around that same moment of intent is why I wrote this.

Method and sources

This paper uses public information only. Statements about DNSFilter quote or paraphrase the company's own published pages and are cited; nothing here describes internal implementation details. Comparisons are by architecture class.

1. DNSFilter, "Speed, Stability, Scale" (network page). dnsfilter.com/our-network
2. DNSFilter, "Everything you need to know about Roaming Clients." dnsfilter.com/blog
3. DNSFilter Help Center, "Set up SecureTransit for Windows Roaming Clients." help.dnsfilter.com