To find the domain a broken app feature needs, isolate one failed action, record its device and exact time, then compare fresh DNS requests and application network requests immediately before and after that action. Identify the hostname whose blocked result consistently aligns with failure, allow it at the narrowest scope, and retest the complete workflow.
The job is dependency discovery, not making every red row disappear. Preserve the current policy while you build a controlled comparison. Broad category or wildcard allows often restore the feature, but they erase the evidence, expand trust unnecessarily, and leave support unable to explain which dependency was actually required.
Turn the feature into a repeatable test
Describe one observable action: signing in, loading an image, saving a document, receiving notifications, or starting a call. Record the app version, device, network, resolver path, resource or profile, exact local time with timezone, expected result, and visible failure. Reset only the minimum app state needed to repeat it.
- Run the action once with the current policy and mark its start and failure times.
- Run a nearby working action in the same app to create a comparison window.
- Capture fresh DNS outcomes for the affected resource during both windows.
- When authorized, capture application network requests with sensitive fields minimized.
- Repeat the failed action once to separate stable dependencies from unrelated background noise.
Do not begin with an hour of device-wide DNS history. RFC 9076 explains that applications, advertisements, embedded resources, prefetching, and intentional navigation can all produce queries.1 A short, repeated action creates a far better signal and reduces the private activity collected for diagnosis.
Correlate DNS with the request chain
List hostnames first seen or blocked near the failed action. Then use app documentation, browser initiator information, or approved endpoint tooling to connect requests to the feature. Chrome DevTools can preserve requests across page loads, show request initiators, and filter by domain; its documentation also warns that exported HAR files can contain sensitive information and provides a sanitized export.2
Keep protocol layers distinct. A DNS block may prevent the app from obtaining an address. An HTTP status, TLS error, CORS failure, authentication denial, or server error occurs later and may not be fixed by DNS. If the hostname resolves successfully but the application request fails, follow the owner of that application or network layer rather than adding a DNS allow.
DNS filtering can act on domain lookups and policy outcomes, but cannot inspect page contents, full URLs, search terms, in-app chats, voice audio, request bodies, or full browser history. Use authorized application evidence for those questions. Never upload an unsanitized capture merely to prove a domain appeared.
Rank candidates before allowing anything
| Signal | Stronger evidence | Weak evidence |
|---|---|---|
| Timing | Appears on every failed action | Appears once in a long window |
| Initiator | Feature request or documented dependency | Unrelated background process |
| Policy result | Blocked at the intended resolver | Allowed or absent from that resolver |
| Comparison | Absent from the nearby working action | Present in both working and failing actions |
| Test | Exact-host allow restores only the feature | Broad category allow changes many things |
Prefer an exact hostname supported by multiple signals. Parent domains and wildcards can cover unrelated services or future names. A shared identity, storage, telemetry, or delivery hostname may also serve many products, so confirm its owner and purpose before changing policy. If ownership is unclear, ask the application vendor for an official endpoint list rather than guessing from registration data alone.
Test one hostname, then the whole journey
Apply a temporary exact-host exception to one affected resource or purpose-based test profile. Do not change shared enforced policy. Repeat the isolated feature, then test sign-in, saving, updates, and one representative protective block. A feature that starts working is useful evidence, but repeat it after a fresh lookup and verify that the candidate hostname actually received the allowed action.
If the feature still fails, remove the unproven exception before testing the next candidate. Do not accumulate allows until something changes; that produces an unknown dependency set. If several hostnames are genuinely required, add and verify them one at a time, recording why each is necessary and whether its ownership or function changes the risk decision.
Write a dependency record support can reuse
Record app and feature, exact hostname, owner, evidence, affected resource, matched block source, approved exception scope, test results, approver, expiry or review trigger, and a link to official vendor documentation when available. This turns a one-off rescue into a reviewable dependency and makes later vendor changes easier to spot.
After closure, return to aggregate outcomes. Detailed DNS and application traces should remain limited to the named purpose and time window. Remove temporary captures according to policy, especially network archives containing identifiers or credentials. The durable record should explain the decision without preserving a person’s unrelated activity.
Domain-discovery questions
Does every blocked hostname near the failure need an allow rule?
No. Apps generate background, analytics, update, advertising, and prefetch requests that may be unrelated to the failed action. A hostname becomes a strong candidate only when timing, initiator evidence, repeated comparison, and a narrow test connect it to the required feature.
Can DNS logs identify the exact button or screen that failed?
No. DNS records domain lookups, not interface actions, full URLs, request bodies, or page contents. Pair a short DNS window with authorized app or browser network evidence and the tester’s timestamp; do not infer an action from a hostname alone.
Should I export a full browser network archive for support?
Only when necessary and authorized. Network archives may contain cookies, tokens, URLs, form data, and other sensitive material. Prefer a sanitized export, minimize the capture window, review it before sharing, and delete it under the applicable retention process.
Scope one Veilty exception
In Veilty, attach a verified exception to the resource inside the household Space or team Tenant that owns the dependency. Reusable baseline and enforced policies can apply across those scopes; a resource may override baseline policy when permitted, but cannot weaken enforced policy. Invitations provide account membership only, and accepted members require assigned Space or Tenant roles 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 live requests must be processed by the resolver. Managed BYOD support is planned for enterprise use, so test supported resources rather than promise personal-device management. Review one short failure window and one exact hostname.