DNS for AI Governance: How to Use DNS Resolver Logs

Most organizations trying to govern AI adoption start by buying something that discovers AI usage. It’s a reasonable instinct and usually a wasted quarter, because the discovery data already exists. It’s in the resolver logs, it covers every device on the network, and in most enterprises nobody has run a query against it.

That’s the argument, and it’s made in full in the companion piece, DNS for AI Governance: Your AI Program Isn’t Stuck on Technology. The short version: identity governance can only govern principals it already knows about, and the entire shadow AI problem consists of things nobody enrolled. DNS is the one control that is both pervasive and pre-connection, because everything resolves before it connects, including what you’ve never heard of.

This piece is the sequence for acting on that. Five steps, in the order I’d do them, with the costs stated honestly, including the one that is larger than most pitches admit.

One framing note before the steps. Nothing here makes DNS a replacement for anything. It is a broad, cheap, early, incomplete signal covering a population your other tools cannot see. The limits are set out near the end and they are worth reading before you build on any of it.

Key takeaways

• Two prerequisites gate everything: client-attributed resolver logs, and a seed list of AI destinations you write yourself. Without the first, discovery returns destinations with nobody attached. Without the second, there’s no category to filter for.
• Start with seven days, not ninety. Ninety days of raw logs on a busy resolver runs to roughly a terabyte, and ten resolvers to ten. Discovery wants distinct client-and-name pairs, which compress enormously, so roll up at the source.
• Enforcement is worth exactly your resolver coverage. Hardcoded resolvers, DoH, DoT and DoQ are the bypass surface, and closing the DoH path properly costs more than port blocking.
• Allow and deny is not enough. Graduated policy, with redirect as the most useful action for AI, needs a resolver that can condition on client identity. Many cannot.
• The same telemetry answers an operations question. Grouped by hostname instead of by client, it gives you a ranked hypothesis about which applications are live and which are dormant.

What that looks like in practice

Five steps, in the order I’d do them.

Two prerequisites first, because the whole sequence assumes them and it’s dishonest to pretend otherwise.

You need client-attributed resolver logs. Not every deployment keeps them. Plenty log queries without preserving which client made them. If you don’t have client attribution today, step 1 produces a list of destinations with nobody attached to it, which is interesting and not actionable. Fixing that comes before everything below.

You do not need ninety days of raw logs, and you should not go and buy them. I had a longer window in an earlier draft and Alexandre Chauvin-Hameau, EfficientIP’s Product Management Director,  put real numbers to it, which I’m glad he did. One resolver at 1,000 queries per second is roughly 86 million queries a day. At about 150 bytes a line that’s some 13GB daily, so ninety days of raw retention on a single resolver runs near a terabyte. Ten resolvers and you’re looking at ten. That is not a configuration change. That is a storage project with a budget and a procurement cycle, and anyone telling you discovery is free has not costed it.

The good news is that discovery doesn’t want raw logs. It wants the set of distinct client-and-name pairs, which compresses to a rounding error against the query volume that produced it, because a client resolving the same name four hundred times collapses to one row. So roll up at the source, discard the high-volume traffic you already know is legitimate before it leaves the resolver, and keep aggregates rather than lines. And start with seven days, not ninety. A week surfaces most of what a quarter will, because an AI tool in real use gets reached for more than once a week. Extend the window when you have a reason, not by default.

Long retention is a genuine requirement, but it belongs to step 4, where it’s an audit decision made deliberately with that storage cost in view. Don’t let it block discovery.

You need a starting list of AI destinations. You cannot filter for a category you haven’t defined. Begin with a seed list: the model providers, inference endpoints, and AI-enabled SaaS you already know about, twenty or thirty names you can write from memory in ten minutes, then expand it from what the first query surfaces alongside them. The list is an input to discovery and an output of it, iteratively. It is not something the query hands you from nothing.

1. Discovery: Run the Query

Before any purchase or architecture discussion: every unique domain resolved in the last 90 days, grouped by client, matched against your seed list and its near neighbours. Model provider APIs, inference endpoints, AI-enabled SaaS, agent frameworks, MCP registries.

How long this takes depends entirely on what you already have. With logs in a SIEM that already retains 90 days with client attribution, it is genuinely an afternoon. Without that, if retention is short, if attribution was never preserved, if the logs exist but nothing indexes them, it is a project, and the first phase of that project is the plumbing rather than the query.

Two things come out, and both are useful.

The first is scale, and it’s your budget justification. Executive surveys consistently show leadership believing they have a clear picture of AI usage; employee surveys consistently show they don’t, and the delta is not small. Resolver logs settle that argument with evidence instead of opinion.

