Most malware, phishing kits and command and control channels need a domain name to resolve before they can do anything, so refusing to resolve known-bad names stops a large share of them at the cheapest point in the network. MITRE D3FEND names this countermeasure Forward Resolution Domain Denylisting (D3-FRDDL) and defines it as "Blocking a lookup based on the query's domain name value." It is a child of DNS Denylisting (D3-DNSDL) under Network Isolation in the Isolate tactic, and it has two children of its own: Hierarchical Domain Denylisting (D3-HDDL) and Homoglyph Denylisting (D3-HDL). This card explains what the technique blocks, the ATT&CK techniques D3FEND relates it to, how resolvers and protective DNS services implement it, how to test it and how it is bypassed. It is for network, DNS and SOC engineers who already know the basics in the Protective DNS Guide.
Key takeaways
- It acts on the question, not the answer. D3-FRDDL matches the domain name in the outbound query. Its sibling D3-FRIDL acts on the IP addresses in the answer instead.
- D3FEND relates it to DNS C2 and dynamic resolution. Through the Outbound Internet DNS Lookup Traffic artefact, D3FEND infers relations to T1071.004 DNS and T1568 Dynamic Resolution.
- The list is the control. D3FEND's only consideration is that the unauthorised domain list needs continuous maintenance, which in practice means threat intelligence feeds, an exception process and review cycles.
- It only covers DNS you control. NSA and CISA note that protective DNS is bypassed by direct IP connections, alternative resolvers and encrypted DNS, so outbound DNS must be forced through the filtering resolver.
- Blocks are detections too. Every blocked query names a host that tried to reach a bad domain, which makes block logs one of the most useful sources for the SOC.
D3-FRDDL at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FRDDL (d3f:ForwardResolutionDomainDenylisting) |
| Synonym | Forward Resolution Domain Blacklisting |
| Tactic | Isolate (via Network Isolation) |
| Parent technique | DNS Denylisting (D3-DNSDL) |
| Child techniques | Hierarchical Domain Denylisting (D3-HDDL); Homoglyph Denylisting (D3-HDL) |
| Siblings under D3-DNSDL | Forward Resolution IP Denylisting (D3-FRIDL); Reverse Resolution IP Denylisting (D3-RRID) |
| Digital artefact | Blocks Outbound Internet DNS Lookup Traffic |
| D3FEND reference | Microsoft, "Use DNS Policy for Applying Filters on DNS Queries" |
| Typical placement | Recursive resolvers, protective DNS services, DNS-aware firewalls and roaming DNS clients |
How it works
D3FEND's description is that policies filter DNS queries using the fully qualified domain name of the record in the query, so queries for names identified as unauthorised are blocked. The parent technique lists other criteria a DNS policy can use (client subnet, protocol, server interface, record type, time of day, response size); D3-FRDDL is the subset that keys on the queried name.
When a query matches, the resolver can answer in several ways. The NSA and CISA guidance "Selecting a Protective DNS Service" describes three: return NXDOMAIN, redirect the user to a block page, or sinkhole the name to a defender-controlled address for investigation. A fourth option is to drop the query silently. Windows Server DNS policy, the reference D3FEND cites, does this with the IGNORE action, which leaves the client to time out.
Response Policy Zones
Most recursive resolvers express domain denylists as Response Policy Zones (RPZ), a policy format carried in an ordinary DNS zone. Its description is the Internet-Draft draft-vixie-dnsop-dns-rpz-00, an individual Informational draft that has expired and has no IETF standing (status checked November 2026). In practice it is the common format for exchanging DNS firewall feeds. The QNAME trigger is the RPZ form of D3-FRDDL.
| RPZ action | Encoding in the policy zone | What the client sees |
|---|---|---|
| NXDOMAIN | CNAME to the root (.) | The name does not exist |
| NODATA | CNAME to *. | The name exists but has no records of the requested type |
| PASSTHRU | CNAME to rpz-passthru. | Normal resolution; used to exempt names from a broader rule |
| DROP | CNAME to rpz-drop. | No response at all |
| TCP-Only | CNAME to rpz-tcp-only. | Truncated UDP answer, forcing a retry over TCP |
| Local Data | A, AAAA or CNAME records | A synthesised answer, such as a block page or sinkhole address |
The draft notes that a QNAME wildcard covers subdomains but not the name itself, so a domain and its subdomains usually need two entries. That rule is where the child technique D3-HDDL begins. See D3-HDDL Hierarchical Domain Denylisting and, for lookalike names, D3-HDL Homoglyph Denylisting.
ATT&CK techniques D3FEND relates to D3-FRDDL
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-FRDDL. The two rows below are inferred and experimental relations derived from the shared artefact Outbound Internet DNS Lookup Traffic, which D3-FRDDL blocks (D3FEND 1.6.0, checked November 2026). Both IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | Tactic | What domain denylisting does against it |
|---|---|---|---|
| T1071.004 | Application Layer Protocol: DNS | Command and Control | Blocks lookups for known C2 domains and tunnelling parent domains, cutting the channel when the domain is listed |
| T1568 | Dynamic Resolution | Command and Control | Blocks known fast flux and generated domains when feeds list them; unlisted generated names still resolve |
The relation to T1568 needs care. Its sub-techniques T1568.001 Fast Flux DNS and T1568.002 Domain Generation Algorithms exist to outrun static lists, so a denylist only helps when the feed is fast or the generated names share a parent the defender can list. Detection of new generated names belongs to D3-DNSTA DNS Traffic Analysis. See the MITRE ATT&CK T1568 Dynamic Resolution and MITRE ATT&CK T1071 Application Layer Protocol pages for the attacker side.
Where it is implemented
| Implementation class | How the denylist is applied | Fits when |
|---|---|---|
| Self-managed recursive resolvers | RPZ zones loaded into the resolver (for example the BIND 9 response-policy statement, whose policy values include nxdomain, nodata, passthru, drop, cname and tcp-only), or a native DNS policy such as Windows Server Add-DnsServerQueryResolutionPolicy with an FQDN criterion | You run your own resolvers and have staff to maintain feeds |
| Government protective DNS services | Upstream resolution against threat intelligence. CISA's Protective DNS Resolver serves federal civilian agencies and a critical infrastructure pilot and alerts the agency and CISA on blocks; the UK NCSC's PDNS is mandated for central government, blocks by not resolving the domain, shows a block page and offers SIEM connectors | You are eligible; it adds a curated national feed at no cost |
| Commercial protective DNS services | Hosted resolvers with threat and category feeds, dashboards and roaming clients | You want managed feeds and coverage for remote devices |
| DNS-aware firewalls and secure web gateways | Inspection of DNS on the wire, with domain lists from the security vendor | Resolvers are outside your control, such as guest or OT networks |
The Windows Server example in D3FEND's reference blocks a domain and everything below it with one server-level policy using the IGNORE action and an EQ,*.domain FQDN criterion. Server-level policies apply to all zones and are evaluated first. For platform hardening around these servers see Windows Server DNS and DHCP Security Guide and BIND DNS Server Hardening.
Implementation steps
- Force all DNS through the filtering resolver. Following the NSA and CISA guidance, block outbound DNS on port 53 and DNS over TLS on port 853 except from approved resolvers, block unapproved DNS over HTTPS servers, and configure browsers to use approved resolvers or turn their own DoH off. Firefox also checks the canary domain use-application-dns.net and disables default DoH when the network returns a negative answer for it; that signal does not apply to users who turned DoH on themselves. See the Encrypted DNS Enterprise Guide.
- Choose feeds and an action. Start with a threat feed (malware, phishing, C2). Use a block page or sinkhole address for user-facing networks so helpdesk calls are explainable, and NXDOMAIN for servers.
- Run in log-only mode. RPZ supports a passthrough or disabled policy override, and most services offer a monitor mode. Run for one to two weeks (an example period) and review what would have been blocked.
- Build the exception path. Exceptions are PASSTHRU entries in a higher-precedence zone, each with an owner and an expiry date.
- Enforce in rings. Move IT first, then general users, then servers. Keep a one-step rollback: switching the policy override back to passthrough.
- Feed the SOC. Send block logs, with client address, queried name and matched rule, to the SIEM. A block from a server is a stronger signal than one from a browser. See the DNS Logging and Detection Guide.
- Cover roaming devices. Laptops off the network need a roaming DNS client or always-on tunnel, or the control only works in the office.
How to verify it works
- Test domain: add a harmless test name you own to the local denylist and query it from each network segment and from a roaming laptop. Every query should get the configured action and create a log entry.
- Bypass tests: from a test host, try a direct query to a public resolver on port 53, a DoT connection on port 853 and a browser with its own DoH turned on. Each should fail or be routed back to the filtering resolver.
- Feed freshness: record the age of the last feed update per zone and alert when a feed stops updating.
- Exception review: list PASSTHRU entries past their expiry date each month.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Share of client DNS traffic seen by the filtering resolver | Above 99% on managed networks | Unseen DNS is unfiltered DNS |
| Blocked outbound DNS and DoT attempts to other resolvers | Tracked; investigate any from servers | Shows bypass attempts and misconfigured software |
| Feed update age | Within the provider's stated update interval | A stale list blocks yesterday's threats only |
| Blocks triaged by the SOC | All server blocks within one working day | Turns the control into detection |
| Expired exceptions still active | Zero | Exceptions are the slow leak in any denylist |
Limits, bypasses and failure patterns
- Hard-coded IP addresses: malware that connects to an IP without a lookup never touches the control. NSA and CISA name this as a basic limit; pair the denylist with D3-OTF Outbound Traffic Filtering.
- Encrypted DNS to outside resolvers: software that brings its own DoH endpoint resolves around the policy unless DoH endpoints are blocked at the egress.
- New and generated domains: a list cannot contain names registered an hour ago. Use newly observed domain categories where offered, and traffic analysis.
- Listing the name but not its aliases: D3FEND's HDDL considerations point to other domains that resolve to the domain of interest through CNAME. Block the chain, not only the first name.
- Exceptions that never expire: each exception is a permanent allowlist entry unless it is reviewed.
- Treating blocks as noise: a blocked lookup from a build server or a service account host can be the only sign of compromised automation. Route those blocks to an analyst.
Where identity fits
Servers, containers and CI runners resolve names on behalf of workloads and their credentials. A blocked lookup from one of these hosts often means a stolen token or a poisoned dependency is trying to call home, and the response should include rotating the machine credentials present on that host. The D3-DNSAL DNS Allowlisting page covers the stricter option for workloads with a known set of destinations.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Controlling outbound communications at managed interfaces |
| NIST SP 800-53 Rev 5 | SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver); SC-22 Architecture and Provisioning for Name/Address Resolution Service | The resolver tier where the denylist lives |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Block logs as monitoring data |
| MITRE ATT&CK mitigations | M1037 Filter Network Traffic; M1031 Network Intrusion Prevention | The mitigation families that contain DNS filtering |
| MITRE D3FEND | D3-DNSDL, D3-FRDDL, D3-HDDL, D3-HDL | Parent, technique and children |
See M1037 Filter Network Traffic and M1031 Network Intrusion Prevention.
Related countermeasures
- DNS Denylisting (D3-DNSDL): the parent. See D3-DNSDL DNS Denylisting.
- Forward Resolution IP Denylisting (D3-FRIDL): filters the addresses in answers. See D3-FRIDL Forward Resolution IP Denylisting.
- Reverse Resolution IP Denylisting (D3-RRID): blocks reverse lookups of listed addresses. See D3-RRID Reverse Resolution IP Denylisting.
- DNS Cache Eviction (D3-DNSCE): removes entries already cached for a newly listed domain. See D3-DNSCE DNS Cache Eviction.
Practitioner checklist
- Block outbound DNS on ports 53 and 853 except from approved resolvers.
- Block unapproved DoH endpoints and set browser DoH policy.
- Load at least one threat feed and record its update interval.
- Pilot in log-only mode before enforcing.
- Give every exception an owner and an expiry date.
- Send block logs with client, name and rule to the SIEM.
- Cover roaming devices with a DNS client or tunnel.
- Test with a harmless listed domain from every segment each month.
- Pair the denylist with egress IP filtering for hard-coded addresses.
Standards and references
- MITRE D3FEND: Forward Resolution Domain Denylisting (D3-FRDDL)
- Microsoft Learn: Use DNS Policy for Applying Filters on DNS Queries
- NSA and CISA: Selecting a Protective DNS Service
- CISA: Protective Domain Name System (DNS) Resolver
- NCSC: Protective Domain Name Service (PDNS)
- IETF Datatracker: DNS Response Policy Zones (RPZ), draft-vixie-dnsop-dns-rpz-00
- ISC: BIND 9 Configuration Reference
- Mozilla Support: Canary domain use-application-dns.net
Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · DNS Logging and Detection Guide · D3-DNSDL DNS Denylisting · MITRE D3FEND Guide