Phishing links, malware downloads and command and control traffic almost always resolve a domain name first, which makes the reputation of that name one of the cheapest points at which to detect or stop them. MITRE D3FEND names this countermeasure Domain Name Reputation Analysis (D3-DNRA) and defines it simply as "Analyzing the reputation of a domain name." It sits under the Detect tactic as a child of Identifier Reputation Analysis, alongside IP, URL and file hash reputation analysis. D3FEND's entry is thin: a definition and two patent references, with no ATT&CK mapping. This card turns that into practice: what reputation signals exist, where they are enforced, how to verify the control and where it fails. It is written for SOC engineers and network security teams; DNS architecture is covered in the DNS Security Guide.
Key takeaways
- D3FEND gives the idea, not the method. The D3FEND entry has no how-it-works text and no ATT&CK relations (D3FEND 1.6.0, checked November 2026); its two references are patents on email message reputation and finding phishing sites.
- Reputation is a score built from several signals. Blocklist listings, domain age and registration data, hosting history, observed abuse and category all feed a verdict; no single signal is reliable alone.
- Enforcement happens at the resolver, the mail gateway and the web proxy. The same verdict can block a DNS answer, quarantine an email or stop a download.
- New and compromised domains are the hard cases. A domain registered yesterday has no history, and a hijacked legitimate domain has a good one.
- Verification needs safe test domains. Test with vendor or project test entries and with the blocklist provider's documented test records, never with live malicious infrastructure.
D3-DNRA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DNRA (d3f:DomainNameReputationAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Reputation Analysis |
| Digital artefact | Domain Name (D3FEND relation: analyzes) |
| Sibling techniques | IP Reputation Analysis, URL Reputation Analysis, File Hash Reputation Analysis |
| D3FEND references | Patent US20050091319A1, "Database for receiving, storing and compiling information about email messages"; patent US8839418B2, "Finding phishing sites" |
| ATT&CK mapping in D3FEND | None, direct or inferred |
| Typical enforcement points | Recursive resolvers and protective DNS, email gateways, secure web gateways and proxies, endpoint web protection |
| Main limitation | A verdict is only as current as its feed; first-seen and compromised domains are often scored as unknown or good |
How it works
D3FEND defines D3-DNRA through its artefact. A Domain Name, in D3FEND's model, is an Identifier that identifies an IP address, and Network Traffic may contain one. The countermeasure analyses that identifier and returns a judgement about how trustworthy it is. The two patents D3FEND cites show the two classic sources of that judgement: compiling reports about email messages and the domains in them, and analysing sites to find those that host phishing.
In practice a reputation verdict draws on the following signals.
| Signal | What it shows | Source examples |
|---|---|---|
| Blocklist listing | The domain has been observed in spam, phishing, malware or botnet command and control | DNS-based domain blocklists. The Spamhaus Domain Blocklist, for example, returns codes such as 127.0.1.4 (phish domain), 127.0.1.5 (malware domain) and 127.0.1.6 (botnet C&C domain), with a separate range for abused legitimate domains |
| Registration data | How old the domain is, when it last changed or transferred | RDAP responses (RFC 9083) carry events such as registration, last changed, transfer and expiration |
| First-seen and passive DNS history | Whether the name has been resolved before, and what it pointed to | Passive DNS datasets, your own resolver logs |
| Hosting and infrastructure | Shared IP addresses, name servers and certificates with known bad domains | Threat intelligence platforms, certificate transparency data |
| Content classification | Category such as phishing, malware, newly registered, parked | Web filtering and protective DNS provider categories |
| Lexical features | Lookalike spelling, random-looking labels typical of generated domains | Lookalike monitoring, see D3-HD Homoglyph Detection and the Domain Portfolio and Lookalike Domain Management Guide |
Spamhaus notes that unknown domains start with a poor reputation by default and build good reputation over time. That design choice, treating the unknown as risky, is the main lever against newly registered attack domains.
Threats it is used against (NHI Mgmt Group view)
D3FEND does not relate D3-DNRA to any ATT&CK technique. The table below is our own view of where domain reputation typically adds detection value; it is not a D3FEND mapping. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Where reputation helps |
|---|---|---|
| T1566 | Phishing | Sender, link and landing domains scored at the mail gateway and at click time |
| T1204.001 | User Execution: Malicious Link | Resolver or proxy blocks the domain when the user clicks |
| T1583.001 | Acquire Infrastructure: Domains | Newly registered attacker domains score as unknown or new |
| T1568.002 | Dynamic Resolution: Domain Generation Algorithms | Generated names have no history and lexical anomalies |
| T1071.004 | Application Layer Protocol: DNS | Queries to known command and control or tunnelling domains |
For the attacker side see MITRE ATT&CK T1566 Phishing, T1583 Acquire Infrastructure and MITRE ATT&CK T1568 Dynamic Resolution.
Where it is implemented
| Implementation class | How the verdict is applied | Fits when |
|---|---|---|
| Protective DNS service | The resolver checks each query against threat indicators and blocks, redirects or sinkholes matches. CISA's Protective DNS Resolver, for example, does this for US federal civilian agencies and, on a limited basis, critical infrastructure pilot participants, and alerts the agency and CISA | You want coverage for roaming and cloud assets without changing internal DNS |
| Self-hosted resolver with response policy zones | BIND's response-policy feature rewrites answers using policy zones, with actions such as nxdomain, nodata, passthru, drop and tcp-only, and logs rewrites to the rpz category | You run your own recursive resolvers and can consume reputation feeds in RPZ format |
| Email gateway | Domains in the connecting host's reverse DNS, HELO, MAIL FROM, headers and body are checked against domain blocklists | Phishing is the main entry route |
| Secure web gateway or proxy | Requested hostnames are categorised and blocked or warned | Web traffic already passes through a proxy |
| Browser and endpoint web protection | Local or cloud lookups against unsafe site lists, such as Google Safe Browsing lists in browsers | Devices leave the network and bypass central DNS |
| SIEM enrichment | Resolver, proxy and mail logs enriched with reputation at ingest for hunting and alert triage | You want detection and investigation context rather than blocking |
Licensing matters. Spamhaus allows free use of its DNS blocklists only for low-volume, non-commercial users, and Google's Safe Browsing API is for non-commercial use, with commercial users directed to the Web Risk API. Check terms before wiring a feed into a production product or service. Choosing between provider types is covered in the DNS Security and Protective DNS Buyer's Guide.
Implementation steps
- Collect resolver logs first. Before blocking anything, log every query with client identity at the internal resolvers. This gives the baseline and the evidence trail; see the DNS Logging and Detection Guide.
- Choose feeds by category. Start with high-confidence categories (malware, phishing, command and control). Treat broad "suspicious" or "newly registered" categories as alert-only at first.
- Run in log-only mode. Enable the policy in passthrough or report mode for two to four weeks. Review hits against business traffic and build an allow list with an owner and expiry for each entry.
- Enforce in rings. Block on a pilot group, then all managed devices, then servers. Servers often need narrower policies because automated jobs fail silently when a dependency is blocked.
- Close the bypasses. Force managed devices to use the protective resolvers, block outbound DNS to other resolvers, and manage browser encrypted DNS settings; the Encrypted DNS Enterprise Guide covers the options.
- Route blocks to the SOC. A blocked command and control lookup means a host may already be infected, so the block event should open a triage ticket, not just end the connection.
- Roll back by policy, not by disabling. If a block breaks a service, add a scoped allow entry; keep logging on so the query history remains for investigations.
How to verify it works
- Documented test entries: use the test domains or test records your provider documents to confirm that a query is blocked and that the block is logged, from each network segment and from a roaming device.
- Bypass tests: from a managed device, try an external resolver and a browser with encrypted DNS enabled; both should fail or be redirected to the protective resolver.
- Feed freshness: track the age of the latest feed update on every enforcement point; a resolver running a feed that stopped updating still answers normally.
- Retrospective hunting: rescan the last 30 days of resolver logs against today's feed. Domains that were unknown at query time and are bad now show the gap new domains create, and may reveal infected hosts.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) |
|---|---|
| Managed devices whose DNS goes through the protective resolver | Above 98% |
| Feed age at every enforcement point | Under 1 hour for high-confidence categories |
| Command and control category blocks triaged | 100% within the SOC's high-severity SLA |
| Allow list entries with owner and expiry | 100% |
| Retrospective hits per month (domains bad now, unknown at query time) | Tracked and investigated |
Limits, bypasses and failure patterns
- Freshly registered domains: attack domains are often used within hours of registration, before any feed lists them. Treating "newly registered" or "unknown" as risky is what catches them.
- Compromised legitimate domains: a hijacked site or a free hosting subdomain carries the parent domain's good history. Spamhaus handles this with hostname-level "abused legit" listings, but many feeds work only at domain level.
- Shared infrastructure: blocking a cloud, CDN or file-sharing domain breaks business use, so attackers favour them. URL reputation (D3-URA) is the better layer there.
- Resolver bypass: hard-coded IP addresses, encrypted DNS to an outside resolver and personal hotspots skip resolver-based checks entirely.
- Silent feed failure: an expired subscription or a blocked update path leaves the control looking healthy while it stops learning.
- Blocking without response: treating a block as the end of the story leaves the infected host that made the query in place. The DNS Hijack Playbook covers the related case where your own domains are the ones abused.
Where identity fits
Workloads and automation resolve domains too. Build servers, CI runners and AI agents fetch packages and call APIs with credentials attached, so a lookalike or compromised domain in a dependency or a tool definition can capture tokens rather than passwords. Apply the same resolver policy to server and pipeline networks, with narrower allow lists, rather than exempting them.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection, SI-4(4) Inbound and Outbound Communications Traffic | Monitoring and controlling communications to external names |
| 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 infrastructure that enforces the verdict |
| NIST SP 800-81 Rev. 3 | Secure Domain Name System (DNS) Deployment Guide, final March 2026 | Current NIST guidance for securing the DNS protocol and infrastructure |
| NIST CSF 2.0 | DE.CM-01, ID.RA-02 | Monitoring networks; receiving threat intelligence |
| CIS Controls v8.1 | Safeguard 9.2 Use DNS Filtering Services | DNS filtering to block access to known malicious domains |
| ISO/IEC 27001:2022 Annex A | A.5.7 Threat intelligence, A.8.23 Web filtering | Using threat information and filtering access to external sites |
| MITRE ATT&CK mitigations | M1021 Restrict Web-Based Content | Our view; see M1021 Restrict Web-Based Content |
Practitioner checklist
- Log every resolver query with client identity before enforcing anything.
- Start blocking with high-confidence categories; alert on newly registered and unknown domains.
- Pilot in report mode and keep an owned, expiring allow list.
- Force managed devices to the protective resolver and block outbound DNS elsewhere.
- Manage browser and operating system encrypted DNS settings.
- Check feed licence terms and monitor feed freshness on every enforcement point.
- Send command and control blocks to the SOC as triage tickets.
- Rescan historical DNS logs against current feeds each month.
Standards and references
- MITRE D3FEND: Domain Name Reputation Analysis (D3-DNRA)
- NIST: SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide
- CISA: Protective Domain Name System (DNS) Resolver
- IETF: RFC 9083 JSON Responses for the Registration Data Access Protocol (RDAP)
- ISC: BIND 9 Configuration Reference (response-policy)
- Spamhaus: Domain Blocklist (DBL)
- Google for Developers: Safe Browsing APIs (v4)
Related NHI Mgmt Group resources: DNS Security Guide · DNS Logging and Detection Guide · Domain Portfolio and Lookalike Domain Management Guide · MITRE ATT&CK T1566 Phishing · MITRE D3FEND Guide