A reverse DNS lookup turns an IP address into a name, and when that address belongs to attacker infrastructure the answer can hand malware or an operator a domain it should never learn. MITRE D3FEND names the countermeasure Reverse Resolution IP Denylisting (D3-RRID), synonym Reverse Resolution IP Blacklisting, and defines it as "Blocking a reverse lookup based on the query's IP address value." It sits under the Isolate tactic as a child of DNS Denylisting (D3-DNSDL), alongside Forward Resolution Domain Denylisting and Forward Resolution IP Denylisting. This is a narrow technique, so this card is short: how it works, the ATT&CK relations D3FEND infers, how to implement it on a resolver, how to test it and where it is bypassed. It is written for DNS and network security engineers who already run a protective or filtering resolver.
Key takeaways
- It matches the question, not the answer. D3-RRID inspects the IP address inside a reverse (PTR) query and drops the query if that address is on the denylist; forward-answer address blocking is a different technique, D3-FRIDL.
- The IP sits in the query name. A reverse lookup for 192.0.2.10 asks for 10.2.0.192.in-addr.arpa, so implementations match reversed names under in-addr.arpa and ip6.arpa.
- D3FEND's ATT&CK links are inferred. D3FEND relates D3-RRID to DNS (T1071.004) and Dynamic Resolution (T1568) because it blocks Outbound Internet DNS Lookup Traffic.
- Coverage depends on resolver control. D3FEND warns that DNS over HTTPS and DNS over TLS complicate collection; clients that bypass the enterprise resolver bypass the control.
- The list must stay fresh. D3FEND's considerations call for maintenance cycles so the denylist is not stale; feed it from the same intelligence as IP blocking.
D3-RRID at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-RRID (d3f:ReverseResolutionIPDenylisting) |
| Tactic | Isolate |
| Parent technique | DNS Denylisting (D3-DNSDL), under Network Isolation (D3-NI) |
| Siblings | Forward Resolution Domain Denylisting (D3-FRDDL), Forward Resolution IP Denylisting (D3-FRIDL) |
| Digital artefact (relation: blocks) | Outbound Internet DNS Lookup Traffic |
| D3FEND reference | Microsoft: Use DNS Policy for Applying Filters on DNS Queries |
| Enforcement point | Recursive resolver or protective DNS service; DNS-aware firewall |
| Main limitation | Only affects queries that reach the controlled resolver in a form it can read |
How it works
D3FEND's description has three steps: reverse resolution queries are collected, the IP addresses in them are examined, and if an address falls in a denylisted range the query is dropped. The goal is to stop a client learning a domain deemed potentially malicious that a reverse response would have delivered.
In DNS terms, a reverse query is a PTR query for the address written backwards under in-addr.arpa (IPv4) or as reversed hexadecimal nibbles under ip6.arpa (IPv6). Blocking a whole range means blocking every name under the matching reverse zone label, for example everything under 2.0.192.in-addr.arpa for 192.0.2.0/24. Ranges that do not fall on octet (or nibble) boundaries need several entries.
Practical value is modest but real: reverse lookups are how tools and scripts turn an address into a host name, whoever runs them. Blocking reverse resolution for known hostile ranges denies that information and, when logged, flags hosts that are interested in those ranges.
ATT&CK techniques D3FEND relates to D3-RRID
Relationship type: inferred only. The D3FEND site derives these because D3-RRID blocks Outbound Internet DNS Lookup Traffic and labels them inferred and experimental (checked November 2026). IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | How reverse lookup blocking interferes |
|---|---|---|
| T1071.004 | Application Layer Protocol: DNS | Denies a DNS channel the answers it would get for PTR queries in hostile ranges, and logs the attempt |
| T1568 | Dynamic Resolution | Removes reverse resolution as a way to learn infrastructure names tied to attacker address space |
| T1071 | Application Layer Protocol (parent) | Listed by D3FEND at parent level |
See MITRE ATT&CK T1568 Dynamic Resolution and T1071 Application Layer Protocol.
Where it is implemented
| Implementation class | Matching method | Notes |
|---|---|---|
| Response Policy Zone (RPZ) on a recursive resolver | QNAME trigger on the reverse name (for example a rule for the range's in-addr.arpa label plus a wildcard for names beneath it) | The RPZ draft states a rule for a name does not cover its subdomains, so pair a name rule with a wildcard rule. The Response IP Address trigger matches A and AAAA records in answers, which is forward IP denylisting, not D3-RRID. Actions in the draft include NXDOMAIN, NODATA, DROP and PASSTHRU. |
| Windows Server DNS policy | Query resolution policy with the FQDN criterion (plus Query Type PTR), action IGNORE | Microsoft documents Add-DnsServerQueryResolutionPolicy with criteria Client Subnet, Transport Protocol, Internet Protocol, Server Interface IP address, FQDN, Query Type and Time of Day; test that the FQDN criterion matches your reverse names before relying on it |
| Protective DNS services | Provider-managed denylists | Check whether the provider applies IP-based lists to PTR queries as well as to forward answers |
| DNS-aware firewalls | DNS query inspection on 53 | Only for unencrypted DNS on the inspected path |
RPZ is described in an IETF individual Internet-Draft (draft-vixie-dnsop-dns-rpz-00, status expired, checked November 2026) and implemented by several resolvers; behaviour can differ, so confirm against your resolver's documentation.
Implementation steps
- Make the resolver unavoidable. Allow outbound DNS (UDP and TCP 53) and DNS over TLS (TCP 853) only from the enterprise resolvers, and set a DoH policy for browsers and operating systems; see the Encrypted DNS Enterprise Guide.
- Choose the source list. Use the same IP intelligence feed that drives firewall blocking, limited to ranges with clear attribution, and record each entry's source and expiry.
- Convert ranges to reverse names. Generate in-addr.arpa and ip6.arpa labels per octet or nibble boundary, with wildcards for names beneath them.
- Log first. Run the policy in a logging or PASSTHRU-with-log mode to see which internal hosts and tools issue these PTR queries.
- Enforce. Switch to NXDOMAIN or drop. NXDOMAIN gives a fast, clean failure to tools; dropping (IGNORE) makes clients wait for a timeout, which can slow legitimate monitoring tools that do reverse lookups.
- Maintain. Refresh on a set cycle and expire entries automatically, as D3FEND's considerations require.
How to verify it works
- Positive test: from a client, query PTR for an address in a denylisted test range through the enterprise resolver; expect the chosen block response and a resolver log entry showing the client and the rule.
- Negative test: query PTR for an address outside the list; expect a normal answer.
- Boundary test: query the first and last address of a non-octet-aligned range to confirm every reverse label was generated.
- Bypass test: attempt the same query direct to a public resolver on 53 and over DoT on 853; both should be blocked by egress rules.
- Measures: share of client DNS traffic through the controlled resolvers; denylist age (oldest entry and last refresh); count of blocked PTR queries per host, reviewed when a host appears for the first time.
Limits, bypasses and failure patterns
- Encrypted or alternative DNS paths. D3FEND notes that DoH and DoT, often enabled in browsers after an update, complicate collecting the IP addresses in queries; direct-to-internet DNS bypasses the resolver entirely.
- Wrong trigger type. Building the rule with an answer-address trigger blocks forward lookups that resolve into the range, not reverse lookups for it.
- Stale lists. Hosting addresses are reassigned; an unmaintained list blocks innocent ranges and misses new ones.
- Breaking your own tools. Monitoring, mail and logging systems perform reverse lookups at scale; prefer fast NXDOMAIN responses and test with those teams.
- Overestimating effect. The attacker already has the IP address; this technique denies a name, not a connection. Pair it with IP blocking under D3-OTF Outbound Traffic Filtering.
Framework mapping
| Framework | Reference |
|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) |
| NIST CSF 2.0 | PR.IR-01; DE.CM-01 |
| CIS Controls v8.1 | 9.2 Use DNS Filtering Services |
| ISO/IEC 27001:2022 Annex A | A.8.20 Networks security |
Related countermeasures
- DNS Denylisting (D3-DNSDL): the parent. See D3-DNSDL DNS Denylisting.
- Forward Resolution IP Denylisting (D3-FRIDL): blocks answers resolving into bad ranges. See D3-FRIDL Forward Resolution IP Denylisting.
- Forward Resolution Domain Denylisting (D3-FRDDL): blocks lookups by name. See D3-FRDDL Forward Resolution Domain Denylisting.
- DNS Traffic Analysis (D3-DNSTA): detects the patterns this control cannot block. See D3-DNSTA DNS Traffic Analysis.
Practitioner checklist
- Force all client DNS through controlled resolvers and set a DoH and DoT policy.
- Build reverse-name rules from the same IP intelligence used for firewall blocks.
- Use QNAME-style rules on reverse names, not answer-address triggers.
- Cover IPv6 ranges under ip6.arpa as well as IPv4.
- Log before enforcing and agree the block response with monitoring teams.
- Expire and refresh entries on a fixed cycle.
- Test positive, negative, boundary and bypass cases on a schedule.
Standards and references
- MITRE D3FEND: Reverse Resolution IP Denylisting (D3-RRID)
- Microsoft Learn: Use DNS Policy for Applying Filters on DNS Queries
- IETF: DNS Response Policy Zones (RPZ), draft-vixie-dnsop-dns-rpz-00
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, SC-21)
- MITRE D3FEND: Network Traffic Filtering (D3-NTF)
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · DNS Logging and Detection Guide · MITRE D3FEND Guide