DNS Security Guide: Protective DNS, DNSSEC, DoH

Almost every connection an attacker makes, from phishing click to command and control, starts with a DNS lookup, yet many organisations still run DNS as plumbing that nobody logs, filters or owns. DNS is attacked as a target (hijacked registrar accounts, poisoned caches, dangling records) and used as a channel (tunnelling, domain generation algorithms, exfiltration hidden in queries). This guide covers both for network engineers, security architects and SOC teams: protective DNS and response policy zones, encrypted DNS, DNSSEC, authoritative zone hygiene, subdomain takeover, logging and detection. It draws on the IETF RFCs, NIST SP 800-81 Rev. 3, NSA and CISA guidance and the UK NCSC, and maps the work to NIST, CIS, ISO, MITRE ATT&CK and D3FEND.

Key takeaways

Protective DNS gives broad coverage for little effort. NSA and CISA describe it as a security service, not a protocol, that blocks, redirects or sinkholes lookups of known malicious domains, and the UK NCSC runs one free of charge for eligible organisations.
Filtering only works if clients cannot route around it. Block outbound 53 and 853 to anything except your resolvers, block unapproved DNS over HTTPS endpoints, and set browser and OS policy so encrypted DNS goes to your resolver.
DNSSEC and encrypted DNS solve different problems. RFC 4033 says DNSSEC "is not designed to provide confidentiality"; RFC 8484 says DoH does not provide "the response integrity of DNS data provided by DNSSEC". Validate on the resolver and encrypt the last hop.
DNS admin accounts are a single point of failure. CISA Emergency Directive 19-01 followed a campaign where stolen DNS credentials were used to change A, MX and NS records and obtain valid certificates. Phishing-resistant MFA, registrar lock and Certificate Transparency monitoring close most of that path.
Dangling records are a decommissioning failure. A CNAME left pointing at a deleted cloud resource lets whoever claims that resource name serve content, collect cookies and get a valid certificate on your subdomain. Remove the record before the resource.

How DNS is attacked

A stub resolver on the endpoint asks a recursive resolver, which walks from the root to the authoritative name server for the zone and caches the answer. Every step, plus the registrar and DNS hosting accounts behind the authoritative server, is attack surface.

Threat	How it works	ATT&CK	Primary control
DNS hijacking	Stolen credentials or a compromised provider used to change NS, A or MX records, or to add subdomains silently (domain shadowing)	T1584.002 Compromise Infrastructure: DNS Server	Phishing-resistant MFA, registrar lock, CT monitoring, CAA records
Subdomain takeover	A record points at a deprovisioned resource that an attacker re-registers	T1584.001 Compromise Infrastructure: Domains	Decommissioning order, ownership verification records, zone scans
Cache poisoning and spoofing	Forged responses accepted and cached by a resolver	No specific technique	DNSSEC validation, no open resolvers
Tunnelling and C2	Commands and output encoded in query names and TXT or A records	T1071.004 Application Layer Protocol: DNS	Force DNS through monitored resolvers; length, entropy and volume analytics
Exfiltration	Data chunked into subdomain labels sent to an attacker's name server	T1048 Exfiltration Over Alternative Protocol	As above, plus egress blocking of direct DNS
DGA and fast flux	Malware computes candidate domains or rotates IP addresses rapidly	T1568.002, T1568.001	Protective DNS with DGA detection, newly registered domain policy
DoH to hide C2	Malware resolves over HTTPS to a public resolver	T1572 Protocol Tunneling	Block unapproved DoH endpoints, endpoint DNS telemetry
Zone transfer leakage	An open AXFR returns the whole zone, including internal hosts and mail exchange (MX) records	Reconnaissance	Restrict AXFR and IXFR to named secondaries with TSIG or XoT
NXDOMAIN and random subdomain floods	Queries for non-existent names exhaust resolver and authoritative capacity	Denial of service	Rate limiting, validated negative caching (RFC 8198), headroom

