D3-DNSAL DNS Allowlisting: Resolving Only Approved Domains and Proving Nothing Else Gets Through

Most malware still needs a name to resolve before it can reach its operator, so a resolver that answers only for approved domains removes a large share of command and control options in one place. MITRE D3FEND calls this DNS Allowlisting (D3-DNSAL, synonym DNS Whitelisting) and defines it as "Permitting only approved domains and their subdomains to be resolved." It sits under the Isolate tactic as a child of Network Isolation, and D3FEND models it as blocking Outbound Internet DNS Lookup Traffic. This card explains where DNS allowlisting is practical (servers, build agents, OT and workload networks rather than general user browsing), how to build it on common resolvers and cloud DNS services, how to verify that unapproved names fail and that clients cannot route around the resolver, and where the control stops. It assumes the DNS basics in the DNS Security Guide.

Key takeaways

• Allow a small set, refuse the rest. The control is a default-deny resolver policy: approved domains and their subdomains resolve, every other query gets no useful answer.
• Fit it to predictable workloads. Servers, CI runners, containers, OT networks and AI agents talk to a short, knowable list of domains. User browsing does not, so allowlisting there needs heavy exception handling.
• D3FEND links it to DNS command and control. The inferred ATT&CK relationships are Application Layer Protocol: DNS (T1071.004) and Dynamic Resolution (T1568), both of which produce outbound DNS lookups.
• The resolver must be the only path. Allowlisting fails open if clients can use another resolver, encrypted DNS to an outside provider, a hosts file entry or a direct IP connection. Pair it with outbound filtering.
• Watch the CNAME chain and the CDN. Approved services often resolve through third-party CDN names; the products described below handle redirection chains differently, and the allowlist has to match.

D3-DNSAL at a glance

D3FEND's single reference for D3-DNSAL is RFC 8904, "DNS Whitelist (DNSWL) Email Authentication Method Extension", an Informational independent submission from September 2020. That document describes DNS-published lists of trusted mail sender IP addresses, which is a different idea from resolver allowlisting. This page therefore builds on the D3FEND definition and on resolver and cloud DNS documentation rather than on the RFC.

How it works

A client asks its configured resolver for a name. The resolver checks the name against an approved list, including subdomains of approved entries. If the name matches, resolution proceeds normally. If not, the resolver drops the query, refuses it, or returns a negative answer such as NXDOMAIN, and logs the attempt. Because the client never learns an IP address, a connection to an unapproved destination by name cannot start.

Two design choices matter more than the product:

• Granularity: approving example.com usually approves every subdomain under it, which matches the D3FEND definition. Approving whole cloud or CDN parent domains can open far more than intended, because attackers can host content under the same parent domains.
• Redirection handling: an approved name that resolves through a CNAME to a CDN name must either have the chain trusted or have each target in the list. AWS Route 53 Resolver DNS Firewall inspects every domain in a redirection chain by default, and Azure DNS resolver policy applies a rule to any name whose CNAME chain contains a listed domain. Test this behaviour for your resolver before rollout.

ATT&CK techniques D3FEND relates to D3-DNSAL

