Skip to content

[medium] fix: [reversedns] fix nameserver fallback when config is an empty dict - #886

Open
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/077-reversedns-nameserver-fallback
Open

[medium] fix: [reversedns] fix nameserver fallback when config is an empty dict#886
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/077-reversedns-nameserver-fallback

Conversation

@elhoim

@elhoim elhoim commented Aug 31, 2026

Copy link
Copy Markdown
Member

BLUF — reversedns.py skips its documented 8.8.8.8 fallback when config is present but empty.

  • Problemreversedns.py falls back to Google DNS only when the config key is absent entirely; if config is present but empty or lacks nameserver, neither branch sets r.nameservers and the resolver silently uses the host's system DNS.
  • Fix — Collapses the if/else into one expression that falls back to 8.8.8.8 whenever config or config.nameserver is missing or empty.
  • Effect — PTR enrichment for requests like {"config": {}} becomes predictable instead of environment-dependent.

The reversedns module's documented fallback to Google DNS only triggers when the config key is missing entirely:

if request.get("config"):
    if request["config"].get("nameserver"):
        nameservers = []
        nameservers.append(request["config"].get("nameserver"))
        r.nameservers = nameservers
else:
    r.nameservers = ["8.8.8.8"]

If config is present but empty or lacks nameserver (e.g. {"config": {}}), neither branch sets r.nameservers, so the resolver silently falls back to the system's default nameservers instead of the documented 8.8.8.8 fallback.

An analyst who submits {"config": {}} (a common case when a config dict is built but not yet populated, or when only unrelated config keys are set) gets PTR lookups resolved through whatever DNS servers the host happens to use, rather than the documented, predictable 8.8.8.8. This can produce inconsistent or environment-dependent enrichment results, and is surprising given the module's documented behavior.

Fix

Replaced the if/else block with a single expression that falls back to 8.8.8.8 whenever config is absent, config.nameserver is absent, or either is empty/falsy:

r.nameservers = [(request.get("config") or {}).get("nameserver") or "8.8.8.8"]

This is a pure bug fix restoring the module's already-documented fallback behavior; it does not change the documented contract.

Verification

  • python -m py_compile misp_modules/modules/expansion/reversedns.py — succeeded.
  • flake8 on the changed file — clean (no output).
  • Full module test suite — 161 passed, 4 skipped, 5 subtests passed in 23.42s.

Found during a review of the repository; other findings are being submitted as separate PRs.

🤖 Generated with Claude Code

The module only fell back to the documented Google public DNS address (8.8.8.8)
when the "config" key was entirely absent from the request. When MISP sends
"config": {} (config present but no nameserver set, which happens whenever the
module is enabled without an explicit nameserver override), the else branch
that sets the fallback never runs, and the resolver silently falls back to
whatever nameservers are configured on the system running misp-modules instead
of the documented default. Analysts get PTR lookups resolved through an
unexpected resolver with no indication the documented fallback was skipped.

Replaced the presence check with a single expression that reads the
nameserver from config when present and non-empty, and otherwise uses
8.8.8.8, matching the documented behavior in all cases.

Verified with flake8 (clean) and the full test suite against a locally
started misp-modules server: 161 passed, 4 skipped, 5 subtests passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018dfYpyaSZd1nxSRLr8suj8
@elhoim elhoim changed the title fix: [reversedns] fix nameserver fallback when config is an empty dict [medium] fix: [reversedns] fix nameserver fallback when config is an empty dict Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant