Buyers can avoid DNS policy lock-in by requiring a documented export of owned rules, profiles, scopes, priorities, sources, and exceptions in a stable readable format, then rehearsing a migration before purchase. Keep credentials and unrelated activity out of policy exports, record unsupported semantics explicitly, and verify cancellation, deletion, and continued resolver operation separately.
The practical outcome is a set of portability questions and one tested exit path. Portability does not mean every provider can reproduce every feature automatically. It means the buyer can recover the policy intent it owns, understand what will be lost or translated, rebuild the important outcomes elsewhere, and close the old service without discovering that the useful configuration exists only as screenshots.
Define portability before contract signing
List the policy objects that would be expensive to recreate: exact allow, block, and redirect rules; category or filter-set choices; profiles; resource assignments; baseline and mandatory boundaries; schedules; local exceptions; owners; reasons; review dates; and source references. Rank them by importance. A family with ten exact rules and a team with many purpose-specific resources need different exit guarantees.
Ask for the export method, format, schema documentation, versioning, limits, availability by plan, and behavior after cancellation. Determine whether an ordinary authorized administrator can create it without vendor support and whether the file is complete enough to review offline. Require a sample early. Contract language that promises “your data” is less useful than an exercised procedure naming objects, fields, timing, readers, and deletion.
Ask what an export preserves
| Policy concern | Portability question | Migration check |
|---|---|---|
| Identity | Are stable names and buyer-owned identifiers included? | Map every profile and resource without guessing |
| Match | Are exact domains, wildcards, categories, and sources distinct? | Rebuild the intended match rather than flattening it |
| Action | Are allow, block, redirect, and other results explicit? | Flag unsupported actions before switching |
| Scope | Are assignments, inheritance, and mandatory boundaries visible? | Recreate who receives each decision |
| Precedence | Can the winning rule be predicted after import? | Test conflicts and exceptions deliberately |
| Lifecycle | Are owners, reasons, dates, status, and schema version present? | Retire stale rules instead of preserving them forever |
Prefer a documented structured format when the policy has nested scope or precedence. CSV can work for a simple table, but it should declare encoding, columns, enumerations, null behavior, and schema version. JSON or another structured representation can preserve relationships, yet a file extension alone proves nothing. Validate it against documentation, inspect it with ordinary tools, and reject undocumented opaque identifiers as the only description of a rule.
Keep source provenance. A category name such as “security,” “adult,” or “social” may refer to different definitions and underlying lists across services. Record the source, version or retrieval time where available, local modifications, and desired outcome. Export exact domains separately from subscriptions to changing sources. During migration, compare behavior with a safe test matrix rather than assuming two category labels are interchangeable.
Separate policy from sensitive state
A policy export should not silently become a credential archive. Exclude resolver tokens, client secrets, private keys, recovery secrets, session material, and reusable authentication values. Replace secret references with a documented requirement to issue new credentials at the destination. Encrypt the export in transit and at rest, restrict its readers, record custody, and delete working copies when the migration closes.
Keep retained DNS activity separate too. DNS filtering acts on domain lookups and policy outcomes; it cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. Even so, a sequence of domain queries can be sensitive. RFC 9076 discusses privacy risks from DNS transactions and correlation.1 Migrate activity only for a named requirement, not because the export button makes collection convenient.
Policy exports also cannot capture endpoint state they do not own. A device may use another resolver because of a browser choice, VPN, relay, mobile connection, or local configuration. Record the desired coverage and identity model, but verify it separately at the destination. RFC 9499 distinguishes resolvers, queries, responses, and caches; portable policy intent does not itself redirect a client to the new resolver.2
Rehearse a policy migration
- Create a small representative policy with an exact allow, exact block, redirect where needed, category source, profile, scoped assignment, and narrow exception.
- Export it through the documented ordinary administrator path and record the schema version, time, owner, and integrity value.
- Inspect the file offline for readable values, complete relationships, undocumented identifiers, secrets, and unrelated activity.
- Map every source concept to the destination as equivalent, translated, unsupported, or intentionally retired.
- Rebuild the policy in a non-production destination and review precedence before directing any representative resource to it.
- Run harmless expected allow, block, redirect, conflict, and ordinary application tests through the destination resolver.
- Rehearse rollback, credential rotation, old-service cancellation, retained-data deletion, and removal of temporary export copies.
- Record elapsed effort and unresolved losses, then decide whether the exit cost is acceptable before purchase.
Do not make the trial a production cutover. The goal is to prove that policy meaning can leave and be reconstructed, not to prescribe platform-specific configuration steps. Use an isolated destination or paper mapping where a live second system is unavailable. Repeat the exercise after major policy-model or schema changes, and keep the export procedure owned rather than waiting for contract renewal.
Recognize portability theater
- Do not accept screenshots or printable reports as the only machine-readable policy record.
- Do not accept a domain list that silently drops scope, precedence, actions, sources, or exception lifecycle.
- Do not export credentials or broad retained activity merely because they are technically available.
- Do not call a migration complete until representative effective outcomes pass on the destination resolver.
- Do not assume account deletion removes exports, backups, support copies, or files held by the buyer.
DNS portability answers
Is a CSV file enough for DNS policy portability?
Only if it preserves every policy concept you need with documented fields and unambiguous values. A flat domain-and-action list may omit profiles, resource scope, category sources, precedence, enforced status, redirects, exception ownership, and review dates. Test reconstruction in another system instead of treating file creation as proof of portability.
Should a DNS policy export include activity logs?
Not by default. Policy configuration and retained activity serve different purposes and carry different privacy risks. Export only the evidence required for a named legal, security, or support need, with authorized readers and deletion dates. A migration usually needs rules and scope, not a broad history of household or employee lookups.
Can every DNS provider import another provider's policy exactly?
No. Providers can differ in category definitions, source lists, rule precedence, resource identity, redirect actions, scheduling, inheritance, and enforced-policy semantics. A good export makes those differences discoverable. Map each concept, record losses, and retest effective outcomes rather than assuming two labels produce equivalent behavior.
Document a Veilty policy boundary
For a Veilty evaluation, document the family Space or team Tenant, reusable baseline and enforced policy, attached resources, profiles, filter sets, rule sets, exact actions, and permitted exceptions that make up the outcome. A resource may adapt baseline policy when permitted but cannot weaken enforced policy. Treat that semantic inventory as the buyer-owned migration requirement; do not assume a specific export or import capability unless it is demonstrated.
Veilty processes live DNS requests to apply policy. Retained Space or Tenant activity is end-to-end encrypted with user-held keys and available only through permitted scoped roles. Keep activity outside the portability exercise unless a named need justifies it. Ask the same export, schema, role, deletion, and reconstruction questions, then verify one profile, rule, redirect, or visibility outcome before treating the exit path as acceptable.