Relationship type: inferred only. D3FEND does not hand-map D3-DNSAL to ATT&CK. The rows below are inferred because D3-DNSAL blocks Outbound Internet DNS Lookup Traffic and these techniques produce that artefact (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

DNS allowlisting does not stop an attacker who tunnels over an approved service or connects to an IP address directly; those cases sit with T1572 Protocol Tunnelling Defensive Guide and outbound filtering. 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 are listed alphabetically. Each builds an allowlist the same way: allow the approved list first, then refuse everything else.

Protective DNS services such as the UK NCSC's PDNS and CISA's Protective DNS Resolver are mainly denylist services for known malicious domains; they are covered on the D3-DNSDL DNS Denylisting page. Choosing a commercial service is covered in the DNS Security and Protective DNS Buyer's Guide.

Where identity fits

Workloads with machine identities are the best candidates for DNS allowlisting. A CI runner holding a cloud deploy key, a service using a payment API token or an AI agent with tool credentials needs a small set of destinations. If its credential is stolen and the runtime is hijacked, an allowlist stops the code from resolving an exfiltration domain. Agent workloads are covered in the Agent Egress Control and Network Isolation Guide.

Implementation steps

1. Pick the scope. Start with one workload network whose destinations are known, such as build agents, a server subnet or an OT historian zone.
2. Learn the real list. Collect resolver query logs for the scope for two to four weeks (an example period) and group them by registered domain. Include update services, certificate revocation endpoints (OCSP and CRL), time services and telemetry. Missing these is the most common cause of outages.
3. Write the list at the right level. Prefer specific service subdomains over whole parent domains, and record an owner and reason for each entry.
4. Deploy in alert mode. Use the platform's alert or log-only action (ALERT on AWS, Alert on Azure, or logging the RPZ catch-all) for the catch-all rule. Review hits daily and add genuine needs.
5. Close the bypass paths. Block outbound TCP and UDP 53 and DNS over TLS (TCP 853) to anything but the approved resolvers; manage browser and OS encrypted DNS settings; for networks where Firefox may enable DNS over HTTPS by default, return a negative answer for the canary domain use-application-dns.net. Mozilla documents that this disables default DoH but not DoH a user turned on. See the Encrypted DNS Enterprise Guide.
6. Switch to enforce. Change the catch-all to block, one network at a time, with a named on-call owner for the first week.
7. Keep a rollback. Rolling back means returning the catch-all rule to alert, not deleting the policy, so logs and the list are kept.

How to verify it works

• Negative test: from a host in scope, resolve a domain that is certainly not on the list (for example a fresh domain you own). It must fail, and the resolver log must show the block.
• Positive test: resolve each approved service and run its real function (package install, API call, update check).
• Bypass test: from the same host, try an external resolver on port 53, DNS over TLS on 853 and a DoH endpoint. Each must fail at the network layer.
• Chain test: resolve approved names that use CNAMEs to CDNs and confirm the policy behaves as you expect for the targets.
• Log health: alert if the resolver log stream stops, since a silent resolver log hides both blocks and bypasses.

Analysing the queries that are blocked is covered in D3-DNSTA DNS Traffic Analysis and the DNS Logging and Detection Guide.

Limits, bypasses and failure patterns

• Direct IP connections: malware with hard-coded IP addresses never asks the resolver. Outbound IP filtering is the complement; see D3-OTF Outbound Traffic Filtering.
• Abuse of approved services: attackers host payloads and command channels on popular cloud storage, code hosting and collaboration domains. If the parent domain is approved, so is the attacker's tenant.
• Uncontrolled resolvers: hosts that can reach any resolver on port 53, or encrypted DNS providers, skip the policy entirely.
• Allowlisting user networks too early: browsing pulls in many third-party domains per page, and an over-strict allowlist leads to blanket exceptions that defeat it.
• Forgetting infrastructure dependencies: certificate revocation, time synchronisation and OS update domains are easy to miss and cause failures that look unrelated to DNS.
• Fail-open by configuration: some services allow fail-open when the filter does not respond. AWS documents fail-closed as the default; changing it trades availability for protection, so record the decision.

Framework mapping

Related countermeasures

• DNS Denylisting (D3-DNSDL): the sibling for networks where a full allowlist is impractical; see D3-DNSDL DNS Denylisting.
• Domain Name Reputation Analysis (D3-DNRA): scores unknown domains during the learning phase; see D3-DNRA Domain Name Reputation Analysis.
• Outbound Traffic Filtering (D3-OTF): closes the direct IP and alternative resolver paths.
• DNS Cache Eviction (D3-DNSCE): clears cached answers after a list change during an incident; see D3-DNSCE DNS Cache Eviction.

Practitioner checklist

• Start with workload networks whose destinations are predictable.
• Build the list from at least two weeks of real resolver logs.
• Record an owner and reason for every allowlist entry and review quarterly.
• Include OCSP, CRL, time and update domains before enforcing.
• Run the catch-all rule in alert mode before blocking.
• Block outbound DNS, DoT and unmanaged DoH to anything but approved resolvers.
• Test how your resolver handles CNAME chains to CDNs.
• Run negative, positive and bypass tests after every change.
• Alert when resolver logging stops.

Standards and references

• MITRE D3FEND: DNS Allowlisting (D3-DNSAL)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, SC-21, SC-22)
• IETF Datatracker: DNS Response Policy Zones (RPZ), draft-vixie-dnsop-dns-rpz-00
• IETF: RFC 8904 DNS Whitelist (DNSWL) Email Authentication Method Extension
• AWS: How Route 53 Resolver DNS Firewall works
• Microsoft Learn: DNS security policy (Azure DNS resolver policy)
• Google Cloud: Manage response policies and rules
• Microsoft Learn: Use DNS Policy for applying filters on DNS queries
• Mozilla Support: Canary domain use-application-dns.net

Related NHI Mgmt Group resources: DNS Security Guide · Encrypted DNS Enterprise Guide · M1021 Restrict Web-Based Content · Cloud Egress Filtering · MITRE D3FEND Guide