require dnsresolve when DNS_NAME consumers are enabled#3102
Merged
Conversation
Catches all three opt-out paths in one preset-bake check: - `-em dnsresolve` - top-level `dnsresolve: false` - `dns.disable: true` Points users at `dns.minimal: true` for the reduce-DNS-overhead case.
The previous "dnsresolve not in modules" check tripped on --list-module-options, which intentionally sets _default_internal_modules to [] to suppress internal modules from the listing. Switch to checking the three explicit user actions directly so inspection-mode code paths that strip internal modules don't trigger the gate.
Contributor
🚀 Performance Benchmark Report
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #3102 +/- ##
=====================================
- Coverage 90% 90% -0%
=====================================
Files 444 444
Lines 38339 38350 +11
=====================================
+ Hits 34282 34288 +6
- Misses 4057 4062 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ausmaster
approved these changes
May 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
dnsresolveis the intercept module that resolves every event, tags wildcards/unresolved, and rewrites wildcard hits to_wildcard.parent. Modules that watchDNS_NAME(dnsbrute, dnsbrute_mutations, the entire passive subdomain-enum family, etc.) rely on those tags to filter false positives. Disablingdnsresolvewhile keeping those modules enabled produces a flood of unverified and wildcard-tainted names with no warning -- the secondary defenses inhelpers.dns.brute(massdns canary check, etc.) are coarse backstops, not replacements.This adds a single check at the end of
bake()that catches all three opt-out paths and refuses the preset when anyDNS_NAMEconsumer is enabled:-em dnsresolve(orexclude_modules: [dnsresolve]in a preset)dnsresolve: falsedns.disable: truePure IP-range scans with no
DNS_NAMEconsumers (e.g.-t 1.2.3.0/24 -m portscanwithout speculate/portscan-style DNS handling) still pass. The error message points users atdns.minimal: truefor the legitimate "reduce DNS overhead" use case, which keepsdnsresolverunning but skips MX/NS/SRV expansion.