A baseline DNS profile should contain common, low-regret rules that most resources in its assigned Tenants need: well-supported threat protection, a small number of organization-wide decisions, clear logging and retention choices, and an owner. Keep enforced requirements, one-off application exceptions, device-specific preferences, and non-DNS controls out of the baseline.
Make the baseline boring enough to reuse
The baseline is the starting policy for resources in the Tenants where it is assigned. It should be unsurprising, explainable, and stable across ordinary work. If a rule exists for one developer tool, one visiting vendor, or one temporary campaign, it is not baseline material. If a decision is so important that no local resource may weaken it, it belongs in enforced policy rather than relying on convention.
NIST CSF 2.0 describes organizational profiles as a way to tailor and prioritize security outcomes around objectives, threats, and requirements.2 A reusable DNS baseline applies that discipline narrowly: choose outcomes shared by its Tenants, separate mandatory controls from adaptable defaults, and make exceptions visible rather than hiding them in an ever-growing common profile.
Include common, low-regret decisions
| Candidate | Include when | Check |
|---|---|---|
| Threat-domain protection | Evidence and maintenance are strong | False positives have a support path |
| A small shared category set | The affected Tenants have agreed on it | Real work remains functional |
| DNS outcome visibility | It answers a named support or security need | Retention and access are limited |
| Ownership metadata | Always | Owner and review trigger are current |
| Known safe test cases | Always | Allowed and blocked outcomes are reproducible |
CISA describes protective DNS as analyzing DNS queries and preventing connections to known or suspected malicious infrastructure.3 That makes maintained malicious-domain protection a sensible common candidate. It does not make every security or productivity category equally suitable. Broader categories can affect legitimate services and workplace expectations, so require a stated outcome, agreement, a pilot, and a support route before making them common.
Include governance with the rules: a policy owner, a plain-language purpose, affected Tenants, the source and maintenance expectation for lists, allowed and blocked test domains, retained-activity purpose, access boundary, retention choice, and review trigger. A clean baseline is not merely a set of switches. It is a decision another administrator can verify without guessing.
Move four kinds of decisions elsewhere
- Put non-negotiable protection in an enforced policy so a Tenant resource cannot weaken it.
- Put one-off domain allowances and blocks on the smallest Tenant resource that needs them.
- Put application paths, page content, identity permissions, and file controls in application or identity systems.
- Put network isolation, endpoint posture, patching, and traffic inspection in their owning network or device controls.
DNS filtering works on domain lookups and policy outcomes. It cannot inspect URL paths, page contents, search terms, files, in-app chats, voice audio, or full browser history. It cannot prove that an application connection completed or that a human initiated a lookup. RFC 9499 defines DNS as a query-response protocol; keep baseline claims inside that boundary.4
Avoid broad allowlists in the baseline. An allow rule can bypass useful filtering for every assigned resource, and a wildcard can include services the original reviewer never considered. When an application needs an exception, observe the failure, identify the exact hostname, confirm ownership and purpose, apply the narrowest resource-level change, and give it a review trigger.
Separate adaptable defaults from mandatory protection
A baseline says, “start here unless this Tenant resource has a justified difference.” An enforced policy says, “this protection applies even when a resource differs.” Confusing them causes two opposite failures. Treating every preference as enforced prevents legitimate work; treating a mandatory control as baseline lets a local override weaken it. Write the reason for each placement in language a non-specialist owner can challenge.
Use three questions. Would an exception create a material risk beyond the affected resource? Must the decision remain consistent across every assigned Tenant? Is there an accountable approval path for changing it? Strong yes answers point toward enforced policy. If teams may reasonably differ and a local reviewer can own the result, baseline is more likely. Revisit the placement when threats, legal requirements, or business dependencies change.
Exercise policy precedence with real work
- Choose one ordinary resource in each assigned Tenant and confirm the expected baseline.
- Test a harmless allowed domain and a harmless domain expected to be blocked.
- Run a representative workflow such as sign-in, document sync, payment, or software update.
- Add a temporary resource-level baseline override and confirm it affects only the intended resource.
- Confirm enforced Tenant policy still takes precedence and cannot be weakened by that resource.
- Remove the test exception and record the verified outcome.
A successful DNS answer is not enough. Confirm the real workflow separately, because authentication, routing, certificates, application policy, or an upstream service may still fail. When evidence is uncertain, observe first and change only the narrowest relevant rule. Do not solve one ambiguous error by weakening the common baseline for every Tenant.
Review drift, not just blocked requests
Quarterly or after a material workflow change, review whether each baseline rule is still common, whether exceptions have accumulated, whether a default should become enforced, and whether an enforced rule still reflects the stated risk. Compare affected Tenants rather than assuming they remain identical. Remove stale entries and move local needs back to their owning resources.
In Veilty, baseline and enforced policies can be reused across Tenants. Resources inside a Tenant may override its baseline but never its enforced policy. Invitations add people to the account; accepted members receive Tenant access only through assigned roles. Retained history belongs to its Tenant, is end-to-end encrypted with user-held keys, and is visible only to permitted Tenant roles, while live DNS requests still require resolver processing.1 Start by removing one local exception from the baseline and placing it on the resource that actually owns the need.
Baseline-profile questions
Should malware and phishing protection be in the baseline?
Common, well-supported threat protection is a strong baseline candidate. If a protection must never be weakened by a Tenant resource, place it in an enforced policy instead.
Should a one-off application allow rule go in the baseline?
Usually no. Put the narrow exception on the smallest Tenant resource that needs it, record the owner and reason, and review it when the application or workflow changes.
Can one baseline be reused across several Tenants?
Yes. Baseline policies are reusable across Tenants. Each Tenant resource may override its baseline for a justified local need, but it cannot weaken an enforced policy.