Blocking one malicious hostname rarely helps, because attackers rotate subdomains under a domain they control far faster than defenders can list them. MITRE D3FEND names the countermeasure Hierarchical Domain Denylisting (D3-HDDL) and defines it as "Blocking the resolution of any subdomain of a specified domain name." It sits under the Isolate tactic as a child of Forward Resolution Domain Denylisting (D3-FRDDL), which blocks Outbound Internet DNS Lookup Traffic. This card covers how hierarchical blocking is expressed in common resolvers, the two ATT&CK techniques D3FEND relates to it, how to prove a block works and where it leaks. It is written for DNS, network and detection engineers who run resolvers or protective DNS services.
Key takeaways
- Block the zone, not the host. One hierarchical entry covers every current and future subdomain of the listed domain, which is what makes it useful against command and control that rotates hostnames.
- The apex is a separate decision. In Response Policy Zones a wildcard entry matches subdomains only, so blocking a domain and everything under it takes two entries; other resolvers differ, so test both.
- D3FEND relates it to two techniques. Application Layer Protocol: DNS (T1071.004) and Dynamic Resolution (T1568), both inferred through DNS lookup traffic.
- Shared parents are the main risk. Listing a domain that hosts many tenants (a cloud or dynamic DNS provider) blocks legitimate business traffic too.
- A resolver only blocks queries it sees. Hard-coded resolvers, encrypted DNS to outside providers and direct-to-IP connections bypass it.
D3-HDDL at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-HDDL (d3f:HierarchicalDomainDenylisting) |
| Tactic | Isolate |
| Parent technique | Forward Resolution Domain Denylisting (D3-FRDDL), under DNS Denylisting |
| Digital artefact | Outbound Internet DNS Lookup Traffic (relation inherited from the parent: blocks) |
| Synonym | Hierarchical Domain Blacklisting |
| D3FEND references | Microsoft: Use DNS Policy for Applying Filters on DNS Queries; Verisign patent on embedding threat context into response policy zones |
| Where it runs | Internal recursive resolvers, protective DNS services, DNS firewalls on network security appliances |
| Main limitation | Only affects queries that reach the controlled resolver; list quality decides both coverage and false positives |
How it works
D3FEND describes a denylist "that contains DNS names and corresponding subdomains, including wildcards, that should be blocked for a given lookup." When a client asks the resolver for any name, the resolver walks up the labels of the query name and checks each parent against the list. A match on example.net or *.example.net stops resolution for a1.c2.example.net as well as any name the attacker creates later.
D3FEND lists three considerations: the list has to be kept current, it needs "identified maintenance cycles" so entries do not go stale, and "Other domains that resolve to the domain of interest for blocking (CNAME, etc)" must be handled. The last point matters because an allowed name can point at a blocked one through a CNAME chain.
How common resolvers express a hierarchical block
| Resolver or format | Hierarchical form | Apex behaviour | Block response options |
|---|---|---|---|
| Response Policy Zones (RPZ), used by several resolvers | A wildcard owner name such as *.example.net in the policy zone | The wildcard matches subdomains only; the RPZ draft says "two policy RRsets must be used, one for the domain itself and another for a wildcard subdomain" | CNAME . (NXDOMAIN), CNAME *. (NODATA), CNAME rpz-drop. (no reply), CNAME rpz-passthru. (exemption) |
| Unbound | local-zone: "example.net." always_nxdomain (or another local-zone type) | A local zone covers the zone name and the names beneath it | always_nxdomain, always_nodata, always_refuse, always_null (0.0.0.0 or ::0), always_deny (drop), inform_deny (drop and log); Unbound also supports RPZ |
| Windows Server DNS (2016 and later) | Server-level query resolution policy with -FQDN "EQ,*.example.net" | Test whether the apex is matched; add a second criterion if needed | The documented example uses the IGNORE action, which drops the query so the client times out |
RPZ itself is described in draft-vixie-dnsop-dns-rpz-00, an expired individual Internet-Draft (June 2018) with no formal IETF standing, but it is implemented widely. Within one policy zone the draft says "an exact name match is better than one involving a wildcard", and among wildcards the trigger with the most labels wins, which lets you exempt a specific subdomain with a passthru rule.
ATT&CK techniques D3FEND relates to D3-HDDL
D3FEND labels these relationships as inferred and experimental, derived from the DNS traffic artefact.
| ATT&CK technique | Tactic | How hierarchical blocking helps | What it does not stop |
|---|---|---|---|
| T1071.004 Application Layer Protocol: DNS | Command and Control | DNS tunnelling encodes data in subdomains of an attacker zone; blocking the parent stops every encoded query reaching the attacker's authoritative server through your resolver | Tunnels through an unblocked domain or through an outside resolver |
| T1568 Dynamic Resolution | Command and Control | Fast-changing hostnames under a known parent stop resolving | Domain Generation Algorithms (T1568.002) that create new registrable domains, which have no common parent to list |
For the attacker side, see MITRE ATT&CK T1071 Application Layer Protocol and MITRE ATT&CK T1568 Dynamic Resolution.
Where it is implemented
- Internal recursive resolvers: RPZ feeds or local zones on the resolvers your clients already use. Full control, but you maintain the lists and the logging.
- Protective DNS services: managed resolvers with curated threat categories, which apply hierarchical blocks for you. See the Protective DNS Guide and the DNS Security and Protective DNS Buyer's Guide.
- Network security appliances: DNS security features on firewalls and secure web gateways that inspect or proxy DNS.
- Endpoint agents: local DNS filtering that follows roaming devices off the corporate network.
Product-specific hardening is in BIND DNS Server Hardening, PowerDNS Security and the Windows Server DNS and DHCP Security Guide.
Implementation steps
- Force DNS through controlled resolvers: allow outbound port 53 (UDP and TCP) and DNS over TLS on port 853 only from your resolvers, and use policy to manage which DNS over HTTPS endpoints browsers and operating systems may use. Without this, the denylist is optional for any client. See the Encrypted DNS Enterprise Guide.
- Choose list sources: threat intelligence feeds, incident findings and a small internal list for domains your organisation has decided to block. Record the source and date for each entry.
- Decide apex and wildcard together: for each entry, decide whether the registrable domain itself is malicious. If it is, block both the apex and
*.in RPZ-style systems. - Check for shared parents before you block: never list a parent that hosts many unrelated tenants (cloud storage, content delivery, dynamic DNS or public suffix domains) as a whole; block the specific tenant subdomain instead.
- Start in log-only mode: use a logging action (RPZ log option, Unbound inform, or a passthru policy) for a week to see which clients would be affected.
- Choose the block response: NXDOMAIN gives fast, clear failures; a redirect to a block page helps the help desk; drop (no reply) causes timeouts and slower failures. Most teams prefer NXDOMAIN or a block page.
- Enforce and log: send every block event, with client address and query name, to the SIEM.
- Rollback: keep a high-precedence passthru or allow policy that can exempt a name in minutes, and a change record for every list update.
How to verify it works
- Synthetic queries: maintain a test domain you control on the denylist. Query the apex, a known subdomain and a random new subdomain from a client on each network segment; all three should return the chosen block response.
- CNAME test: point an allowed test name at a blocked name with a CNAME and confirm the final answer is blocked.
- Bypass test: from a test client, try querying an outside resolver directly on port 53 and 853, and through DNS over HTTPS. Each attempt should fail or be logged.
- Log review: confirm block events reach the SIEM with the original client address, not only the address of a forwarding resolver.
Metrics (examples, not standards)
| Metric | Why it matters | Example target |
|---|---|---|
| Share of client DNS traffic passing through controlled resolvers | Coverage of the control | Close to 100 per cent of managed devices |
| Block events by list source per week | Shows which feeds earn their place | Reviewed monthly |
| False positive exemptions raised per month | List quality | Trending down |
| Median age of denylist entries | Staleness, which D3FEND flags | Entries reviewed within a set cycle, for example 90 days |
| Synthetic test pass rate | Enforcement on every segment | 100 per cent |
Query logging design is covered in the DNS Logging and Detection Guide.
Limits, bypasses and failure patterns
- Blocking a shared platform: a hierarchical entry on a multi-tenant parent takes out every customer of that platform, including your own suppliers.
- Missing the apex: in RPZ, a wildcard alone leaves the registrable domain itself resolving.
- Clients that avoid the resolver: malware with a hard-coded resolver, encrypted DNS to an outside provider, or direct connections to IP addresses never touch the denylist.
- New registrable domains: a DGA or a fresh registration has no listed parent; pair this with reputation and newly registered domain checks.
- Stale lists: expired malicious domains are re-registered by unrelated owners; entries without a review date block legitimate sites years later.
- No alerting on hits: a block event on a command and control domain means a device is likely compromised. Treat it as a detection, not just a prevented connection.
Framework mapping
| Framework | Reference | Fit |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection | Blocking communication with known bad destinations |
| 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 control lives |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring | Block events as detections |
| NIST CSF 2.0 | PR.IR-01 Networks and environments are protected from unauthorized logical access and usage | Enforcement |
| NIST CSF 2.0 | DE.CM-01 Networks and network services are monitored to find potentially adverse events | Monitoring of block hits |
| CIS Controls v8.1 | 9.2 Use DNS Filtering Services | Direct |
| ATT&CK mitigations | M1037 Filter Network Traffic | Closest mitigation |
This mapping is NHI Mgmt Group's view; D3FEND does not publish it.
Related countermeasures
- Homoglyph Denylisting (D3-HDL): the sibling technique under the same parent, for lookalike domains. See D3-HDL Homoglyph Denylisting.
- Domain Name Reputation Analysis (D3-DNRA): scores domains that are not yet on any list. See D3-DNRA Domain Name Reputation Analysis.
- DNS Traffic Analysis (D3-DNSTA): finds tunnelling and DGA patterns that feed the denylist. See D3-DNSTA DNS Traffic Analysis.
- Forward Resolution IP Denylisting (D3-FRIDL): blocks by the answer's IP address, which catches new domains pointing at known infrastructure. See D3-FRIDL Forward Resolution IP Denylisting.
Practitioner checklist
- Force all managed DNS through resolvers you control, including encrypted DNS.
- Record source, owner and review date for every denylist entry.
- Block both the apex and its subdomains where the whole domain is malicious.
- Never list a multi-tenant parent; block the tenant subdomain.
- Pilot new feeds in log-only mode before enforcing.
- Keep a high-precedence exemption path for urgent false positives.
- Alert on block events for command and control categories.
- Run synthetic apex, subdomain and CNAME tests on every network segment.
Standards and references
- MITRE D3FEND: Hierarchical Domain Denylisting (D3-HDDL)
- NIST: SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, SC-21, SC-22)
- IETF Datatracker: draft-vixie-dnsop-dns-rpz-00 DNS Response Policy Zones
- Microsoft Learn: Use DNS Policy for Applying Filters on DNS Queries
- NLnet Labs: unbound.conf reference (Unbound repository)
Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide · D3-HDL Homoglyph Denylisting