Protective DNS — block command-and-control and known-bad domains at the resolver

What the control is

Protective DNS is a recursive DNS resolver — the service every endpoint, server and IoT device on your network depends on to translate domain names into IP addresses — augmented with a continuously-updated block list of known-malicious domains. When a host on the protected network resolves an attacker-controlled domain, the resolver returns NXDOMAIN or a sinkhole address, the host’s outbound connection fails, the attacker’s command-and-control beacon never reaches its server, and the resolver logs the attempt with the source host. The defender gains both prevention and detection in a single network choke point.

The control is most effective when it covers the full estate: every endpoint, every server, every cloud workload, every IoT device’s DNS goes through the protective resolver. Split-horizon and bring-your-own-resolver configurations create blind spots. The corollary is that the protective resolver is a privileged piece of infrastructure that needs the same hardening attention as any other tier-0 service.

Why it matters

Almost every modern intrusion uses DNS as its primary command-and-control channel. The attacker’s payload, once executing on the victim host, makes a DNS query for an operator-controlled domain — to fetch the next-stage configuration, to register the new infection with a botnet C2, to receive commands, or in some cases to encode exfiltrated data into the query string itself. MITRE ATT&CK lists the technique as T1071.004 (“Application Layer Protocol: DNS”) with several adjacent techniques covering DNS tunnelling and DNS-based exfiltration.

The catalogue’s worked examples cluster around the call-home stage of intrusions. SolarWinds Sunburst, the most famous worked example of all, used a multi-stage DNS-based C2 to the avsvmcloud.com domain — protective DNS subscribers caught it as soon as the indicator was published. The HSE Ireland Conti ransomware event, Colonial Pipeline DarkSide event, JBS Foods REvil event, British Library Rhysida event and Travelex Sodinokibi event each had a phone-home stage in which the deployed payload reached an operator-controlled domain via DNS before initiating encryption or staging exfiltration. NotPetya’s lateral-spread phase did not depend on DNS C2 — that was the point of the wiper, it didn’t need to phone home — but the post-incident reviews at Maersk, Merck and FedEx all surfaced DNS telemetry as the primary forensic source for reconstructing the chain.

Protective DNS does not stop initial access. It stops the second-stage call-home that turns initial access into persistent operator control. That intermediate stage is where the attacker’s tradecraft is most repeatable and most catalogued in public threat-intelligence feeds, which is exactly where a block-list-driven resolver bites hardest.

Where the regulators sit

NCSC operates a free Protective DNS service for UK public sector and has published the threat statistics annually since launch — billions of blocked queries per quarter, with the leading categories tracking the public commodity-malware landscape. CISA’s Protective Domain Name System service is the US federal-civilian equivalent. The NSA and CISA joint 2021 guide “Selecting a Protective DNS Service” is the clearest published buyer’s checklist and is the right reference for procurement conversations. NIST SP 800-81-2 (“Secure DNS Deployment Guide”) covers the deployment posture in technical detail. MITRE D3FEND maps the control to specific defensive techniques against the ATT&CK DNS-C2 family.

The framework view is unanimous. There is a free national-agency service for UK public-sector organisations and a wide commercial market for everyone else.

Where it usually breaks

Two failure modes account for most weak protective-DNS deployments. The first is incomplete coverage. Endpoints obeying corporate DHCP go through the protective resolver; servers configured with static DNS pointing at internal AD-integrated DNS without onward forwarding to the protective resolver do not. IoT devices that ship with hardcoded resolvers ignore the configuration entirely. Cloud workloads with VPC-native DNS may bypass the corporate path. The fix is firewall-level egress blocking of all outbound UDP/TCP 53 except to the approved protective resolver, plus DoH/DoT egress blocking unless explicitly allowlisted.

The second is alert fatigue. A protective DNS service generates a meaningful volume of blocks, most of which are routine commodity-malware drive-by infections that the resolver has already mitigated. The operations team needs a clear playbook for which blocks warrant investigation: enterprise-domain hits, off-hours hits from server-class hosts, hits on indicators tied to recent advisory publications. Treating every block as an incident burns out the team; treating none of them as an incident wastes the telemetry. The fix is documented triage tiers.

What good looks like

A protective DNS service in front of every internal recursive resolver. Egress firewall rules that block UDP/TCP 53 and DoH/DoT to anywhere except the protective service. Log retention sufficient for forensic reconstruction — at least 90 days, preferably a year. A documented triage playbook for protective-DNS alerts, integrated with the SOC’s existing incident-response process. A quarterly review of the most-blocked categories to surface emerging campaigns.

The cost is low — free for UK public sector via NCSC, modest commercial subscription for everyone else. The control sits between initial access and operator persistence and breaks the chain at the cheapest, most repeatable stage.