SolarWinds SUNBURST shows DNS as a C2 channel: Microsoft's analysis describes each infected host generating its own subdomain of avsvmcloud[.]com from its adapter address, domain name and MachineGuid, and lists T1071.004 and T1568.002. See the SolarWinds supply chain compromise. Central DNS logs let defenders hunt for those lookups once indicators were published.

Protective DNS, response policy zones and sinkholing

Protective DNS (PDNS) is a recursive resolver that checks queried names, and often returned IP addresses, against threat intelligence and refuses to resolve the bad ones. The NSA and CISA sheet "Selecting a Protective DNS Service" compares providers on malware, phishing and DGA blocking, heuristics, content filtering, SIEM APIs, DNSSEC validation, DoH and DoT support, per-group policy and hybrid coverage. It warns that PDNS "is bypassed by any traffic using IP addresses directly", so it is one layer, not a perimeter.

Government services: the UK NCSC PDNS is "a recursive DNS resolver which prevents access to domains known to be malicious", mandated by the Cabinet Office for central government and implemented by Cloudflare and Accenture; PDNS Roaming sends queries over DoH from Windows, macOS and iOS devices off the office network. CISA's Protective DNS Resolver, the 2022 successor to E3A, is mandated for US federal civilian agencies.
Response policy zones (RPZ): the NCSC service stores its rules as an RPZ, a policy zone the resolver consults before answering (the basis of a DNS firewall). RPZ is supported in BIND 9 (Berkeley Internet Name Domain) and other resolvers; rules trigger on the queried name, the answer IP address or the name server, and respond with NXDOMAIN, NODATA, a redirect to a block page, or pass-through for exceptions.
Sinkholing: the resolver returns an address you control instead of failing the lookup, which turns a block into a detection: every host that connects to the sinkhole is infected or misconfigured. Registries apply the same idea when a malicious domain is seized and repointed.
Denylisting and allowlisting: D3FEND DNS Denylisting (D3-DNSDL) covers Forward Resolution Domain Denylisting (D3-FRDDL), Hierarchical Domain Denylisting (D3-HDDL, a domain and all its subdomains), Forward Resolution IP Denylisting (D3-FRIDL, answers resolving to bad addresses), Reverse Resolution IP Denylisting (D3-RRID) and Homoglyph Denylisting (D3-HDL). DNS Allowlisting (D3-DNSAL), "Permitting only approved domains and their subdomains to be resolved", suits servers, OT segments and kiosks, not general desktops.
Cache eviction: after a fixed hijack, flush resolver and client caches (D3FEND DNS Cache Eviction, D3-DNSCE) so bad answers do not outlive the fix.

Encrypted DNS: DoH, DoT and enterprise control

Classic DNS travels in clear text, so anyone on the path can read and alter it. Encrypted transports protect the client to resolver hop but do not authenticate the data, and they remove network visibility unless the encrypted endpoint is your own resolver.

Option	Standard and port	Protects	Enterprise implication
Classic DNS	RFC 1035, UDP and TCP 53	Nothing	Visible; easy to spoof on hostile networks
DNS over TLS (DoT)	RFC 7858, TCP 853; an alternative port "MUST NOT be port 53"	Confidentiality and integrity of the hop	Dedicated port: easy to allow to your resolver and block elsewhere
DNS over HTTPS (DoH)	RFC 8484, TCP 443, application/dns-message, GET and POST, HTTP/2 minimum recommended	Same as DoT	Blends with web traffic; control by policy and by blocking known DoH endpoints
DNS over QUIC (DoQ)	RFC 9250, UDP 853	Same as DoT	Block UDP 853 except to approved resolvers
DNSSEC	RFC 4033 to 4035	Origin authentication and integrity of data, authenticated denial of existence	Validate on the resolver; queries stay visible
XFR over TLS (XoT)	RFC 9103, port 853, TLS 1.3 or later	Confidentiality of zone transfers	Use across untrusted networks; TSIG alone "does not add confidentiality"