The second is shape, and here you have to be careful about what the data actually supports.

Resolution count is not call count. Client-side caching, connection reuse, and HTTP keep-alive all sit between the two. An agent hammering a model provider over one persistent connection may resolve the name once an hour and make ten thousand calls behind it. Treat resolution counts as a floor, never a measure. Anyone who tells you DNS quantifies AI usage is overselling it.

What degrades least is presence, timing, breadth, first-seen activity, and changes in behavior, and these are signals rather than proof. A lookup logged at 3am was logged at 3am regardless of TTL.

Distinct clients per service is the sturdiest number you get. How many clients in your estate resolved a given AI service is barely affected by caching, because each one has to ask at least once. That alone answers more of the governance question than most people expect.

TTL also bounds the cache problem more than I first credited. Published TTLs on AI services tend to be short, often a few minutes, so a client in sustained use has to re-resolve repeatedly across a working session. That still won’t give you call volume. It does give you a floor on engagement windows, and reading resolution counts against a known TTL tells you something about how long a client was actually in a service rather than merely that it touched one.

Regularly spaced lookups can indicate a cache entry expiring and being refreshed on a schedule, which human browsing tends not to produce.

One thing I had wrong in an earlier draft and will state correctly here: whether “first seen” means anything depends on your resolver. Working only from logs, it means the first appearance in the lines you still have, which is a fact about retention rather than history. Resolvers that track newly observed domains at the engine level know genuine first observation regardless of how long you keep logs. Find out which of those you have before you trust the field.

NIST SP 800-81r3 is worth reading on caching behavior before anyone builds detection logic on lookup timing.

So none of this finds you an agent. It finds you a candidate worth confirming with something that can confirm it.

Scope boundary, and it’s narrower than I first described it. This works because AI tools are overwhelmingly SaaS-hosted and have to resolve something to function. A locally-run model resolves nothing. A stdio MCP call between an agent and a server on the same machine resolves nothing either, so that hop is invisible to you.

But the hop is rarely the interesting part. Ask instead what the MCP server itself reaches for. If it connects onward to a data source addressed by name, a SaaS API, a hosted database, a web service, then that connection does resolve and you do see it. The question worth asking is not is this transport local but does this tool reach a named data source, and for most tools worth governing the answer is yes. The genuinely dark case is a local model talking to a local store, and that is a smaller population than the phrase “local MCP” suggests.

2. Fix the plumbing before writing policy

The common failure: a beautiful DNS policy enforced on 70% of endpoints, because the rest aren’t using the enterprise resolver and nobody checked.

DNS enforcement is worth exactly your resolver coverage. CISA’s encrypted DNS guidance is direct. Encrypted DNS costs defenders visibility and enforcement, and the fix is permitting only authorized internal resolvers to reach authorized external ones. Four paths to close:

• Hardcoded resolvers. 8.8.8.8 or 1.1.1.1 baked into apps and devices. Common in IoT, appliances, BYOD.
• DoH on 443. DNS inside HTTPS, browser-default, and indistinguishable from ordinary web traffic once established. Worth knowing that it usually announces itself first: a client configured with a DoH provider by hostname has to resolve that hostname through your resolver before it can start bypassing you, so the provider’s name shows up in your own logs. Only a client pinned to a raw IP skips that tell. Go and look for the known provider names before assuming you have no visibility.
• DoT on TCP/853. Block unauthorized external encrypted resolvers rather than the port itself; your own resolver may legitimately need it.
• DoQ on UDP/853. RFC 9250 sets UDP/853 as the default and explicitly forbids port 53; UDP/443 appears only where both ends have agreed to it. Newer, increasingly common, frequently missed.

The goal isn’t forbidding encrypted DNS. It’s ensuring your resolver does the encrypting. Support DoH internally, and block every other encrypted resolver.

Be realistic about that last clause, because it’s where this gets expensive. Blocking DoT or DoQ by port is straightforward. Blocking DoH to an arbitrary provider on 443 is not, because it needs either a firewall that can inspect inside a TLS session or a maintained IP blocklist of known providers. Neither is free, and a plan that assumes port blocking covers DoH will quietly leave the largest hole open.

NIST SP 800-81r3, final in March 2026 and the first revision since 2013, covers the rest: DNSSEC validation, hardened recursive and authoritative infrastructure, minimizing information leakage in queries and responses. Read the document, not a vendor summary of it.

3. Enforcement: Graduated, Never Binary

Allow/deny fails at AI governance for an organizational reason: the honest answer to most AI destination questions is neither. It’s “yes, but log it, rate-limit it, and tell me who.” Give a team only permit-or-forbid and they will permit, because forbidding breaks the business, and you’ll have deployed enforcement with the enforcement switched off.

