Attach a DNS rule to an endpoint when one device has a genuinely unique job, dependency, or exception. Put it in a reusable profile when several devices should make the same domain decision under one owner. Keep shared defaults in the Space or Tenant, preserve enforced Space or Tenant policy, and test the narrowest affected group before widening it.
Let the decision population own the rule
The right scope is the smallest stable population that shares one decision. “Block a known phishing domain for every company device” belongs in shared protection. “Allow the firmware host used by one meeting-room display” belongs closer to that endpoint. “Permit the package repositories required by engineering laptops” is usually a profile decision. The domain alone does not choose the owner; the devices, business purpose, failure cost, and review responsibility do.
Write the rule as a sentence before placing it: “These devices need this outcome because of this job, and this person reviews it on this date.” If “these devices” names one durable exception, use an endpoint. If it describes a recognizable class with the same needs, use a profile. If it names nearly everything in a household or organization, ask whether the decision belongs in the Space or Tenant policy instead.
| Scope | Good fit | Warning sign |
|---|---|---|
| Endpoint | One device has a verified dependency or exception | Many endpoints carry copied versions |
| Profile | A stable device class shares decisions and an owner | Membership exists only to inherit one workaround |
| Space or Tenant baseline | A shared default should apply unless a resource has a justified override | The strictest endpoint defines everyone |
| Enforced Space or Tenant policy | A rule must not be weakened by attached resources | Preferences are treated as mandatory security |
Recognize a real endpoint exception
Endpoint rules are valuable when the exception follows a machine rather than a broad type. A laboratory instrument may contact an old vendor domain. A lobby display may need a media host that staff laptops do not. A parent laptop may need a service blocked on a child device. Keeping that decision local avoids weakening unrelated resources and makes the exception disappear naturally when the endpoint is retired.
Local does not mean informal. Record the required workflow, exact hostname, observed policy result, owner, and review point. Test the real task, not merely the vendor home page. If the same exception appears on a second and third device with the same role, stop copying it. Repetition is evidence that a reusable profile may now be the honest owner.
Promote repeated decisions to a profile
A profile is useful when it expresses a stable operational class: child homework devices, parent devices, developer workstations, guest equipment, or meeting-room screens. It provides one place to explain why a rule exists and one membership list to review. A change can be tested on a representative endpoint before it reaches the rest of the profile, reducing both configuration drift and accidental blanket policy.
- Name the device population by job rather than by a vague risk label.
- List the domain outcomes members genuinely share.
- Choose one representative endpoint and one required workflow.
- Run the proposed decision narrowly and observe false blocks.
- Move repeated endpoint rules into the profile instead of retaining duplicates.
- Review membership and exceptions together when a device changes job or owner.
Do not create a profile for every device name, every temporary incident, or every domain. That reproduces endpoint sprawl under another label. A useful profile survives individual device replacement because its members share a continuing purpose. Temporary exceptions can remain attached to the affected resource with an expiry rather than distorting the profile for everyone.
Keep shared policy above both scopes
Profiles and endpoints sit inside a broader Space or Tenant policy context. Use baseline policy for defaults an attached resource may override when a reviewed need exists. Reserve enforced policy for decisions no resource may weaken. This separation prevents a device-specific preference from becoming a universal restriction, while keeping genuinely mandatory protection intact across profiles and endpoints.
DNS remains a coarse control at every scope. It can allow, block, or otherwise answer a domain lookup according to policy. It cannot inspect a URL path, webpage text, typed search, file, message, voice session, or full browser history. RFC 9076 also explains that lookups may be caused by embedded resources, prefetching, or background applications, so a request is not proof of a person’s intent.1 Use browser, application, identity, endpoint, or network controls when the decision needs those signals.
Prove ownership with two-sided tests
Test both sides of the boundary. On an affected endpoint, confirm one expected DNS outcome and complete the required business workflow. On an unaffected endpoint, confirm that its behavior did not change. Repeat through the normal browser, VPN, office, home, or mobile path because an alternate encrypted resolver can bypass the policy you intended to test. Record the endpoint, route, approximate time, and result rather than collecting broad activity without a question.
- Copying the same exception to many endpoints instead of creating an owned profile.
- Putting a personal preference in enforced Space or Tenant policy because it feels safer.
- Assuming a profile proves which person generated a lookup.
- Testing only the administrator device rather than a representative member.
- Using a broad allow when one verified dependency caused the failure.
Endpoint and profile questions
Should every endpoint have its own DNS profile?
No. Separate an endpoint only when its domain decisions, operator, failure cost, or review lifecycle differs. Devices that need the same outcomes are easier to govern through one reusable profile.
Can an endpoint exception weaken enforced Space or Tenant policy?
No. A resource may override Space or Tenant baseline policy where that is justified, but enforced Space or Tenant policy remains in force. If an enforced rule is wrong, review the enforced policy itself rather than creating a local exception that cannot work.
Does a DNS profile control pages or actions inside a website?
No. DNS policy acts on domain lookups and outcomes. It cannot see URL paths, page content, search terms, account actions, in-app chats, voice audio, or full browser history.
Model a reviewable team Tenant
If Veilty fits this ownership model, keep shared defaults in a team Tenant baseline, reserve enforced Tenant policy for non-overridable protection, and attach narrow filters or rules to the endpoint or reusable profile that owns the difference.2 Invite responsible people to the account first, then assign Tenant roles; the invitation alone grants no Tenant access. Retained Tenant history is end-to-end encrypted with user-held keys and available only where an assigned role permits it. Review a short, named troubleshooting window, then close the detail view when the decision is explained.