Windows: the Group Policy "Configure DNS over HTTPS (DoH) name resolution" (Computer Configuration\Policies\Administrative Templates\Network\DNS Client) offers Allow, Prohibit and Require. Microsoft warns against Require on domain-joined computers because Active Directory depends on DNS and the Windows Server DNS Server service does not answer DoH. Register your resolver with Add-DnsClientDohServerAddress.
Chrome and Edge: DnsOverHttpsMode takes off, automatic (DoH with clear-text fallback) or secure (DoH only), with DnsOverHttpsTemplates naming the resolver. On managed devices with the policy unset, Chrome sends no DoH queries.
Firefox: where DoH is on by default, Firefox looks up the canary domain use-application-dns.net through the system resolver; NXDOMAIN, SERVFAIL or an empty NOERROR answer disables default DoH. Return that from your resolver, and use enterprise policy because the canary does not override a user's own choice.
Network enforcement: NSA and CISA advise blocking outbound 53 and 853 except where operations require them, and blocking unauthorised DoH servers. Software can embed its own DoH client, so endpoint DNS telemetry is the backstop.

DNSSEC: signing zones and validating answers

RFC 9364 (BCP 237) states that "Using the DNSSEC set of protocols is the best current practice for adding origin authentication of DNS data." Validation is done by your resolvers for every answer they fetch; signing is done for zones you publish. NIST SP 800-53 separates them: SC-20 covers the authoritative source, SC-21 the recursive or caching resolver.

Validate first: validation on internal and protective resolvers protects every user against forged answers for signed domains. Use a negative trust anchor (RFC 7646) to disable validation for one broken external domain, never globally.
Sign public zones: a key signing key (KSK) and zone signing key (ZSK) sign the zone, and the parent publishes a DS record hashing the KSK to complete the chain of trust. ECDSA P-256 (algorithm 13) keeps responses small; check registrar support first.
Automate DS updates: CDS and CDNSKEY records (RFC 7344, RFC 8078) let the parent pick up new keys, removing the classic outage where a KSK is rolled but the DS at the registrar is not. RFC 7583 covers rollover timing.
Use NSEC3 sensibly: NSEC3 (RFC 5155) hinders zone walking; RFC 9276 advises zero additional iterations and no salt, because extra iterations add resolver cost without real protection.
Build on it: DNS-Based Authentication of Named Entities (DANE) TLSA records bind a certificate or trust anchor to a name; RFC 7671 says "DANE relies on the DNS Security Extensions (DNSSEC)" and recommends DANE-TA(2) and DANE-EE(3),, and is most used for SMTP between mail servers. CAA records (RFC 8659) restrict which certificate authorities may issue for your domain.

Authoritative zones, registrars and zone transfers

The campaign behind CISA Emergency Directive 19-01 broke no cryptography: attackers logged in to DNS management accounts with stolen credentials, changed records and redirected web and mail traffic. ATT&CK lists Sea Turtle and LAPSUS$ among groups that changed DNS records under T1584.002.

Lock the control plane: enforce phishing-resistant MFA on registrar, DNS hosting and cloud DNS accounts (the directive did not recommend SMS), and use registrar lock plus registry lock for critical domains. See the MFA Guide.
Audit records against intent: the directive required agencies to verify that records "resolve to the intended location", prioritising NS records. Keep zones in version control and compare live answers with the repository.
Watch Certificate Transparency: a hijacker who controls your records can pass domain validation, so certificates you did not request are often the first sign.
Restrict zone transfers: AXFR (query type 252, the full zone transfer in RFC 5936) and IXFR should go only to named secondaries, authenticated with TSIG and carried over XoT across untrusted networks. Test with dig axfr example.com @ns1.example.com from outside; expect a refusal.
Separate internal and external views: internal host names and domain controller SRV records do not belong in public zones. Set Active Directory-integrated zones to secure dynamic updates only, so arbitrary hosts cannot register or overwrite names through dynamic DNS (DDNS).
Run no open resolvers: authoritative servers should not recurse, and recursive resolvers should answer only your address ranges.
Govern the machine identities that change DNS: API tokens used for ACME DNS-01 certificate challenges, cloud roles used by infrastructure-as-code pipelines and TSIG keys are non-human credentials that can redirect mail or obtain certificates for any name they can write. Scope them to specific zones, vault them, rotate TSIG keys and alert on record changes made outside the pipeline. See the API Key Management Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.