One prerequisite before the model, because it’s the part that decides whether any of this is practical: your resolver has to be able to apply policy per client. A stock resolver generally cannot. It answers queries; it doesn’t know that this subnet is finance and that tag is an agent host, and it has no way to vary the answer accordingly. Conditioning policy on client identity rather than on the name alone is a specific capability, usually sold as client query filtering or something named like it, and if you don’t have it then what follows is a design you can’t yet implement. Establish that first, because it changes the conversation from configuration to procurement.

Three inputs, more than two outputs:

Client identity. IP, subnet, MAC, or better, a tag: finance, contractor, dev-workstation, unmanaged, agent-host. Tags survive re-IPing and scale past a spreadsheet.

Destination category. The AI taxonomy from step 1, maintained as a living list. Most threat feeds don’t give you this yet; you may curate it yourself initially. Do it anyway.

Action. Allow, allow-with-logging, rate-limit, redirect, quarantine, deny.

Redirect is the one people forget, and for AI governance it’s frequently the best answer available. Rather than denying a client’s lookup for an unsanctioned AI service and generating a support ticket and a workaround, resolve it to your own approved equivalent: the enterprise tenant, the internal gateway, the sanctioned API endpoint. The employee reaches a working tool instead of a block page. You get the governance and they get the job done, which is the only version of this that survives contact with people who have deadlines. Blocking teaches employees to route around you. Redirecting teaches them the sanctioned path is the easy one.

That gets you the policies you actually want. Sanctioned provider: allow all, log everything. Unsanctioned: allow for the AI evaluation team, deny for finance, quarantine and alert for unmanaged devices. Newly registered domain resolved by a production agent host: quarantine, always.

That last one is where AI governance and threat defense turn out to be the same control. EfficientIP’s threat intelligence tracked one campaign through 2025 that generated roughly 580,000 potential command-and-control domains, the large majority registered and left dormant, waiting. Attackers provision infrastructure the way cloud teams do: in bulk, ahead of need. Newly registered and newly observed domains account for roughly a fifth of matched malicious DNS traffic; phishing another 30%.

Domains you’ve never seen are the highest-signal, lowest-cost thing to be suspicious about, and an agent resolving one is a materially different event than a human doing it. The human might have clicked a link. The agent is following a plan, and something put that name in its path.

4. Audit: Resolution Logs as Governance Evidence

Resolution logs are the only record covering attempts rather than enrollments, including by things nobody registered. Piped to your SIEM, they’re a defensible timeline of AI activity across the estate.

Two things to get right. Retention. Match your longest audit window, not your default log policy; DNS logs are high-volume and get aged out by teams who see them as operational noise. Attribution. Someone resolved this is worthless; this tagged client resolved this at this time is evidence. Make sure client attribution survives into what you forward.

5. Portfolio Triage: The Operations Dividend

A recap, because this step rests on an argument made in Part 1 rather than here. AI compressed the distance from kickoff to MVP and did nothing to day 1 and after, so organizations now ship far more applications against flat operations headcount. “We deployed seventy-three applications this month, you need to support them all” has no honest answer without usage data, and AI-accelerated applications are the least likely to have been instrumented, because instrumentation is a phase-two concern and phase two often never arrives. DNS doesn’t need the application’s cooperation to answer it.

Same telemetry, different query, different customer. Instead of grouping by client and filtering to AI destinations, group by internal application hostname and count distinct clients over time.

What you want per application: distinct clients over the full window and over the last 30 days, and the distribution of activity across time so you can separate a quarterly burst from a daily grind.

The most useful figure is the gap between those first two numbers: how many clients reached for a name early and stopped. I’d avoid calling that an abandonment rate, because it isn’t measuring abandonment; a lookup is not a use, and its absence is not proof of disuse. A client can reach an application by address, through a proxy that resolves on its behalf, or from a record still held in a cache. What the gap gives you is a fall-off signal: a ranked list of names that look dormant, to be confirmed with the owners before anyone acts on it.

That’s the honest frame for the whole step. It is a prioritization hypothesis, not a usage metric, and it is worth having precisely because the alternative on offer is nothing.

One prerequisite, and it has to be set at deploy time: one application, one name. This works cleanly when each app gets its own FQDN. It degrades badly under path-based routing on a shared ingress, where apps.company.com/thing-73 produces the same single resolution as everything else behind that hostname. If your platform team is deploying at volume, per-app naming costs essentially nothing and should be policy, not for tidiness, but because it’s what turns your resolver into a portfolio instrument for free. Get this into the deployment template now; you cannot retrofit it onto names that were never issued.

