A modern app often uses separate domains for sign-in, APIs, content delivery, storage, updates, telemetry, and tenant-specific services. Allowing its visible domain may open only the first screen. Trace the exact failing journey, identify each necessary hostname from reproducible evidence, and allow the smallest dependency set rather than a vendor-wide wildcard.
The useful unit of troubleshooting is not “the app” but a specific journey: sign in, open a document, join a meeting, sync a file, or receive an update. Each journey can depend on a different set of names. Define the outcome before observing traffic so optional background activity does not become part of the allow rule by accident.
Think in journeys, not brand names
DNS names organize administration and delegation, not product boundaries. RFC 1034 describes a hierarchical namespace whose zones can be managed separately.1 A company can place its public site, identity service, APIs, storage, and regional infrastructure under different names or delegate parts to delivery and cloud providers. Conversely, one shared hostname can serve many products and customers.
That architecture explains why the brand domain in a browser is incomplete evidence. A desktop client may authenticate through a system browser, fetch configuration from an API, download code from a content network, and keep a connection to a regional service. Mobile and web versions can use different paths. Do not infer the complete dependency set from a logo, certificate organization, or one successful home page.
| Journey stage | Possible dependency | Proof that matters |
|---|---|---|
| Launch | Configuration or update host | App starts cleanly |
| Authenticate | Identity and callback hosts | New session completes |
| Use core feature | API, storage, or media host | Named task succeeds |
| Close and return | Session or sync host | State persists correctly |
Build a minimum dependency set
- Choose one affected device, app version, network, profile, and five-minute test window.
- Write the exact journey and its expected result before reviewing DNS activity.
- Reproduce once and mark the last successful step and first failed step.
- Confirm the device used the intended resolver and identify the policy decision for candidate names.
- Add one exact, documented dependency at the narrowest supported scope, then replay from a fresh session.
- Stop when the journey succeeds; do not promote every nearby hostname into the exception.
Use official application network-requirement documentation when it exists, but verify the relevant subset. Published lists often cover multiple products, platforms, regions, administrative features, or optional integrations. Record which entry supports your journey and when it was reviewed. If the app publishes no requirements, ask its owner rather than guessing from an unrestricted browsing capture.
Separate essential from incidental traffic
A lookup during the test does not prove dependency. RFC 9076 notes that DNS traffic may result from embedded resources, prefetching, advertising, applications, or malicious activity, not only deliberate navigation.2 Require a repeatable relationship: the named task fails when the hostname receives the restrictive outcome and succeeds when the narrow exception applies, with other relevant variables held stable.
- Essential: the journey reproducibly stops when the dependency is blocked.
- Conditional: the dependency is required only for a platform, region, feature, or authentication method.
- Optional: analytics, diagnostics, advertising, or convenience behavior can fail without breaking the task.
- Unknown: traffic appears nearby but has no demonstrated effect; leave it out while investigating.
DNS cannot inspect page contents, full URLs, API paths, search terms, files, in-app chats, voice audio, or full browser history. If an essential feature and an unwanted feature share a hostname, DNS cannot allow one path and block the other. Choose an application, endpoint, proxy, or identity control that understands the required layer rather than trying to encode paths as domains.
Test the set against real work
Retest from the original device and network with a new application session. Complete sign-in and the named core action, then exercise a second common action that should remain available. Verify a representative blocked destination still receives the enforced outcome. Check both IPv4 and IPv6 paths when the environment supports them, and compare native, browser, and mobile variants only when users actually rely on them.
Review rule precedence as part of the proof. In Veilty, a resource may override reusable baseline policy when permitted but cannot weaken enforced Space or Tenant policy. If the dependency is blocked by enforced policy, involve its owner rather than creating an ineffective lower-scope allow. The observed resolver decision, not the newest configuration entry, tells you which rule won.
Maintain the exception as the app changes
App dependencies change with releases, provider migrations, regions, and enabled features. Record the journey, exact names or maintained catalog, affected scope, supporting documentation, owner, and review date. When a new failure appears, compare it with the existing set before widening it. Remove names that no longer support a required journey instead of letting the exception grow forever.
Keep detailed activity only for the named troubleshooting window and authorized readers. Aggregate policy outcomes are normally enough for routine health. A dependency inventory should document why access exists; it should not become a long-lived record of individual browsing.
Multi-domain app questions
Should I allow every hostname an app contacts?
No. Apps contact optional analytics, advertising, diagnostics, and shared delivery services as well as essential dependencies. Start from a named user journey, correlate failures with policy decisions, and add one proven hostname at a time. A hostname appearing during the test is a candidate, not automatic permission.
Is a wildcard the easiest way to keep an app working?
It may be easy, but it is rarely the safest first choice. A vendor domain can cover unrelated products, user content, or future services. Prefer documented exact hosts, authentication-specific catalogs, or a narrowly reviewed suffix only when the application genuinely uses dynamic names beneath it.
Can DNS filtering allow one path or feature inside a domain?
No. DNS decisions concern domain lookups, not URL paths, page elements, API methods, or individual account actions. When required and unwanted functions share one hostname, use application permissions, an HTTP-aware gateway, endpoint controls, or the service’s own administration features.
Scope one Veilty app exception
In Veilty, begin with one affected resource and one named app journey inside its Space or Tenant. Review the shortest useful activity window through a permitted role; retained history is end-to-end encrypted with user-held keys, while live requests still must be processed by the resolver. Map the matched baseline, enforced, resource, or catalog decision, allow only a proven dependency where policy permits, then verify the task and the original block.