An existing session can continue after a DNS block because DNS usually supplies an address before the connection starts; it does not sit inside that connection afterward. A browser or app may reuse an open TCP, QUIC, proxy, or VPN path without another lookup. Verify the rule with a fresh connection and fresh DNS query.
This is a session-state question, not a reason to broaden the block. Capture the affected endpoint, hostname, expected rule, original connection time, and a short test window. The useful outcome is knowing whether the policy governs the next lookup while a different control governs traffic already in flight.
Separate lookup time from connection time
DNS translates a name into information an application can use to reach a service. RFC 1034 describes caching as a core part of the system, so an application or local resolver may already hold an answer when a rule changes.1 After the address is known, TCP maintains connection state independently; HTTP can reuse a persistent connection for later requests.23 A new DNS decision does not travel backward into that established state.
Modern applications add more reuse paths. QUIC can carry multiple streams over an existing connection, a VPN can keep a tunnel alive, and a proxy can resolve names on the client's behalf. Browsers may keep service workers and cached assets. The visible page can therefore keep working even when the intended resolver would block a genuinely new query.
DNS filtering can act on domain lookups and return a policy outcome such as allow, block, or redirect. It cannot read page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. It also cannot reliably distinguish two activities sharing one hostname or terminate packets in a connection it never controls.
Prove what the session reused
Begin with observation rather than cache-clearing rituals. While the original session remains open, reproduce one harmless action and note whether the intended resolver receives a query for the target hostname. No new query plus continued traffic supports connection or address reuse. A new query with an allow result points instead to rule scope, precedence, or assignment. A blocked query followed by continued use points toward another hostname, resolver, proxy, or existing connection.
- Identify one affected endpoint, exact hostname, policy action, and five-minute window.
- Confirm which resolver should receive that endpoint's query and whether it actually does.
- Note whether the application uses a VPN, secure DNS setting, relay, proxy, or alternate network.
- Compare the still-open session with a separate clean client or private profile.
- Change no policy until the comparison identifies lookup reuse, connection reuse, or a different path.
Do not treat a missing DNS event as proof of evasion. It can mean the application used a cached answer, never needed a lookup, asked another resolver, or delegated resolution to a proxy. Likewise, a nearby query does not prove what a person viewed. RFC 9076 warns that DNS traffic can reveal sensitive patterns, so keep detailed review limited to the named endpoint, domain, and troubleshooting window.4
Run a clean session-state test
- Preserve evidence from the original session before closing anything.
- Confirm the desired block is attached to the profile or endpoint expected to make the fresh query.
- Close the affected application or connection in a normal, authorized way; do not disrupt unrelated users.
- Clear only the relevant local cache when necessary, then start a new application session.
- Generate one fresh lookup and confirm the intended resolver returns the expected policy result.
- Test one representative allowed service to catch accidental collateral breakage.
Use a provider-owned test hostname or another harmless domain that is safe to test. Never browse to a live malicious destination merely to prove a security rule. If the new query is blocked but the original session continues, the DNS policy is behaving consistently with its layer. Document that distinction instead of adding a broader rule that still cannot reach the old connection.
Choose the control that owns the moment
If policy must stop active traffic immediately, use an authorized connection-aware control: revoke an application session, close a gateway connection, change firewall state, isolate an endpoint, or follow the incident-response procedure that owns the traffic. The correct choice depends on safety, business impact, and administrator authority. DNS remains valuable for preventing later resolution, but it should not be presented as a kill switch.
Avoid restarting routers, disabling encrypted DNS everywhere, or clearing every user's cache. Those actions destroy evidence, interrupt unrelated work, and may make the test appear successful without identifying the owning layer. Also avoid a wildcard block when the exact hostname and next-query outcome already answer the question.
Record a result support can repeat
Write down the endpoint, profile, hostname, rule source, expected action, resolver path, whether the original session created a fresh query, and the result after a clean reconnect. Include the narrow corrective action and an owner. This turns “the block did not work” into a repeatable statement about old and new state, which another support helper can verify without opening visibility broadly.
Open-connection questions
Does flushing the DNS cache always stop an active session?
No. Flushing a DNS cache removes stored name-to-address answers, but it does not necessarily close an established TCP connection, QUIC connection, VPN tunnel, proxy session, or application socket. Close the relevant connection or restart the affected app, then generate a fresh lookup to test the DNS rule.
Does a site loading after a block prove that DNS filtering failed?
No. The app may reuse a connection, cached address, service worker, proxy, alternate hostname, or content already stored locally. Confirm whether a fresh query reached the intended resolver and which policy result it received before changing the rule.
Can DNS filtering terminate a live download or call?
Not by itself once the transfer or call has a working connection. DNS can affect later lookups, but terminating live traffic belongs to a firewall, proxy, application, access gateway, or endpoint control that can act on the connection itself.
Verify one Veilty policy outcome
In Veilty, review the affected endpoint and its Space policy, then compare the rule result for the original session with one clean reconnect. Keep activity review scoped to the endpoint, hostname, and short time window needed for support. Veilty processes live DNS requests to answer them, while saved DNS history is end-to-end encrypted for authorized account members. Confirm one expected blocked lookup and one allowed lookup; use a connection-aware control separately if active traffic must end.