After a router change, confirm which resolver each home network advertises, which devices override it, and which family policies still apply. Review main, guest, and IoT paths separately; preserve only justified exceptions; then test one allowed domain and one known policy outcome. Record off-network limits and inspect only the minimum activity needed to verify the migration.
Migrate the policy, not the control panel
A replacement router changes more than a box. It may advertise different DNS resolvers through DHCP, create new main and guest network boundaries, handle IPv6 differently, or restore an ISP default. Google Public DNS documents that DHCP commonly supplies resolver addresses automatically and that devices can also hold explicit settings.1 The useful review begins with the household outcome you meant to preserve, not with copying every field from the old interface.
Write a short before-and-after statement: which risks should be blocked, which legitimate services must work, which devices need a narrower rule, and where coverage is expected to stop. Keep the old configuration available as a reference, but do not assume its addresses are still appropriate. They might identify an ISP resolver, an old local forwarder, or a service you no longer intend to trust.
Treat router security separately from DNS policy. NIST’s consumer-grade router profile covers product security outcomes because the router is a critical home-network component.2 Update supported firmware, replace default administration credentials, and review remote-management exposure through the manufacturer’s current guidance. Those actions protect the router; they do not prove that family DNS policy reaches every device.
Rebuild the resolver-path map
Map where DNS decisions happen before changing policy. The new router may forward queries itself or advertise another resolver directly. IPv4 and IPv6 clients may receive different answers. Guest and IoT networks may inherit the main setting, use an ISP default, or isolate clients behind another forwarding path. Record observed behavior rather than inferring it from a single settings page.
| Path to review | Question to answer | Evidence worth keeping |
|---|---|---|
| Main Wi-Fi and Ethernet | Which resolver is advertised for IPv4 and IPv6? | Expected resolver and one dated test |
| Guest Wi-Fi | Does it share policy or use an intentionally separate scope? | Allowed and policy-test outcomes from a guest device |
| IoT segment | Can appliances reach a different resolver or vendor tunnel? | One representative device result and any known gap |
| Managed devices | Does a work, school, VPN, browser, or OS policy own DNS? | Owner and boundary, without removing required controls |
| Off-network use | Should policy follow a phone or laptop away from home? | Documented expectation for cellular and other Wi-Fi |
Do not make a product-by-product setup inventory. Group devices by meaningful resolver path: ordinary router clients, guest devices, IoT resources, endpoint-managed devices, and required VPN or work profiles. Test one representative of each group, then investigate exceptions. This keeps the review maintainable while still revealing when a television, browser, or phone resolves somewhere the router cannot govern.
Reconcile rules with the new boundaries
- List the shared household rules, any non-overridable safety boundary, resource-specific variations, and temporary exceptions in plain language.
- Match each rule to a resolver path that the new network can actually deliver; mark unsupported paths as gaps rather than pretending they are covered.
- Review guest and IoT behavior independently. A visitor should not inherit private household visibility merely because the network name changed.
- Recheck every allowance, redirect, or bypass carried from the old router. Keep an exception only when its owner, purpose, and review point are still clear.
- Preserve work, school, accessibility, and security controls owned by another administrator. Record the boundary instead of disabling them for uniformity.
- Choose a fallback for resolver failure and write down whether it fails closed, uses another approved resolver, or temporarily loses filtering.
A rule is effective only where requests reach the resolver that applies it. Browser Secure DNS, operating-system encrypted DNS, VPNs, relays, application-specific resolution, direct IP use, caches, and cellular data can create another path. Encrypted transport protects DNS messages on the way to a resolver; it does not make every resolver equivalent or hide requests from the resolver itself.3
Run a small, deliberate test matrix
For each important path, test one ordinary allowed domain and one domain with a known policy outcome. Use a fresh session so an existing connection is less likely to mask the result. Confirm the intended resolver when a supported diagnostic is available, then check the corresponding allowed, blocked, or redirected outcome. A browser page alone is weak evidence because caches, multiple hostnames, captive portals, and unrelated network failures can change what appears.
- Test a normal device on main Wi-Fi and, if relevant, Ethernet.
- Test one guest device without granting it household-level history access.
- Test a representative IoT resource through the behavior it normally uses.
- Test an endpoint-managed phone or laptop both at home and on its expected off-network path.
- Confirm essential sign-in, update, messaging, school, work, and accessibility journeys still function.
- Record failures by device, path, time, expected result, and actual result before changing another layer.
Change one owner at a time. If all paths fail, inspect the router or upstream resolver. If only guest devices fail, inspect that network scope. If one browser differs, inspect its resolver and cached state. This sequence prevents a narrow mismatch from becoming a router-wide weakening. Keep a rollback note until the household has passed both allowed and policy tests over normal use.
Separate proof from household surveillance
Start verification with aggregate health and policy outcomes. Detailed activity is justified only when it answers a named troubleshooting question for a specific resource and short time window. Shared televisions, tablets, and networks do not identify the person who initiated a lookup. A router replacement is not a reason to expand collection or give every caregiver unrestricted access.
DNS filtering can act on domain lookups and policy outcomes. It cannot see page contents, search terms, in-app chats, voice audio, or full browser history. A DNS request does not prove that a page loaded or that a person viewed it. RFC 9076 also emphasizes that DNS data can be sensitive and that devices move through multiple network contexts.3 Keep only the evidence needed to confirm this migration.
Router-migration questions
Should I copy every DNS setting from the old router?
No. Preserve the intended resolver, policy scopes, and known exceptions, but review each value against the new router’s behavior. Old addresses may belong to an ISP, relay, local forwarder, or retired service. Treat the change as a policy migration and verify the resulting path instead of copying fields without context.
Why do some devices follow the new router while others do not?
Devices can retain manual DNS, use browser or operating-system encrypted DNS, connect through a VPN, move to cellular data, or join a different network segment. Cached answers can also delay visible changes. Compare the resolver path and policy outcome on each important device class rather than assuming one router test represents the household.
How much DNS activity should I inspect after the migration?
Use the least detail that proves the intended outcome. Start with aggregate allowed, blocked, and error signals. Open domain-level activity only for a named device, a short troubleshooting window, and an authorized household role. A successful migration does not require collecting routine browsing indefinitely.
Keep the reviewed policy in a family Space
If Veilty fits the household, represent each meaningful device or network path as a resource in its family Space and verify one resource before widening the migration.4 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 Veilty account first, then assign the minimum Space role; an invitation alone gives no Space access. Retained activity history 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 by the resolver to apply policy.