Every time someone at your business clicks a link, opens an email, or visits a website, the first thing that happens is a Domain Name System (DNS) lookup. The browser asks a DNS resolver to translate the human-readable domain name into the numeric Internet Protocol (IP) address where the server lives. This lookup happens before the page loads, before any file downloads, and before any credential prompt appears. It is the very first step of every connection your business makes to the internet.
Most small businesses and defense contractors have never touched this setting. Their computers use whatever DNS resolver their Internet Service Provider (ISP) assigned when the router was installed. That default resolver does one thing: it answers the question. It translates the domain name to an address, and it does so regardless of whether that address hosts a legitimate business or a phishing page built to steal credentials.
A protective DNS resolver does the same translation, but it adds a check. Before returning the address, it compares the requested domain against a continuously updated list of known-malicious sites. If the domain is associated with phishing, malware distribution, command-and-control infrastructure, or other threats, the resolver blocks the connection and returns a safe response instead. The employee never reaches the dangerous page. The malware never phones home. The credential prompt never appears.
Why this matters more than most controls that cost money
Protective DNS sits at the earliest possible chokepoint in an attack. Most attacks against small businesses follow the same pattern: an employee clicks something, and the click reaches a server controlled by the attacker. Protective DNS breaks that chain before the connection is established. It does not replace endpoint protection, firewalls, or multifactor authentication. It adds a layer underneath all of them, one that operates before any of those controls are tested.
The Cybersecurity and Infrastructure Security Agency (CISA), the federal agency responsible for defending civilian networks, runs its own Protective DNS service for government agencies and critical infrastructure. CISA built it because the data showed that blocking malicious DNS queries prevented a measurable percentage of successful intrusions. The same principle applies to a ten-person defense subcontractor or a twenty-person medical practice. The threats use the same infrastructure, and the DNS lookup is the same chokepoint.
The cost is zero. The setup takes roughly fifteen minutes. There is no hardware to buy, no software to install, and no subscription to manage. You change two settings on your router or on each computer, and the protection is active.
How protective DNS works, in plain terms
When an employee types a web address or clicks a link, the operating system sends a DNS query to a resolver. With a standard ISP resolver, the query is answered without inspection. The resolver does not know or care whether the destination is safe.
A protective DNS resolver intercepts that same query and runs it against a threat intelligence feed before responding. These feeds are compiled from multiple sources: government threat databases, commercial security research, honeypot networks, and real-time analysis of newly registered domains. If the domain appears on any of those lists, the resolver returns a block page or a safe IP address instead of the real one. The connection never reaches the malicious server.
This happens in milliseconds. There is no noticeable delay in browsing. Legitimate sites load normally. Only requests to known-bad domains are intercepted.
Protective DNS also helps with a category of threat that is difficult to catch any other way: malware that is already on a machine and trying to communicate with its operator. Most modern malware uses DNS to reach command-and-control (C2) servers for instructions and to send stolen data out. If the C2 domain is blocked at the DNS layer, the malware cannot function, even though it is running on the endpoint. This buys time to detect and remove it.
The free options available right now
Three protective DNS services stand out for small businesses because they are free, well-maintained, and backed by organizations with strong track records.
Quad9, operated by the Quad9 Foundation, a Swiss nonprofit, provides threat-blocking DNS at the addresses 9.9.9.9 and 149.112.112.112. Quad9 blocks known-malicious domains using threat intelligence from more than 25 providers, including commercial threat feeds and government sources. It does not log user IP addresses and does not sell data. For a small business that wants a simple protective DNS with no account required, Quad9 is the fastest path: change your DNS settings to those two addresses and the protection is live.
Cloudflare Gateway offers a free tier through its 1.1.1.1 for Families service. The malware-blocking addresses are 1.1.1.2 and 1.0.0.2. For businesses that also want to block adult content on work networks, Cloudflare offers a combined filter at 1.1.1.3 and 1.0.0.3. The free tier requires no account. Cloudflare also offers a paid Zero Trust tier with logging and per-user policies, but the free DNS filtering alone is a meaningful upgrade over an unfiltered ISP resolver.
CISA Protective DNS is available to United States (U.S.) federal agencies, state and local governments, and critical infrastructure organizations. If your business qualifies as critical infrastructure or holds certain federal designations, this service may be available to you at no cost. It is worth checking eligibility, because CISA's threat intelligence is among the most current available. Even if your business does not qualify for the CISA service directly, the existence of the program validates the approach: the federal government built this because it works.
How to set it up in fifteen minutes
There are two approaches: configure it on the router, or configure it on each device. The router approach is better for most small businesses because it protects every device on the network, including phones, tablets, and Internet of Things (IoT) devices that cannot run endpoint security software.
To configure it on your router, log in to your router's administration page, find the DNS settings (often under Wide Area Network (WAN) or internet settings), and replace the existing DNS server addresses with the protective DNS addresses of your chosen provider. For Quad9, enter 9.9.9.9 as the primary and 149.112.112.112 as the secondary. Save the settings and restart the router. Every device that picks up its DNS settings from the router, which is most of them, will now use the protective resolver.
To configure it on individual Windows machines, open Network and Internet settings, select the active connection, find the DNS server assignment, switch it from automatic to manual, and enter the protective DNS addresses. On macOS, open System Settings, select Network, choose the active connection, click Details, select DNS, and replace the existing entries. The change takes effect immediately.
One important note: if your business uses a managed IT service or a domain controller that handles DNS internally, coordinate with that provider before making changes. Internal DNS servers can be configured to forward external queries to a protective resolver while still handling internal name resolution. Making changes without coordination could break internal services. If you manage your own network, the change is straightforward.
Where protective DNS maps to NIST Special Publication 800-171 and Cybersecurity Maturity Model Certification
For defense contractors working toward the Cybersecurity Maturity Model Certification (CMMC) or maintaining compliance with National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, protective DNS is not a nice-to-have. It maps directly to several control families.
Under System and Communications Protection, the requirement to monitor, control, and protect communications at external system boundaries (Security Requirement 3.13.1) is directly supported by DNS filtering. Protective DNS is a boundary control that inspects and blocks outbound connections to known-malicious infrastructure. The requirement to deny network communications traffic by default and allow by exception (3.13.6) is also relevant: protective DNS enforces a default-deny posture for connections to threat-listed domains.
Under System and Information Integrity, the requirement to provide protection from malicious code at appropriate system entry and exit points (3.14.2) is served by DNS filtering that prevents malware downloads and blocks C2 communications. The requirement to monitor organizational systems for attacks and indicators of potential attacks (3.14.6) aligns with the logging capabilities that some protective DNS providers offer, which can show which machines on your network are attempting to reach malicious domains.
Protective DNS does not satisfy any of these controls by itself. But it contributes to each one in a way that is easy to document and easy for an assessor to verify. When an assessor asks how your organization prevents connections to known-malicious infrastructure, pointing to a configured protective DNS resolver is a concrete, auditable answer.
What protective DNS does not do
Protective DNS is not a replacement for other controls. It blocks connections to known-bad domains, but it cannot stop an attacker who uses a newly registered domain that has not yet appeared on any threat list. It cannot inspect the content of encrypted traffic. It does not protect against threats that do not use DNS, such as direct IP connections or attacks delivered through legitimate services like cloud storage links or compromised email accounts.
It is one layer. It is a strong layer, and it is free, but it works best alongside endpoint protection, email filtering, multifactor authentication, and employee awareness training. The value of protective DNS is not that it replaces those controls. The value is that it catches threats before those controls are tested, and it costs nothing to add.
What to do this week
Pick one of the three providers listed above. If you want the simplest option with no account, use Quad9: set your DNS to 9.9.9.9 and 149.112.112.112. If you are comfortable with Cloudflare and may want to upgrade to logging later, use 1.1.1.2 and 1.0.0.2. Configure it on your router if you manage your own network, or ask your IT provider to make the change and confirm it was done.
Then document it. Write down which provider you chose, which devices or routers were configured, and the date. If you are a defense contractor maintaining a System Security Plan (SSP), add protective DNS to the controls narrative under System and Communications Protection and System and Information Integrity. The documentation takes ten minutes and gives you a concrete answer for the next time a prime contractor or assessor asks what you are doing to prevent connections to malicious infrastructure.
This is the rare security control that costs nothing, takes less than an hour to deploy across an entire small business, and provides measurable risk reduction from the moment it is active. Most small businesses are not using it. There is no reason not to start.
Adams Cloud and Cybersecurity provides cybersecurity readiness consulting for small businesses and defense contractors.
Want help tightening your network security controls?
Adams Cloud helps small businesses and defense contractors configure protective DNS, document boundary controls for NIST 800-171 and CMMC, and build a System Security Plan that holds up to scrutiny.
Book a free thirty minute consultation