Attackers change domain names far more often than they change the hosting they point them at, so checking the IP addresses inside DNS answers catches new names that a domain list has never seen. MITRE D3FEND names this countermeasure Forward Resolution IP Denylisting (D3-FRIDL) and defines it as "Blocking a DNS lookup's answer's IP address value." It is a child of DNS Denylisting (D3-DNSDL) under Network Isolation in the Isolate tactic, beside Forward Resolution Domain Denylisting (D3-FRDDL) and Reverse Resolution IP Denylisting (D3-RRID). This card explains how answer filtering works, why D3FEND attaches no ATT&CK techniques to it, where resolvers implement it, how to test it and the limits D3FEND itself lists. It is for DNS and network engineers who run or buy filtering resolvers.
Key takeaways
- It filters the answer, not the question. The resolver lets the lookup happen, inspects the A and AAAA records returned and withholds the answer if an address falls in a listed range.
- It hides addresses, it does not block them. D3FEND's first consideration is that the technique does not prevent a client from contacting the listed IP, only from learning it through a lookup. Egress filtering on the same ranges does the blocking.
- No ATT&CK techniques are mapped. The D3FEND 1.6.0 page lists none, direct or inferred. The value comes from the artefact, Inbound Internet DNS Response Traffic.
- Encrypted DNS and DNSSEC change the picture. D3FEND notes that DoH and DoT hide answers from inline devices and that rewriting answers fails against DNSSEC-validating clients.
- Build it into the resolver. Applying the rule inside the recursive resolver, for example as an RPZ response IP trigger, avoids the interception problems of inline devices.
D3-FRIDL at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FRIDL (d3f:ForwardResolutionIPDenylisting) |
| Synonym | Forward Resolution IP Blacklisting |
| Tactic | Isolate (via Network Isolation) |
| Parent technique | DNS Denylisting (D3-DNSDL) |
| Siblings | Forward Resolution Domain Denylisting (D3-FRDDL); Reverse Resolution IP Denylisting (D3-RRID) |
| Digital artefact | Blocks Inbound Internet DNS Response Traffic |
| D3FEND reference | Microsoft, "Use DNS Policy for Applying Filters on DNS Queries" |
| ATT&CK mapping | None listed by D3FEND (direct or inferred), checked November 2026 |
| Typical placement | Recursive resolvers and protective DNS services; less often inline DNS-aware devices |
How it works
D3FEND describes the process in three steps. Responses to forward resolution requests (a name goes out, addresses come back) are collected. The addresses in each response are compared with the denylist. If an address is in a listed range, the response is dropped and not forwarded to the client. The block can be done by an inline device dropping the traffic, or by the DNS server changing the response. To stop client applications hanging, D3FEND notes that it is common to replace the listed value with an address in 127.0.0.0/8 or with the address of a honeypot run by the network team.
The design point is reach. A domain denylist (D3-FRDDL) fails on a name registered this morning. If that name points at a hosting range already known to be hostile, the answer still contains a listed address, and D3-FRIDL catches it. The technique therefore complements domain lists rather than replacing them.
RPZ response IP triggers
In a Response Policy Zone the Response IP Address trigger is the RPZ form of D3-FRIDL. According to the RPZ Internet-Draft (draft-vixie-dnsop-dns-rpz-00, an expired individual Informational draft with no IETF standing, checked November 2026), it matches A and AAAA records in the answer section only. Addresses are written as the prefix length followed by the octets in reverse under the rpz-ip label, so the draft's example 24.0.2.0.192.rpz-ip covers 192.0.2.0/24. The policy action then decides the outcome: NXDOMAIN, NODATA, DROP or local data such as a sinkhole address.
| Option | Action on a listed answer | Client effect | Trade-off |
|---|---|---|---|
| Drop the response (inline device or RPZ DROP) | Discard | Client waits and times out | Simple, but slow failures and unclear helpdesk calls |
| NXDOMAIN or NODATA rewrite | Replace answer with a negative response | Fast failure | No record for the user of why it failed |
| Loopback substitution (127.0.0.0/8) | Replace address | Connection fails locally | Named by D3FEND as common practice; no telemetry on follow-up connections |
| Sinkhole or honeypot address | Replace address with a defender-run host | Client connects to the sinkhole | Gives evidence of what the client tried to send; the sinkhole must be secured and monitored |
A defensive use beyond threat feeds
As general practice (NHI Mgmt Group view, not part of D3FEND), the same mechanism is used against DNS rebinding: a resolver withholds public-domain answers that contain private address ranges (such as the RFC 1918 ranges or 127.0.0.0/8), so a hostile external name cannot point a browser at internal services. Many resolvers expose this as a dedicated private-address or rebinding setting. Internal names that legitimately resolve to private addresses must be exempted, usually by domain.
ATT&CK techniques and D3-FRIDL
D3FEND lists no ATT&CK techniques for D3-FRIDL, neither direct nor inferred (D3FEND 1.6.0, checked November 2026). The sibling D3-FRDDL is related by inference to T1071.004 DNS and T1568 Dynamic Resolution through the outbound lookup artefact; D3-FRIDL works on the inbound response artefact, for which D3FEND draws no ATT&CK relation. In our view (NHI Mgmt Group, not a D3FEND mapping) the technique is most useful against infrastructure reuse behind rotating domains, the pattern described in MITRE ATT&CK T1568 Dynamic Resolution, provided the address ranges are known.
Where it is implemented
| Implementation class | How answer filtering is applied | Fits when |
|---|---|---|
| Self-managed recursive resolvers | RPZ zones with rpz-ip entries (for example in BIND 9 through the response-policy statement), or built-in private address filtering for rebinding protection | You run resolvers and can source reliable IP feeds |
| Protective DNS services | NSA and CISA describe protective DNS as a policy-implementing resolver that checks both domain names and returned IP addresses against threat intelligence | You want managed feeds and roaming coverage |
| Inline DNS-aware devices | Parse response traffic on UDP and TCP port 53 and drop matches | Resolvers are outside your control; only practical for unencrypted DNS |
D3FEND stresses that the technique must sit logically between the application that receives the response and the server that sent it. Inside the resolver satisfies that for every client using it. For the wider service see the Protective DNS Guide.
Implementation steps
- Make the resolver the only path. Block outbound DNS on port 53 and DoT on port 853 except from approved resolvers, and control DoH, as the NSA and CISA guidance recommends. See the Encrypted DNS Enterprise Guide.
- Choose IP sources carefully. Use ranges dedicated to hostile infrastructure. Shared hosting and content delivery addresses serve thousands of legitimate sites, so listing them causes broad outages.
- Pick the action. A sinkhole address gives the best evidence; loopback substitution is the simplest. Decide how DNSSEC-signed answers are handled before enforcing (see limits).
- Pilot in log-only mode. Record which names would have been rewritten for one to two weeks (an example period) and review false positives.
- Mirror the list in egress filtering. Because hiding an address does not block it, apply the same ranges at the firewall. See D3-OTF Outbound Traffic Filtering.
- Log and alert. Send rewrites, with client, queried name, returned address and rule, to the SIEM. A new domain resolving into a listed range is a useful indicator in itself.
- Keep a rollback. Switch the response IP zone to passthrough rather than deleting it, so history and rule numbering survive.
How to verify it works
- Test record: create a test name in a zone you control that resolves to an address in a test range, list that range, and query from each segment. The answer must be rewritten and logged.
- IPv6 check: repeat with an AAAA record. Lists that cover only IPv4 leave the IPv6 path open.
- Encrypted path check: from a test host, attempt DoH to an external provider. It should be blocked; if it succeeds, the filter is bypassable.
- Egress pairing check: attempt a direct connection to the test address. It should be blocked at the firewall too.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Resolvers with the response IP policy loaded | All production resolvers | A single unfiltered resolver is a bypass |
| Listed ranges also enforced at egress | 100% | Closes the "hidden but reachable" gap |
| False-positive rewrites reported per month | Falling after pilot | Shows list quality |
| Rewrites triaged by the SOC | All server-originated rewrites | Turns blocks into detections |
Limits, bypasses and failure patterns
Most of these limits are stated in D3FEND's own considerations for the technique.
- Hidden is not blocked: a client that already knows the address, or receives it another way, still connects.
- Many transports: D3FEND notes DNS uses UDP port 53, with TCP port 53 for responses over 512 bytes or after no UDP response. Inline devices must parse both.
- Encrypted DNS: DoH and DoT hide answers from inline devices, and D3FEND notes browsers have enabled them after updates. Inspecting them requires TLS interception; the cleaner fix is forcing clients onto your resolver.
- DNSSEC: D3FEND notes that replacing a response does not work when the nameserver protects integrity with DNSSEC. The RPZ draft says that by default policy is not applied when the client asks for DNSSEC data and signatures exist; an optional break-dnssec setting rewrites anyway, and validating clients then reject the altered answer. Drop or NXDOMAIN outcomes still prevent the client using the answer.
- Collateral damage: listing shared hosting or content delivery ranges blocks unrelated sites and leads teams to switch the control off.
- Stale lists: hostile ranges are reassigned. Lists need expiry and review like domain lists.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Paired egress enforcement on the same ranges |
| NIST SP 800-53 Rev 5 | SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) | The resolver tier where answers are filtered |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Rewrite logs as monitoring data |
| MITRE ATT&CK mitigations | M1037 Filter Network Traffic | The mitigation family that contains DNS and IP filtering |
| MITRE D3FEND | D3-DNSDL, D3-FRIDL | Parent and technique |
See M1037 Filter Network Traffic.
Related countermeasures
- DNS Denylisting (D3-DNSDL): the parent. See D3-DNSDL DNS Denylisting.
- Forward Resolution Domain Denylisting (D3-FRDDL): blocks by queried name. See D3-FRDDL Forward Resolution Domain Denylisting.
- Reverse Resolution IP Denylisting (D3-RRID): blocks reverse lookups of listed addresses. See D3-RRID Reverse Resolution IP Denylisting.
- Outbound Traffic Filtering (D3-OTF): blocks the connection the address would have been used for. See D3-OTF Outbound Traffic Filtering.
Practitioner checklist
- Apply answer filtering inside the recursive resolver, not only inline.
- Force all client DNS through that resolver; control DoH and DoT.
- List only ranges dedicated to hostile infrastructure, never shared hosting.
- Cover both A and AAAA answers.
- Mirror every listed range in egress filtering.
- Decide and document DNSSEC handling before enforcing.
- Exempt internal names before enabling private-address filtering.
- Log rewrites with name, address and rule, and triage server-originated ones.
Standards and references
- MITRE D3FEND: Forward Resolution IP Denylisting (D3-FRIDL)
- MITRE D3FEND: Forward Resolution Domain Denylisting (D3-FRDDL)
- IETF Datatracker: DNS Response Policy Zones (RPZ), draft-vixie-dnsop-dns-rpz-00
- NSA and CISA: Selecting a Protective DNS Service
- Microsoft Learn: Use DNS Policy for Applying Filters on DNS Queries
- ISC: BIND 9 Configuration Reference
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · DNSSEC Deployment Guide · D3-DNSDL DNS Denylisting · MITRE D3FEND Guide