A resolver that refuses to answer for known malicious domains stops phishing pages, malware downloads and command and control at the cheapest point in the connection, but only for the domains on the list and only for clients that use that resolver. MITRE D3FEND calls this DNS Denylisting (D3-DNSDL, synonym DNS Blacklisting) and defines it as "Blocking DNS Network Traffic based on criteria such as IP address, domain name, or DNS query type." It sits under the Isolate tactic as a child of Network Isolation and is the parent of three narrower techniques: Forward Resolution Domain Denylisting, Forward Resolution IP Denylisting and Reverse Resolution IP Denylisting. This card covers the filter criteria D3FEND lists, how protective DNS services, response policy zones and cloud DNS firewalls implement them, how to test that blocks work, and the limits D3FEND itself records. It assumes the overview in the DNS Security Guide.
Key takeaways
- More than a domain list. D3FEND lists seven filter criteria, from client subnet and query type to time of day and response size, so a denylist can block whole classes of risky queries, not just named domains.
- The list is the control. D3FEND's considerations stress continuous maintenance of unauthorised domain lists; a stale list blocks yesterday's threats.
- ATT&CK links are inferred through a sub-artefact. D3-DNSDL blocks DNS Network Traffic; the D3FEND site relates it to DNS-based command and control (T1071.004) and Dynamic Resolution (T1568) through Outbound Internet DNS Lookup Traffic, a sub-class of that artefact.
- Bypasses are documented by D3FEND. Connections by IP address and hosts file changes produce no DNS traffic, and CDNs and file-sharing sites need URL-level filtering instead.
- Test blocks with harmless test domains. Prove each block action and each log path with a domain you control, and re-test after every list or resolver change.
D3-DNSDL at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DNSDL (d3f:DNSDenylisting) |
| Tactic | Isolate |
| Parent technique | Network Isolation |
| Child techniques | Forward Resolution Domain Denylisting (D3-FRDDL), Forward Resolution IP Denylisting (D3-FRIDL), Reverse Resolution IP Denylisting (D3-RRID) |
| Digital artefact | DNS Network Traffic (D3FEND relation: blocks) |
| Related ATT&CK mitigation | M1021 Restrict Web-Based Content (D3FEND marks it related) |
| D3FEND reference | Microsoft: Use DNS Policy for Applying Filters on DNS Queries |
| Effort | Low with a protective DNS service; medium when you run your own lists and resolvers |
| Main limitation | Blocks only listed or matched queries made through the controlled resolver |
How it works
D3FEND describes rules that filter DNS queries on these criteria. The table shows each one with an example use; the examples are ours, not D3FEND's.
| D3FEND filter criterion | Example use |
|---|---|
| Client subnet | Apply a stricter list to server or OT subnets than to user subnets |
| Type of network protocol used in the query | Treat TCP queries from endpoints differently, since large DNS responses and some tunnelling tools rely on TCP |
| Fully qualified domain name (FQDN) in the query | Block domains on threat intelligence lists (the D3-FRDDL child technique) |
| DNS server IP address that received the request | Apply policy per resolver interface, for example a guest network listener |
| Type of DNS record queried | Restrict TXT or NULL queries from hosts that have no need for them |
| Time of day the query is received | Deny categories outside business hours for kiosk or OT networks |
| Size of the response | Flag or block unusually large responses that suggest data transfer over DNS |
D3FEND's example is a DNS policy blocking queries for FQDNs that have been identified as unauthorised. The three children narrow the idea: blocking on the queried domain name (D3-FRDDL), blocking answers that contain a denied IP address (D3-FRIDL), and blocking reverse lookups for denied IP addresses (D3-RRID). Their own pages cover each in depth: D3-FRDDL Forward Resolution Domain Denylisting, D3-FRIDL Forward Resolution IP Denylisting and D3-RRID Reverse Resolution IP Denylisting.
Block actions
The Response Policy Zone (RPZ) format, described in the expired individual Internet-Draft draft-vixie-dnsop-dns-rpz-00 (2018) and implemented in BIND 9, names the common responses: NXDOMAIN (the name does not exist), NODATA (the name exists but has no records of that type), DROP (no response), TCP-Only, PASSTHRU (an exception) and Local Data (a rewritten answer, for example pointing to a block page or sinkhole). Its triggers are Client IP Address, QNAME, Response IP Address, NSDNAME and NSIP, which line up with the D3FEND criteria and children. A rewritten answer to a block page helps users and the help desk; NXDOMAIN or DROP gives attackers less information. Windows Server DNS policies use the IGNORE action, which drops the query so the client times out.
ATT&CK techniques D3FEND relates to D3-DNSDL
Relationship type: inferred only. D3FEND has no direct ATT&CK mapping for D3-DNSDL, and no ATT&CK technique in the D3FEND data acts directly on the DNS Network Traffic artefact. The D3FEND site shows the two rows below as inferred relationships through the sub-artefact Outbound Internet DNS Lookup Traffic, which these techniques produce (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What denylisting does |
|---|---|---|---|
| T1071.004 | Application Layer Protocol: DNS | Sub-artefact: Outbound Internet DNS Lookup Traffic | Queries to known command and control zones fail; record-type and response-size rules can disrupt DNS tunnelling tools |
| T1568 | Dynamic Resolution | Sub-artefact: Outbound Internet DNS Lookup Traffic | Domains already identified as generated or fast-flux are blocked when they appear on intelligence feeds; new ones are not |
The attacker side is covered in MITRE ATT&CK T1071 Application Layer Protocol and MITRE ATT&CK T1568 Dynamic Resolution.
Where it is implemented
Platforms and services are listed alphabetically.
| Implementation | Denylisting features from the documentation |
|---|---|
| AWS Route 53 Resolver DNS Firewall | Rule groups of domain lists with BLOCK, ALERT or ALLOW actions, custom or AWS-managed lists, customisable block responses; covers queries through Route 53 VPC Resolver |
| Azure DNS resolver policy | Domain lists with wildcards, Block, Alert or Allow traffic rules, a Microsoft-managed threat intelligence feed in alert or block mode, CNAME chain matching |
| BIND and other RPZ resolvers | Response policy zones with the triggers and actions above; zones can be fed from internal or commercial lists |
| Google Cloud DNS response policies | Rules on a VPC network that override answers for matching names with local data, with bypass rules for exceptions |
| Government protective DNS | CISA's Protective DNS Resolver for US Federal Civilian Executive Branch agencies blocks resolution of known malicious domains and IP addresses and supports DoH and DoT. The UK NCSC's PDNS for eligible public sector bodies keeps its block rules in an RPZ, shows users a block page and offers SIEM connectors and a roaming client using DoH |
| Windows Server DNS | Query resolution policies with Add-DnsServerQueryResolutionPolicy on client subnet, transport and internet protocol, server interface, FQDN, query type and time of day criteria, with the IGNORE action |
Commercial protective DNS services follow the same model. Evaluation criteria are in the DNS Security and Protective DNS Buyer's Guide, and the ATT&CK mitigation that groups these controls is described in M1021 Restrict Web-Based Content.
Implementation steps
- Make the resolver the only path. Point all clients at managed resolvers, block outbound TCP and UDP 53 and DNS over TLS on TCP 853 to anything else, and manage encrypted DNS settings in browsers and operating systems. See the Encrypted DNS Enterprise Guide.
- Choose list sources. Combine a maintained threat intelligence feed (managed list, protective DNS service or commercial RPZ feed) with an internal list for incident indicators. Record who can add entries and how fast.
- Start in alert mode. Run new lists and new criteria rules as alert or log-only for one to two weeks (an example period) and review false positives.
- Enforce in rings. Switch to block for IT and security staff first, then wider groups. Keep a PASSTHRU or allow exception path with an owner and expiry for each exception.
- Feed the SOC. Send every block to the SIEM with client IP, queried name, rule and list name. A blocked lookup is often the first sign of an infected host.
- Use it in incidents. Add incident indicators to the internal list within minutes, then clear caches so cached answers do not outlive the block; see D3-DNSCE DNS Cache Eviction.
- Roll back safely. Rolling back a bad entry means adding a PASSTHRU or allow rule, or removing the entry, never turning off the whole policy.
How to verify it works
- Test domain: put a domain you control on the internal list and resolve it from each network segment. Expect the configured block response and a SIEM event.
- Feed freshness: track when each list was last updated and alert if a feed stops updating.
- Bypass check: from a test host, try an external resolver, DoT and a DoH endpoint; each must fail.
- Criteria rules: for record type or size rules, generate a test query of that type to a domain you control and confirm the rule fires.
- Coverage check: compare the number of hosts seen in resolver logs with your asset inventory. Hosts missing from the logs are using another path.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Managed hosts seen in resolver logs | Above 98% of inventory | Shows the resolver really is the path |
| Time from new incident indicator to enforced block | Under 30 minutes | Speed of using DNS as a containment lever |
| Hours since last feed update | Within the feed's stated cadence | Catches stale lists |
| Blocked lookups triaged within the SOC SLA | Above 95% | Turns blocks into detections |
| Open exceptions past expiry | Zero | Stops the denylist eroding |
Analysis of blocked and allowed queries is covered in D3-DNSTA DNS Traffic Analysis and the DNS Logging and Detection Guide.
Limits, bypasses and failure patterns
D3FEND records four considerations: avoid over-blocking and under-blocking; maintain unauthorised domain lists continuously as site content changes; file sharing and content delivery networks may need finer URL blocking; and access by IP address, or after a local hosts file change, may produce no DNS traffic at all. In practice these lead to these failure patterns.
- New domains are not on any list: denylisting is reactive. Newly registered or generated domains resolve until a feed lists them. Reputation scoring helps; see D3-DNRA Domain Name Reputation Analysis.
- Shared hosting and CDNs: blocking a shared parent domain breaks legitimate services, so attackers favour them and the block falls to URL filtering.
- Direct IP and hosts file: no lookup, no block. Outbound IP filtering covers this; see D3-OTF Outbound Traffic Filtering.
- Encrypted DNS to outside resolvers: clients or malware using their own DoH provider skip the policy.
- Roaming devices: laptops off the corporate network lose protection unless a roaming client or always-on tunnel sends their DNS to the managed resolver, as NCSC PDNS Roaming does.
- Blocks nobody reads: a block without a SIEM alert prevents one connection but leaves the infected host in place.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Filtering communications at managed boundaries |
| NIST SP 800-53 Rev 5 | SC-21, SC-22 | Recursive resolver integrity and architecture for name resolution |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Using DNS blocks as monitoring events |
| NIST CSF 2.0 | PR.IR-01, DE.CM-01 | Protecting networks from unauthorised access; monitoring network services |
| MITRE ATT&CK mitigations | M1021 Restrict Web-Based Content, M1037 Filter Network Traffic | D3FEND relates M1021; M1037 covers IP-level bypasses |
| MITRE D3FEND | Network Isolation, D3-DNSDL, D3-FRDDL, D3-FRIDL, D3-RRID | Parent, technique and children |
Related countermeasures
- DNS Allowlisting (D3-DNSAL): the default-deny sibling for predictable workloads; see D3-DNSAL DNS Allowlisting.
- Hierarchical Domain Denylisting (D3-HDDL) and Homoglyph Denylisting (D3-HDL): children of D3-FRDDL that refine domain blocking; see D3-HDDL Hierarchical Domain Denylisting.
- DNS Traffic Analysis (D3-DNSTA): finds the tunnelling and generated domains that lists miss.
- Outbound Traffic Filtering (D3-OTF): closes the IP-based bypass.
Practitioner checklist
- Make managed resolvers the only DNS path, including for roaming devices.
- Combine a maintained threat feed with an internal incident list.
- Use client subnet, record type and response size criteria, not only domain names.
- Run new lists in alert mode before blocking.
- Send every block to the SIEM with host, name and rule.
- Give every exception an owner and an expiry date.
- Alert when a feed stops updating.
- Test each segment monthly with a domain you control.
- Pair with outbound IP filtering and URL filtering for CDNs and shared hosting.
Standards and references
- MITRE D3FEND: DNS Denylisting (D3-DNSDL)
- Microsoft Learn: Use DNS Policy for applying filters on DNS queries
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, SC-21, SC-22)
- NCSC: Protective Domain Name Service (PDNS)
- CISA: Protective Domain Name System Resolver
- IETF Datatracker: DNS Response Policy Zones (RPZ), draft-vixie-dnsop-dns-rpz-00
- AWS: How Route 53 Resolver DNS Firewall works
- Microsoft Learn: DNS security policy (Azure DNS resolver policy)
- Google Cloud: Manage response policies and rules
Related NHI Mgmt Group resources: DNS Security Guide · DNS Logging and Detection Guide · DNS Security and Protective DNS Buyer's Guide · M1021 Restrict Web-Based Content · MITRE D3FEND Guide