Dangling DNS and subdomain takeover

ATT&CK T1584.001 notes that "Subdomain hijacking can occur when organizations have DNS entries that point to non-existent or deprovisioned resources." Microsoft's example: greatapp.contoso.com is a CNAME to an App Service host name, the app is deleted but the record is not, and an attacker creates an app with the same name in their own subscription. Microsoft lists cookie harvesting, phishing (including via MX records) and cross-site scripting or CORS bypass as results, and notes the attacker can get a valid certificate. Expired domains carry the same risk when something still trusts them: see ForcedLeak, where a $5 expired domain became an exfiltration route.

Delete in order: remove the DNS record before the resource. Microsoft recommends "Remove DNS entry" on every decommissioning checklist and delete locks on resources with custom domains.
Bind ownership: an asuid.<subdomain> TXT record with your verification ID means "no other Azure subscription can validate the custom domain". Azure DNS alias records point at a resource rather than a name and become an empty record set when it is deleted.
Scan continuously: resolve every CNAME and flag cloud targets (for example *.azurewebsites.net, *.cloudapp.azure.com, *.trafficmanager.net) that no longer exist or sit outside your subscriptions. Microsoft's Get-DanglingDnsRecords tool does this for Azure; Defender for App Service alerts when an app is removed but its custom domain is not.
Treat a find as an incident: check whether the name was already claimed and whether cookies, OAuth redirects or other secrets reached it.

Choosing an approach

Small organisations: point every device at one protective DNS service, with roaming clients for laptops, block outbound 53 and 853 at the firewall, and enable DNSSEC and registrar lock with your DNS host. A self-hosted filtering resolver such as AdGuard Home or Pi-hole suits one office but adds patching and availability work.
Large organisations: keep internal resolvers (often Active Directory DNS) for internal names, forward external resolution to PDNS or an RPZ-fed resolver, log at both tiers, and automate DNSSEC signing in the hosting platform.
Government or commercial PDNS: government services are free and curated but less customisable; commercial services add dashboards, APIs and per-group policy. Both see every lookup, so check data use.
DoT or DoH to your resolver: DoT is easier to govern because of its dedicated port; DoH works better for roaming devices on networks that block 853.
Allowlist or denylist: allowlist servers, OT and build agents, where required domains are few and stable; denylist user devices through PDNS.

Rolling out DNS security

Inventory: list every resolver, forwarder, zone, registrar account and DNS hosting tenant with an owner, and export cloud CNAME targets.
Log before you block: enable resolver and endpoint DNS logging into the SIEM, and run PDNS in monitor mode for two to four weeks to see what would be blocked.
Pilot ring: move IT and security staff to blocking mode with a block page explaining how to request exceptions; tune false positives into a reviewed RPZ pass-through list.
Broad rollout: change DHCP and VPN DNS settings, deploy roaming clients, apply browser and Windows DoH policy, then block outbound 53, 853 and known DoH endpoints except from your resolvers.
Harden authoritative DNS: MFA and registrar lock, CAA, transfer restrictions and CT monitoring, then DNSSEC signing on one low-risk zone before the rest.
Roll back safely: keep previous resolver settings and firewall rules ready to re-enable. To back out DNSSEC, remove the DS record at the parent and wait out its TTL before unsigning, never the reverse.

Detection and measurement

