Protective DNS for local government networks

Reference article · 5 min read

Most intrusions that reach a user's browser or inbox depend on a name lookup happening first. A staff member clicks a link in a phishing message, a document reaches out for a second stage, or a compromised workstation calls home. Each starts with a resolver turning a name into an IP address. Protective DNS puts policy at that step: the resolver checks the requested name against threat intelligence and returns a block response instead of an address when the name is known to be malicious, newly registered, or otherwise suspicious.

For a small city or county IT shop, this is one of the few controls that widens coverage without touching every endpoint. It does not inspect content, and it applies to every device using the resolver you point it at. The limits are just as real: it only sees queries that reach your resolver, and it only stops what the intelligence behind it already knows.

What the control actually does

A protective resolver either answers normally, returns a block response such as NXDOMAIN, or returns a sinkhole address serving a block page. Policies typically cover command and control infrastructure, phishing, malware distribution, and lookalike names. The category that catches the most real attacks in small agencies is often newly registered and newly observed domains, because phishing infrastructure tends to be young.

Treat the block as half the value. Every block is also an alert: a workstation repeatedly querying blocked command and control domains is telling you it is already compromised.

Where enforcement happens, and where it leaks

Enforcement is only as good as your control over resolution paths. Map yours before you buy anything.

• Internal resolvers and forwarders. Most agencies run Active Directory DNS and forward external queries upstream. Repointing those forwarders is the fastest win, but the provider then sees your domain controller as the source of every query. Keep client level query logging internally, or you cannot say which machine asked.
• Roaming laptops. Off your network, a device uses whatever resolver the home router hands it. Coverage there requires an endpoint agent, an encrypted DNS profile pushed by policy, or always on VPN.
• Mobile devices. Phones on cellular bypass network controls entirely. Device management can push a DNS profile to managed phones; unmanaged personal devices stay uncovered.
• Guest and public wifi. Worth protecting, but a block page carrying agency branding on a library or lobby network invites complaints.
• Encrypted DNS in browsers. Browsers using DNS over HTTPS to their own provider skip your resolver silently. Set the browser policy that disables or pins it, and verify it applied.
• Hardcoded devices. Cameras, printers, and building systems often ship with a public resolver baked in. Block or redirect outbound DNS from everything except your own resolvers.

What the logs give you

A usable log line includes timestamp, query name, source, action, and category. During an incident that tells you when a host first contacted attacker infrastructure, which other hosts reached the same names, and whether a newly published indicator appears in past activity.

Know the limits. DNS logs show intent to connect, not what was transferred, and they say nothing about traffic sent straight to an IP address. Ask how long the provider retains logs, whether you can export them to your SIEM, and whether you get raw queries or only dashboards.

False positives and block pages

Plan the complaint path before go live, because that is where these projects stall.

• Name an owner for allowlist requests and give the help desk a documented path with a realistic response time. Log each decision with a reason and an expiration date.
• Choose deliberately between a block page and a silent block. A block page reduces tickets, but on HTTPS sites it often shows a certificate warning instead of readable text.
• Pilot with IT and one friendly department first, and tune the newly registered domain category early, since short lived sites for events, grants, and vendor portals land there.

How it differs from firewall filtering

Firewall and proxy filtering generally act after a connection begins and identify sites by IP address or by inspecting the session. Protective DNS acts at the lookup, before the connection, and covers any protocol rather than web traffic alone.

The reverse is also true. DNS filtering does nothing about a connection made straight to an IP address, and it cannot block one bad page on an otherwise legitimate hosting domain. Neither replaces the other. If your firewall vendor already claims DNS security, ask whether it enforces for off network devices and which feeds it uses.

Free options, and how to start

The Center for Internet Security, through the MS-ISAC, has offered a no cost protective DNS service to state, local, tribal, and territorial members, and CISA has supported protective DNS availability for that community. Program scope and funding have changed over time, so confirm current eligibility and terms with CIS or your state program. Some states also run a statewide resolver or hold a term contract local agencies can use. CISA's own service is aimed at federal civilian agencies.

To start, inventory every place resolution happens, run in monitor only mode if the provider supports it, enforce for internal clients first, then extend to roaming endpoints and route logs where you already review security data.

Ask any provider, free or paid: what feeds the blocklist and how often it updates, how a bad block gets reviewed and how fast, what is retained and for how long, whether logs export, how roaming coverage works, and what happens if the service is unreachable. In a paid contract, write down log export rights, data ownership and deletion at termination, notice before default categories change, and support response times.

HQT works with state and local agencies on network and security engineering, including resolver architecture, logging integration, and rollout planning.

Frequently asked questions