Dynamic blocking based on query attributes (qname/domain) instead of only client IP

[ffabretti19]

🧩 Description

Hello,

First of all, thanks for the great work on dnsdist — dynblocks are extremely useful and work very well in production environments.

I would like to understand if there are any plans (or ongoing discussions) about extending dynamic blocking capabilities beyond the current client IP–based model, to support query-based criteria such as qname (domain).

---

⚠️ Current behavior

From what I understand:

• DynBlockRulesGroup() evaluates traffic using ring buffers
• When thresholds are exceeded, the resulting dynamic block is applied to the client source IP (ComboAddress)
• This means that all traffic from that IP is impacted, regardless of which specific queries triggered the rule

This works very well for typical abuse scenarios, but has limitations in environments with:

• NAT or shared resolvers
• Mixed legitimate + abusive traffic behind the same IP
• Abuse concentrated on specific domains or qnames

---

🚧 Limitation

In our use case, we often see:

• High query rates targeting specific domains (e.g., NXDOMAIN floods, random subdomains, etc.)
• Relatively few source IPs (due to NAT or recursive resolvers)

In this scenario:

👉 Blocking per IP is too coarse-grained
👉 Blocking per domain would be much more effective and safer

Also, as noted by maintainers, dnsdist does not have strong domain-awareness (zone cuts etc.), which makes this non-trivial.

---

💡 Suggested enhancement

Would it make sense to extend dynblocks to optionally support query-based keys, instead of only client IP?

Some possible approaches:

Option 1 — Composite key

Allow dynamic blocks keyed by:

• (client IP + qname)
• or (qname) only

Option 2 — Query-scoped enforcement

Related to this existing request:
👉 #13671

Instead of blocking all traffic from an IP:

• Apply action only to matching queries

For example:

• Only queries exceeding threshold for a specific qname
• Allow other queries from the same IP to pass

---

Option 3 — New rule types

Introduce new functions like:

• setQNameRate(...)
• exceedQNameRate(...)

---

🎯 Use cases

This would help in cases like:

• NXDOMAIN amplification / random subdomain attacks
• Domain-specific DDoS patterns
• Abuse targeting a small set of domains behind large recursive platforms
• Environments where IP-based blocking causes too much collateral damage

---

❓ Question

Is this something that is being considered for future versions of dnsdist?

If not, would you see this as aligned with the design goals of dynblocks, or out of scope?

[rgacogne]

Per-domain dynamic blocking already exists, see DynBlockRulesGroup.setSuffixMatchRule. As for combining both client IP and domain, you can configure the dynamic block to set a tag, and use that tag later during the processing of regular rules to combine the result from the dynamic block logic with any selector.