What my DNS logs can and cannot tell me

NextDNS sits in the lab as LXC 209, and it is the part of the stack that sees intent earliest. Before a machine opens a connection, it asks a resolver where to go. A DNS log is a record of those questions, which makes it useful, and also easy to over-read.

I keep my DNS requests private. A DNS log is a list of every name my devices looked up, so it shows which sites I browse, which apps check in with their servers, and when each device wakes up and goes quiet. Publishing it would publish my habits and my devices’ schedules along with it.

So I publish only aggregates I have approved and examples I built for the purpose. Everything you can filter below is simulated telemetry: one invented day, 7 November 2026 in UTC, built so every number on this site agrees with every other. The real capture stays in my private notebook.

How a query reaches the profile

A NextDNS profile is a policy with an ID: blocklists, allowed and denied domains, and logging settings. In my lab, ordinary clients ask Sophos, Sophos forwards to LXC 209, and LXC 209 runs the NextDNS CLI, which sends each query to the profile over DNS-over-HTTPS with client reporting on. The forwarder bootstraps with a separate plain resolver, so Sophos and the forwarder can never loop into each other. My Windows laptop also runs the NextDNS client directly, so its queries reach the profile without passing through the forwarder.

nextdns status && nextdns config

running
listen <forwarder-address>:53
profile ••••••
report-client-info true

A day of queries, simulated

What the log can tell me

• Which device asked, and when. With the forwarder tagging clients, a burst of blocked queries points at one machine.
• What the policy did. A block is the profile matching a list, which is a decision I can trace to a rule.
• Changes in pattern. A workstation that suddenly asks for a newly registered domain is worth a closer look.

What it cannot tell me

• That a connection happened. A blocked query means the name was not answered. It says nothing about a hard-coded address, a different resolver, or encrypted DNS that bypassed the forwarder.
• Who the person was. A device tag is not an account. That is what the Windows logs and Active Directory are for.
• Where traffic really went. A destination country inferred from resolved addresses is an estimate, which is why the map above is labelled modelled.

That last list is why DNS sits next to the firewall and the endpoint logs in my notes, not instead of them. It also cuts the other way: when a name fails to resolve, the answer may not come from the profile at all. The NOC case is one where Sophos answered NXDOMAIN on its own. When a DNS alert reaches the SOC queue, the next step is always to look for the matching connection, or its absence, in Sophos.

What I learned

A DNS log records questions, not connections. It is the earliest sign of intent I have, and the easiest one to over-read. Read on its own, a block proves the policy worked; it does not prove the device was stopped.

Takeaway: pair every DNS finding with one other source before calling it an event. For a block, that source is the firewall log for the same device and minute.

Further reading: NextDNS CLI wiki