Effective DNS-based web filtering manages access to external websites by blocking malicious, high-risk, and inappropriate domains before users or systems connect to them. This web filtering dns filters ultimate guide explains the control’s scope, limitations, implementation sequence, evidence, and operational checks needed to support ISO 27001 Annex A control 8.23. DNS filtering is a strong preventive layer, but it must be governed with clear policies, endpoint coverage, exception handling, monitoring, and complementary web and email controls.
What does ISO 27001 control 8.23 require?
ISO 27001 Annex A 8.23, Web Filtering, requires that access to external websites be managed to reduce exposure to malicious content. The objective is not to prohibit general internet access or to create an impractical blacklist; it is to apply risk-based controls that reduce the likelihood of malware delivery, credential theft, command-and-control communications, and access to unsafe content.
As a vCISO, I advise clients to treat this as an operating control rather than a procurement exercise. An auditor should be able to see the approved filtering standard, the technology configuration, the population covered, the block and exception process, and evidence that alerts and policy changes are reviewed.
What does web filtering with DNS filters actually cover?
DNS filtering evaluates a domain request before a browser, endpoint agent, server, or other system establishes a connection. When a device requests a domain such as malicious-example[.]com, the DNS security service compares it against threat intelligence, domain reputation, and policy categories. It then returns a permitted response, a block response, or a redirect to a block page, depending on the policy.
A mature DNS filtering program should cover the following:
- Known malicious domains: phishing, malware, ransomware, botnets, command-and-control infrastructure, newly observed threats, and domains associated with fraud.
- High-risk domain characteristics: newly registered domains, dynamic DNS providers, parked domains, suspicious top-level domains, and domains with poor reputation.
- Content categories: adult content, gambling, illegal activity, anonymizers, and other categories defined by business, legal, HR, and acceptable-use requirements.
- Business-risk categories: unsanctioned file sharing, personal webmail, crypto-mining, generative AI services, or remote-access tools where their use creates a documented risk.
- Non-user systems: servers, manufacturing workstations, kiosks, point-of-sale devices, IoT devices, and cloud workloads that perform DNS resolution.
- Remote users: laptops outside the corporate network, including users working from home, at customer sites, or on public Wi-Fi.
DNS filtering does not inspect full URLs, page content, encrypted payloads, or files downloaded from an allowed domain. It may block example.com, but it usually cannot distinguish a safe page from a malicious path on that same domain. That limitation is why a web filtering DNS filters program should sit alongside secure web gateway controls, endpoint detection and response, email security, patching, and user awareness measures.
Which DNS traffic and devices must be included?
Coverage failures are the most common weakness I find during client assessments. A policy can be well written and a DNS security platform can be fully licensed, but the control is ineffective if endpoints can use public resolvers, browsers can use encrypted DNS independently, or unmanaged network segments bypass the service.
Include corporate endpoints, mobile devices where technically feasible, VPN and non-VPN remote users, branch offices, servers, cloud virtual machines, wireless networks, guest networks, and operational technology networks where DNS is used. Apply more restrictive policies to systems that do not need general browsing, such as production servers and industrial engineering workstations.
For example, a 650-person precision-components manufacturer selling into aerospace and automotive supply chains operates Microsoft 365, an ERP platform, a supplier portal, engineering workstations, and 90 shop-floor terminals. Its office laptops receive Cisco Umbrella protection through the roaming client; branch firewalls forward DNS through Umbrella virtual appliances; and production terminals use a narrowly permitted DNS policy that allows approved update, identity, ERP, and supplier domains while blocking broad internet categories. This separation reduces risk without interrupting machine maintenance workflows.
How should filtering policies balance security and business access?
Start with a baseline policy that blocks confirmed threats and categories with little legitimate business value. Then create documented policy groups for populations with materially different requirements, such as standard users, privileged administrators, engineering teams, servers, guests, and operational technology.
| Policy group | Recommended DNS filtering settings | Operational rationale |
|---|---|---|
| Standard corporate users | Block malware, phishing, command-and-control, newly seen domains, adult content, gambling, anonymizers, and cryptomining. | Provides a defensible default while allowing normal research and supplier activity. |
| Privileged administrators | Use the standard policy plus alerts for newly registered domains; allow approved administration sites through named exceptions only. | Administrators face higher credential-theft risk and should not receive unrestricted browsing. |
| Servers and cloud workloads | Allow only required update, identity, monitoring, backup, and application domains; block all content categories and risky domain types. | Servers rarely need open web access and are valuable targets for command-and-control activity. |
| Guest wireless | Block threats, adult content, anonymizers, and peer-to-peer services; isolate from internal DNS and networks. | Reduces liability and prevents guest traffic from bypassing corporate controls. |
Do not build policies around vague labels such as “reasonable use.” Define categories, named owners, exception criteria, review dates, and escalation paths. A temporary supplier portal exception should have a business sponsor, a specific domain, a defined expiration date, and a review record—not a permanent broad allow rule.
How do you implement the web filtering DNS filters ultimate guide in practice?
- Define the control standard. Document the purpose, scope, baseline categories, policy groups, exception authority, log-retention period, and control owner. Map the standard directly to ISO 27001 Annex A 8.23.
- Inventory DNS paths. Identify internal resolvers, firewall forwarding rules, DHCP settings, VPN DNS settings, cloud DNS services, browser secure-DNS configurations, and devices using public resolvers such as Google Public DNS or Cloudflare.
- Select an enforcement model. Use a managed DNS security service such as Cisco Umbrella, DNSFilter, or Cloudflare Gateway; deploy endpoint roaming clients for off-network users; and configure network forwarding or virtual appliances for on-network devices.
- Prevent bypass. Restrict outbound DNS over UDP/TCP port 53 to approved resolvers. Manage browser DNS-over-HTTPS settings through endpoint policy, and block unauthorized DNS-over-HTTPS providers where the chosen platform or secure web gateway supports this.
- Build and test policy groups. Begin in monitor or report-only mode for categories likely to cause disruption, especially for engineering, supplier, and production systems. Review requests, refine allow lists, then move high-confidence threat categories to block mode.
- Integrate alerting and response. Send DNS security logs to the SIEM. Create alerts for malware callbacks, repeated phishing-domain requests, command-and-control matches, and unusual requests from servers or production assets.
- Operate and evidence the control. Review exceptions monthly, review policy effectiveness quarterly, test blocking from internal and remote networks, and retain records of results, changes, and remediation decisions.
A second client, a 280-person electronics assembly business with an ERP supplier-integration server and shared engineering file-transfer workflows, initially blocked a legitimate component distributor because the distributor’s new portal used a recently registered domain. The security team validated the supplier through procurement, permitted the exact domain for 30 days, and added a recurring review. That is the right outcome: neither a blanket bypass nor an undocumented permanent exception.
What evidence demonstrates ISO 27001 web filtering compliance?
Auditors generally need evidence that the stated control is implemented consistently and is reviewed. Keep the evidence practical and tied to the management system: an approved web filtering standard; a current asset and network scope; screenshots or exports of DNS policies; endpoint-agent deployment reports; firewall rules restricting external DNS; sample block events; exception tickets; monthly review records; and periodic test results.
Useful metrics include percentage of managed endpoints protected, percentage of sites forwarding DNS to the approved service, blocked malicious-domain requests, unauthorized resolver attempts, exceptions past expiry, and mean time to investigate high-severity DNS alerts. Metrics should drive decisions, not simply fill a dashboard.
What is the implementation checklist for DNS web filtering?
- Approve a web filtering standard owned by information security and aligned to ISO 27001 control 8.23.
- Document every corporate DNS resolver, DHCP scope, VPN profile, cloud network, and remote endpoint path.
- Deploy DNS filtering for office networks, remote endpoints, branch locations, servers, and cloud workloads.
- Block or redirect outbound DNS traffic to unauthorized public resolvers.
- Manage DNS-over-HTTPS and DNS-over-TLS to prevent policy bypass.
- Configure baseline blocks for malware, phishing, command-and-control, and other approved high-risk categories.
- Apply separate policies for users, administrators, servers, guests, and operational technology.
- Document allow-list requests with business owner, justification, scope, approval, and expiry date.
- Send filtering logs to the SIEM and define triage procedures for high-severity detections.
- Test internal and off-network blocking at least quarterly and retain the results.
- Review coverage, exceptions, and policy changes at least quarterly.
Frequently asked questions about DNS web filtering
Is DNS filtering enough for ISO 27001 Annex A 8.23?
DNS filtering can be a primary implementation mechanism for Annex A 8.23 because it manages access to external websites and blocks known malicious domains. It is not sufficient on its own for all web risks, however, because it cannot inspect full URLs, encrypted web sessions, or downloaded content. Layer it with endpoint, email, and secure web controls based on risk.
Can users bypass DNS filtering by using Google DNS or Cloudflare DNS?
They can if outbound DNS is not controlled. Configure firewalls to permit DNS only to approved resolvers, deploy roaming clients for remote devices, and manage browser encrypted-DNS settings. Monitor attempted use of unauthorized resolvers as a potential policy-bypass signal.
What categories should a company block first with DNS filtering?
Block malware, phishing, command-and-control, botnet, ransomware, and confirmed malicious domains first. Then assess categories such as newly registered domains, anonymizers, adult content, gambling, cryptomining, and unsanctioned file sharing according to legal, HR, business, and operational requirements.
How often should DNS filtering rules and exceptions be reviewed?
Review temporary exceptions monthly and remove those that are no longer justified. Review policy categories, coverage reports, blocked-event trends, and control effectiveness quarterly, and after material changes such as mergers, network redesigns, major SaaS adoption, or security incidents.
How do I prevent DNS filtering from disrupting suppliers or production systems?
Inventory required domains before enforcement, start sensitive groups in monitoring mode, and use narrowly scoped exceptions with expiry dates. For critical systems, permit only validated required domains rather than weakening the entire policy for a network segment.
Next step: Ask your security and network leads for a current DNS-path inventory and use it to identify every location where your ISO 27001 web filtering control can be bypassed.