Windows DNS Server: audit events (on by default) include 513 zone delete, 515 record create, 516 record delete, 519 record created by dynamic update and 541 server setting changed. Analytic events (off by default) include 257 RESPONSE_SUCCESS, 260 RECURSE_QUERY_OUT, 263 DYN_UPDATE_RECV and 269 and 270 for AXFR requests. Microsoft states analytic logging can cost about 5% at 100,000 queries per second, with no apparent impact at 50,000 or lower.
Endpoints: Sysmon Event ID 22 (DNSEvent) records which process made each query, separating a browser from rundll32 or PowerShell resolving an encoded subdomain, which is what ATT&CK's T1071.004 detection guidance looks for alongside long labels and unusual TXT volume.
Resolvers and PDNS: keep query name, type, client, response code and answer. D3FEND DNS Traffic Analysis (D3-DNSTA) scores domains on length, dynamic DNS use, fast flux and recent registration.

Metrics that show it is working:

Percentage of managed endpoints whose queries reach the sanctioned resolver.
Hosts attempting direct external DNS or unapproved DoH per week, trending down.
Mean time to triage a PDNS block or sinkhole hit on a known C2 domain.
Dangling records found per scan, and days from discovery to removal.
Percentage of public zones signed with a valid DS chain, and resolver validation failure rate.
Percentage of DNS administration accounts with phishing-resistant MFA (target 100%).

Framework mapping

Framework	Reference	What it covers
NIST SP 800-53 Rev. 5	SC-20, SC-21, SC-22	Signed authoritative data, validating resolvers, name service architecture and provisioning
NIST SP 800-81 Rev. 3	Secure DNS Deployment Guide (March 2026)	Protective DNS, encrypted DNS, DNSSEC and logging
CIS Controls v8.1	4.9, 8.6, 9.2	Trusted DNS servers on enterprise assets; DNS query audit logs; "Use DNS filtering services on all enterprise assets to block access to known malicious domains"
ISO/IEC 27001:2022 Annex A	A.8.20, A.8.21, A.8.23, A.8.16	Networks security, security of network services, web filtering, monitoring activities
NIST CSF 2.0	PR.IR-01, DE.CM-01	Networks protected from unauthorised access; networks and services monitored
MITRE ATT&CK	T1071.004, T1568.001, T1568.002, T1572, T1048, T1584.001, T1584.002	DNS C2, fast flux, DGA, DoH tunnelling, exfiltration, subdomain hijacking, DNS server compromise
MITRE D3FEND	D3-DNSDL, D3-FRDDL, D3-HDDL, D3-FRIDL, D3-RRID, D3-DNSAL, D3-DNSTA, D3-DNSCE	Denylisting, allowlisting, traffic analysis, cache eviction

Common failure patterns

Filtering with an open back door: PDNS is set in DHCP but outbound 53, 853 and public DoH remain open, so malware resolves wherever it likes.
Logging at the wrong tier: only the forwarder to PDNS is logged, so every query appears to come from the domain controllers. Log where the client address is visible, or on the endpoint.
DNSSEC outages from manual key handling: a KSK is rolled, the registrar DS is not updated, validating resolvers return SERVFAIL and the zone disappears.
Cloud teams deleting resources, not records: dangling CNAMEs build up in zones the network team owns but nobody scans.
Password-only DNS management: the weakness exploited in the ED 19-01 campaign, made worse when nobody watches Certificate Transparency.
Requiring DoH on domain-joined Windows: Active Directory name resolution fails because internal DNS servers do not answer DoH, as Microsoft warns.

Practitioner checklist

Route all endpoint and server DNS through protective resolvers, including roaming devices.
Block outbound 53, 853 and unapproved DoH endpoints except from your resolvers.
Set Windows, Chrome, Edge and Firefox DoH policy to your resolver or off.
Enable DNSSEC validation on all recursive resolvers; sign public zones with automated DS updates.
Enforce phishing-resistant MFA, registrar lock and CAA for every public domain, and monitor Certificate Transparency.
Restrict AXFR and IXFR to named secondaries with TSIG, using XoT across untrusted networks.
Scan zones for dangling CNAME, A and MX records weekly; add "remove DNS entry" to decommissioning.
Collect resolver logs and Sysmon Event ID 22 centrally, with tunnelling and DGA detections.
Scope, vault and rotate DNS API tokens and TSIG keys used by automation.

DNS Security Guide: Protective DNS, DNSSEC and DoH