On tooling, as of this writing: this is not a standard report in the DNS platforms I’m aware of, from any vendor. Where something like it surfaces at all, it tends to be a point-in-time assessment rather than continuous reporting. So assume for now that this is a query you or your vendor’s services team run against the log store, not a dashboard you switch on. Plan the effort accordingly, and ask any vendor telling you otherwise to show it running in a customer environment today.

Hand the output to whoever owns the application portfolio. It answers a question they have been asking for two years and have never been able to source.

What this does not do

The same caveats I’d want from anyone selling you something, unprompted.

DNS shows a requested name and, if your resolver logs it, the client that asked. Not content, not intent, not proof that anything followed. A lookup for a model provider’s API is identical whether an employee is drafting an email, an agent is walking a customer database out the door, or a link preview fired and nothing happened. A resolution is a request for an address, not evidence of a connection, a transfer, or a human. Pair this with DLP and egress inspection; it replaces neither.

Local agent traffic is invisible here. Stdio MCP calls never traverse the network. Anyone claiming DNS gives you complete agent visibility is selling you something.

This is not your AI governance program. It’s the substrate underneath it. You still need policy, ownership, and an answer for what happens when someone violates it.

What DNS uniquely provides is pervasive, pre-connection coverage of things nothing has onboarded yet, precisely the population your identity layer is structurally blind to. Bounded claim. Enough to make it the first move rather than the fourth.

Monday

1. Check the prerequisites. Do your resolver logs retain 90 days, and do they preserve which client made each query? If either answer is no, that’s the actual first task and everything below waits on it.
2. Write the seed list of AI destinations from memory. Twenty or thirty names, ten minutes, no tooling.
3. Run the 90-day query against it, grouped by client. With logs already in a SIEM this is an afternoon; without, it’s a project whose first phase is plumbing.
4. Run the per-application query alongside it: distinct clients by internal hostname. Expect this to be a query someone writes against the log store rather than a report you switch on; see step 5. Take it to whoever owns the app portfolio. This is the version of the argument that gets funded outside the security column.
5. Audit resolver coverage. Find clients not using yours: hardcoded, DoH, DoT, DoQ. Close them.
6. Get one application, one name into the deployment template before another quarter of apps ships without it.
7. Expand the seed list from what the query surfaced. Maintain it as a living document.
8. Write one graduated policy against one high-risk client group. Prove the model before scaling.
9. Fix retention and client attribution into the SIEM, before an auditor asks, not after.

Most of this is configuration and query work against infrastructure you already own rather than new licence spend. That is not the same as free: it is engineering time, and steps 0 and 8 in particular can mean real capacity or storage cost if your logging pipeline was never built to carry this. Budget the effort honestly. The argument doesn’t need it to be countless, only cheaper than the alternative.

Your competitors are hitting the same gates you are. You will be asked what your AI is touching, repeatedly, by customers and auditors and your own risk committee. You will also be asked which of last month’s applications deserve an operations budget, and by whom, and how often. Neither question is going away, and both are answered by the same logs.

The only variable is whether answering takes an afternoon or a quarter, compounded across every initiative in your portfolio, for the next three years.

That’s not a security outcome. It’s your speed.

WHERE TO START, BY ROLE

TO SECURITY ARCHITECTS: Run step 0 today. Not the query, the prerequisite check. Find out whether your resolver logs preserve client attribution and how long they’re kept. Everything in this piece is worthless if the answer is wrong, and most people have never looked.

TO NETWORK AND INFRASTRUCTURE LEADS: You own the bypass surface, and it’s the part nobody else can fix. Hardcoded resolvers, DoH on 443, DoT, DoQ on 853. Enforcement is worth exactly your coverage, and coverage is worth exactly what you’ve measured. Measure it.

TO PLATFORM TEAMS: One application, one name, in the deployment template. It costs nothing this quarter and it cannot be retrofitted onto names you never issued. This is the single highest-leverage thing on the list and it takes an hour.

TO APPLICATION AND PORTFOLIO OWNERS: Ask your network team for distinct clients by hostname over ninety days. They can probably produce it and have never been asked. Treat what comes back as a list of questions rather than a verdict, then go and confirm it with the people whose applications are on it.

TO ANYONE ABOUT TO BUY SOMETHING FOR THIS: Run the query first. You may find you already own the answer, and you will certainly negotiate better knowing what your own data looks like.

About Howard Holton

Howard Holton is Founder and Chief Analyst of Phronia Counsel. This piece was produced in connection with a sponsored engagement with EfficientIP. EfficientIP had no editorial control and reviewed the draft only for factual accuracy regarding its own products.