A device can show no DNS activity because it sent no fresh query, used another resolver or network path, appeared under a different resource identity, or fell outside the selected time, action, and retention filters. Generate one harmless test lookup, confirm where it was resolved, then check identity and visibility before changing policy or enabling broad logging.
Treat an empty activity view as a missing-evidence problem, not immediate proof of bypass, data loss, or device failure. DNS is only one step in a connection, and clients commonly cache answers or keep connections open. A disciplined diagnosis follows one fresh lookup from one named resource through resolver, identity, policy, and permitted visibility.
Prove that a fresh query exists
Choose a harmless hostname that the device has not recently requested, preferably a provider-owned diagnostic name. Record the device, network, browser or command, local time with timezone, and expected resolver. Request it once. Avoid repeatedly opening a popular site: its address may already be cached, and page resources may generate many unrelated lookups that make the test harder to follow.
- Confirm the device has working connectivity and note whether it uses Wi-Fi, Ethernet, VPN, or cellular data.
- Issue one fresh A or AAAA lookup for the harmless test hostname and save the exact timestamp.
- Record the resolver address or encrypted resolver configuration the client actually selected.
- Check whether the client received an answer, timeout, redirect, or local error.
- Search only the expected resource and narrow test window before widening the investigation.
RFC 1034 and RFC 1035 describe resolver caching as a normal part of DNS operation.12 A browser or operating system can reuse an unexpired answer without sending another query to the recursive resolver. Applications may also reuse an existing network connection. No new resolver event in those cases is accurate, not missing telemetry.
Trace the device to its actual resolver
If a fresh test receives an answer but never reaches the expected resolver, inventory the resolution path. Check browser Secure DNS, application-specific DNS, operating-system encrypted DNS, VPN-provided DNS, security software, manual IPv4 and IPv6 settings, and the resolver advertised by the current network. A device can switch paths when it roams from office Wi-Fi to a guest network or cellular connection.
RFC 9076 describes how applications may choose their own recursive resolver rather than the system service.3 That choice is not automatically malicious or broken; it may be a privacy feature, managed configuration, or VPN behavior. Compare the observed destination with the intended ownership model. Correct the authoritative selector instead of adding domain rules to a resolver that never sees the query.
Check split paths explicitly. IPv4 and IPv6 can use different configuration, and a proxy may resolve names on the device’s behalf. If the application sends traffic through a remote proxy, the local DNS service may have no query to record. Document who performs resolution before treating the absence as a telemetry defect.
Match the query to the right resource
When the intended resolver receives the test but the expected resource view is empty, inspect attribution. Compare the source address, resource identifier, network attachment, resolver credential or token where applicable, and profile assignment. Address translation, shared networks, stale device names, re-enrollment, or a changed attachment can make the event appear under another legitimate resource.
Do not merge identities or rename resources until the test proves the mismatch. First locate the exact timestamp and hostname in the permitted scope, then compare its attribution with the device’s current configuration. Preserve the old and new identifiers, explain why they differ, and correct the owning attachment. A display label alone is weak evidence because names can be duplicated or stale.
| Observed result | Likely boundary | Next check |
|---|---|---|
| No client answer | Device or network | Connectivity, local error and resolver reachability |
| Answer, no expected resolver event | Resolver selection | Browser, OS, VPN, proxy and network settings |
| Resolver event under another resource | Identity or attachment | Address, credential and profile mapping |
| Correct event outside the view | Visibility query | Time, timezone, action and permitted scope |
Audit the visibility window with restraint
Verify the viewer has the appropriate scoped role, then check time range, timezone, resource filter, action filter, hostname filter, and whether the view shows aggregate or detailed retained activity. A block-only view will not show allowed tests; a current-day filter can miss a timestamp recorded in another timezone. Also confirm that the test falls within the configured retention window.
Use least visibility throughout. Start with resolver health and aggregate counts. Open detailed activity only for the named resource, harmless hostname, and shortest useful window. DNS filtering can act on domain lookups and policy outcomes, but it cannot see page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. A lookup also does not prove what a person intended to view.
- Do not enable broad history before proving that a fresh query reaches the expected resolver.
- Do not treat an empty filtered view as evidence that storage or ingestion failed.
- Do not clear every cache before recording the device’s actual resolver selection.
- Do not change DNS policy when the fault belongs to identity, visibility, or connectivity.
- Do not infer browsing intent from a technical lookup event or its absence.
Use a control to locate the missing layer
Run the same harmless lookup from one known-good resource in the same policy scope. If both events are absent, inspect resolver health and the shared visibility path. If the control appears but the target does not, compare resolver selection and identity. If the target appears only in an unfiltered permitted search, correct the saved view or attribution rather than the device policy.
Finish with two fresh results from the target: one expected allowed answer and one harmless provider-owned blocked test or policy preview. Confirm both are attributed to the correct resource and visible only to the appropriate role. Record network, resolver, resource identity, profile, timestamps, filters, outcomes, root cause, correction, and review owner. Then close the detailed window and return to aggregate monitoring.
Missing-activity questions
Does an empty DNS activity view mean the device is offline?
No. The device may be online while reusing cached DNS answers or open connections, using a browser, VPN, or application resolver, switching to cellular data, or appearing under another identity. Generate one fresh test lookup and trace its destination before drawing conclusions from an empty view.
Should I enable detailed DNS history for every device to diagnose this?
No. Start with aggregate health, then open the smallest detailed view needed for the named resource, test hostname, and short time window. Broad collection can expose unrelated activity without fixing a routing or identity problem. Close the detailed review after the path is confirmed.
Can a blocked site load even when no new DNS event appears?
Yes. A client may reuse a cached address, existing connection, service worker, proxy result, or locally stored content. A loaded page does not prove a new lookup bypassed policy. Wait for an appropriate fresh query or use a harmless unique test hostname, then observe which resolver receives it.
Inspect one Veilty resource path
In Veilty, trace one resource inside its household Space or team Tenant. Reusable baseline and enforced policies belong to that scope; a resource may override baseline policy when permitted, but cannot weaken enforced policy. Account invitations create membership only, and accepted members need an assigned Space or Tenant role for scoped access. Retained activity belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver necessarily processes live requests. Generate one harmless lookup, confirm its resolver and identity, then review only its shortest permitted activity window.