A remote team can keep DNS protection consistent by defining reusable baseline and enforced Tenant policies, applying them where managed endpoints actually resolve DNS, and testing each normal network path. Do not rely on the office router after laptops leave. Start with high-confidence threat protections, decide which component owns DNS, and verify home, hotspot, hotel, coworking, and VPN behavior.
Write the baseline as testable promises
A baseline is not a long category checklist. Write it as a small set of promises every in-scope work endpoint must keep wherever work happens: use the approved resolver, apply the intended response to high-confidence malicious domains, preserve essential workflows, and leave enough evidence for an authorized role to investigate a specific security or reliability question.
| Requirement | Verification | Separate control |
|---|---|---|
| Approved resolver path | Resolver identity test on every normal network | Device management or secure client |
| Malicious-domain protection | Provider-owned safe test method | Endpoint and email security |
| Work continuity | Critical journey checklist | Application support process |
| Narrow visibility | Role and purpose review | Privacy and retention practice |
| Incident readiness | Harmless reporting exercise | Identity, device, and response plan |
CISA describes protective DNS as a safeguard that prevents connections to known or suspected malicious domains and provides useful visibility.2 NCSC similarly emphasizes malicious-domain blocking, deployment, and response considerations.3 Neither presents DNS as a complete remote-work program. Multifactor authentication, phishing-resistant sign-in where possible, software updates, endpoint protection, backups, email defenses, and human verification remain essential.
Separate baseline from enforced policy. Reusable baseline Tenant policy supplies defaults that a Tenant resource can override narrowly when legitimate work requires it. Enforced Tenant policy protects rules that resources must not weaken. Enforcing everything makes valid exceptions painful; enforcing nothing lets important safeguards disappear. Document the reason and owner for each enforced choice.
Design for the network that changes
Remote laptops cross trust boundaries throughout a week. A home router may supply an internet provider’s DNS. A browser can enable Secure DNS. A VPN may send lookups to its own resolver. A hotel can require a captive portal before normal resolution works. A mobile hotspot changes networks again. Configure the control on the managed endpoint or through an approved service that follows it, then document which component owns DNS in each mode.
DNS services cover different jobs and deployment models. Some apply filtering at a router, others identify endpoint or roaming-client policy, and mobile tools may combine DNS with local firewall controls. Smart DNS proxy services often focus on location-based media access instead of organizational protection. A service “using DNS” therefore does not prove it can carry a remote security baseline. Choose by outcome, supported device path, policy ownership, and a verification method.
- Inventory company laptops, phones used for work, contractors, and shared or lab devices separately.
- List home Wi-Fi, office, coworking, hotel, customer site, hotspot, and approved VPN paths.
- Decide whether endpoint management, a resolver client, or the VPN owns DNS for each path.
- Prevent accidental alternate-resolver use through supported device controls, not assumptions.
- Document the recovery path when DNS configuration blocks sign-in, updates, or a captive portal.
Roll out with a roaming test matrix
- Choose one representative managed laptop and record its current resolver behavior.
- Attach the reusable security baseline with malware, phishing, scam, and command-and-control protection.
- Test resolver identity and a provider-owned safe block method on home Wi-Fi and a hotspot.
- Enable the approved VPN and repeat both tests. Resolve ownership if DNS changes unexpectedly.
- Complete sign-in, video meetings, email, file sharing, updates, source control, payments, and support tools.
- Test a captive-portal workflow safely, including the documented temporary recovery route.
- Expand in small groups, record failures by network mode, and retest after every policy change.
Use safe test domains or documented provider checks. Never browse to a live malicious address. Confirm both positive and negative behavior: an ordinary approved domain should resolve, and the safe test should receive the intended block or redirect. A screenshot of a policy setting is not proof that the endpoint used it.
DNS filtering cannot inspect page contents, search terms, messages, downloads, in-app chats, voice audio, or full browser history. It may miss a new threat, direct IP traffic, cached answers, or traffic sent through another resolver. If the team needs file inspection, browser controls, device isolation, data-loss prevention, or identity enforcement, choose controls designed for those jobs.
Keep remote exceptions small
Remote work creates pressure for fast exceptions because the affected person may have no nearby support. Provide a clear report path and a named backup reviewer. Ask for the service, failure time, network mode, and business impact. Verify which rule acted before changing it. Allow only the required domain or resource, attach an owner and review date, and retest the original protection afterward.
Review aggregate policy outcomes routinely. Open detailed retained history only for a named security, coverage, or compatibility question and only through authorized Tenant roles. A request from a remote endpoint is not proof of personal intent; background software and shared page dependencies also generate lookups. Trust improves when collection and access have declared limits.
Once a month, sample each network mode, review devices that have not checked in, remove stale exceptions, and rehearse one harmless report. Also review contractors and departed staff: invitations are account-scoped, while access to a Tenant and its history is determined by roles. Removing access should be part of offboarding, not an informal reminder.
Remote baseline questions
Is router DNS enough for remote employees?
Usually not. Router DNS protects only while the device uses that network and resolver path. Endpoint configuration or an approved secure client is needed when laptops move among homes, hotspots, hotels, and coworking spaces.
Should remote workers use both a VPN and protective DNS?
They can, but the organization must define which service owns DNS and test the combination. A VPN may replace the configured resolver. DNS filtering and VPN encryption solve different problems.
Can DNS policy monitor what remote employees do inside websites?
No. DNS can record domain lookups and policy outcomes, not page contents, search terms, messages, documents, voice audio, or full browser history. Use the least visibility needed for security and reliability.
Apply a Tenant baseline in Veilty
Create a Veilty Tenant for the remote team, then apply reusable baseline and enforced Tenant policies. Attach one endpoint and complete the roaming matrix before adding the next group. Tenant resources may override baseline policy for a narrow legitimate need, but cannot override enforced policy. Use Tenant roles to limit retained-history access, keep exceptions owned and dated, and repeat coverage tests after network, VPN, browser, or policy changes.1