A family DNS device inventory should record each device’s purpose, responsible person, stable network identity, normal networks, resolver path, policy scope, expected fallback, last verification, approved exceptions, privacy setting, and retirement state. Keep shared hardware separate from people, note unmanaged or off-network paths honestly, and review the list whenever devices, networks, or responsibilities change.
Inventory the policy relationship
A shopping list of model names cannot explain why one laptop is filtered, why a television appears in another log stream, or whether a sold tablet still has an active identity. The useful unit is the relationship between a physical or virtual device, the network paths it uses, the resolver that makes DNS decisions, and the policy expected on those paths.
NIST’s consumer IoT guidance treats asset identification as the ability to uniquely identify the product and inventory its components.1 A household inventory can be lighter than an enterprise asset system while keeping the same discipline: give every resource a stable label, record enough identifiers to distinguish it, and know when it entered and left service.
Capture fields that survive a router change
| Field | What to record | Why it matters |
|---|---|---|
| Household label and purpose | School laptop, shared TV, entry camera | Explains the intended use without claiming a person |
| Identity clues | Device type, current network ID, optional serial fragment | Distinguishes similar devices after reconnecting |
| Responsible person | Who approves policy or maintains the device | Creates an owner for changes, not an activity attribution |
| Normal network paths | Trusted Wi-Fi, guest/IoT segment, Ethernet, cellular | Shows when router policy is on path |
| Resolver path | Router-supplied, device-managed, VPN-managed, unknown | Locates the DNS decision and bypass boundary |
| Policy scope | Shared baseline, enforced rule, resource rule | Makes expected outcomes reviewable |
| Verification | Allowed test, policy test, date, result | Proves the path without recording general browsing |
| Exception and review | Reason, approver, expiry or review date | Prevents permanent mystery allowances |
| Lifecycle state | Active, stored, reset, sold, recycled | Supports clean retirement |
Use identifiers proportionately. A network address can change or be randomized, so pair it with a plain household label and another clue you can verify locally. Do not put account passwords, recovery codes, full serial numbers, children’s browsing histories, or unnecessary personal details in the inventory. It should help administer policy, not become a new sensitive-data collection.
Write down who controls each layer
For each device, name the network owner, device administrator, resolver owner, and policy approver. A school laptop may be physically in the home while the school controls its VPN and DNS. A work phone may use cellular data or a managed encrypted resolver. A shared television may inherit only the router path. Recording these owners prevents a parent from “fixing” a setting that another administrator requires.
- Start with devices visible on networks you own, then reconcile them with the hardware actually present.
- Label unknown entries before assigning policy; pause or isolate only through supported controls and avoid guessing from a vendor name alone.
- Ask which resolver path each resource uses on trusted Wi-Fi, guest or IoT Wi-Fi, Ethernet, cellular, and VPN connections.
- Write the intended baseline, any non-overridable boundary, and any narrower resource rule in plain language.
- Run one allowed journey and one known policy outcome, then record the date and result rather than routine activity.
- Give every exception a reason and review point, and every resource a retirement action.
This is an inventory workflow, not a device setup guide. Use current vendor instructions for locating network identity or managed resolver information. Do not remove a work or school profile, disable a required VPN, or change locked DNS to make the record uniform. “Managed elsewhere” and “coverage unknown” are valid inventory states.
Verify without building a surveillance ledger
A verification entry needs only the resource, path, test time, expected outcome, actual outcome, and next review. DNS filtering can act on domain lookups and record policy decisions. It cannot see page contents, search terms, in-app chats, voice audio, or full browser history. A lookup also does not prove which household member used a shared device or whether an application displayed the result.
Resolver coverage is never implied by an inventory row. Device-level encrypted DNS, a browser resolver, VPN, relay, vendor tunnel, direct IP use, cached answers, or cellular data can bypass a router resolver. Record the fallback and whether policy follows the device. RFC 9076 notes that DNS privacy depends on the device and its changing network contexts, and that DNS data can be sensitive.2
Make retirement part of the record
When a device is reset, sold, donated, recycled, or replaced, remove or archive its resolver identity, revoke credentials through the owning service, and retire device-specific exceptions. Record the action and date. If a new device inherits the old network address, do not assume it inherits the old policy purpose. Verify its identity and intended scope as a new resource.
Review the inventory after router changes, network renaming, VPN installation, management changes, repeated failures, or household responsibility changes. A short quarterly check can catch devices that disappeared and exceptions that outlived their reason. The goal is a small trustworthy record, not perfect continuous discovery.
Device-inventory questions
Should a family DNS inventory include MAC addresses?
A locally administered hardware identifier can help distinguish devices, but it should not be the only identity. Some devices use private or changing addresses. Pair the current network identifier with a household label, device type, serial fragment where appropriate, normal network, and a last-verified date.
Should every family member be listed as a device owner?
List a responsible person when someone maintains or approves changes, but do not assume that person generated every request. Shared televisions, tablets, consoles, and IoT devices should be labeled as shared resources. DNS identifies a resolver context more reliably than the human using it.
How often should the inventory be reviewed?
Review it after a router migration, device reset, sale, replacement, new VPN or security app, household-role change, or unexplained policy result. A short scheduled review also catches stale identities and forgotten exceptions. Record the last successful allowed-and-blocked test rather than relying on memory.
Map the inventory to a family Space
If Veilty fits the household, map each maintained inventory item to a resource in its family Space and test one endpoint before widening scope.3 Reusable baseline and enforced policies can be assigned to Spaces: a resource may override baseline policy, but it cannot weaken enforced Space policy. Invite a caregiver to the account first, then grant the minimum Space role; an invitation alone gives no Space access. Retained activity is Space-scoped, end-to-end encrypted with user-held keys, and visible only when the role permits it, while live DNS requests still must be processed to apply policy.