[infoblox_nios] Fix NIOS 9 named log parsing

[vinit-chauhan]

Proposed commit message

[infoblox_nios] Fix NIOS 9 named log parsing

NIOS 9 prefixes named log lines with a logging-category token
(e.g. `queries:`, `security:`). The notify, zone-transfer, and
DNSSEC-validation grok patterns lacked that prefix, silently
dropping dns.question.* fields. A trailing EDNS Client Subnet
suffix on `queries` lines had the same effect: those lines fell
through to the catch-all alternative, which kept client.ip and the
raw message but none of dns.question.*.

Fix both by accepting the optional category prefix on all affected
patterns and adding an ECS_CLIENT_SUBNET pattern definition for
the suffix. Normalise dns.question.name to lowercase after
extraction (DNS names are case-insensitive, and resolvers may
0x20-encode them, which BIND logs verbatim).

Bound dns.question.class to a single token on the zone and
zone-transfer patterns, and capture the optional BIND view into
infoblox_nios.log.view. Previously a multi-view deployment logging
`zone name/class/view:` put `IN/internal` into the ECS
dns.question.class field.

Parse the message tail for query-errors, security, xfer-in, and
notify categories to extract failure_reason, action, query_context,
and transfer status. Derive ECS event.outcome and dns.response_code
from those values; raw BIND tokens stay in infoblox_nios.log.dns.*.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices (no dashboard changes)

Author's Checklist

• Pipeline unit tests updated (test-dns.log and test-dns.log-expected.json) to cover new NIOS 9 log lines for all four categories
• New fields documented in fields/fields.yml and docs/README.md
• Each new grok processor tagged and gated with a cheap prefix/suffix condition to avoid hot-path regressions
• event.outcome and dns.response_code are only set when there is enough information; DNS-specific RCODE strings are allow-listed to prevent internal BIND status tokens from leaking into dns.response_code

How to test this PR locally

# From the repo root, with elastic-package available:
cd packages/infoblox_nios
elastic-package test pipeline --data-streams log

The test-dns.log file contains representative NIOS 9 lines for each new category. Compare the rendered output against test-dns.log-expected.json.

To smoke-test against a real stack:

1. Configure Infoblox NIOS 9 to forward named logs via syslog.
2. Enable one or more of the queries, query-errors, security, xfer-in, and notify categories in the BIND logging configuration.
3. Ingest a sample via the infoblox_nios integration and confirm that dns.question.*, event.outcome, and dns.response_code are populated correctly.

Related issues

• Closes [Infoblox_nios]: enhancements or bugs after 9.0 NIOS #16636
• Closes [Infoblox_nios]: missing dns.query.name for message containing -E(0)D #16626

Screenshots

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[infra-vault-gh-plugin-prod]

Pinging @elastic/integration-experience (Team:Integration-Experience)

[Copilot]

🟡 Changes recommended

It includes unrelated DHCP expected-fixture changes (including future-dated timestamps) that should be justified in the PR scope/description or addressed to avoid noisy, potentially confusing test updates.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the infoblox_nios integration’s DNS ingest pipeline to correctly parse Infoblox NIOS 9 named logs that now include a logging-category prefix (e.g. queries:, security:), restoring dns.question.* extraction and enriching events with additional DNS outcome/context fields.

Changes:

• Extend DNS grok patterns to accept an optional category prefix and handle EDNS Client Subnet ([ECS ...]) suffixes on queries lines.
• Add parsing for query-errors, security, xfer-in, and notify message tails to populate new fields and derive event.outcome and (allow-listed) dns.response_code.
• Update package version/changelog, field definitions, docs, and pipeline tests to cover the new NIOS 9 shapes.

File summaries

File	Description
packages/infoblox_nios/manifest.yml	Bumps package version to 2.2.0.
packages/infoblox_nios/docs/README.md	Documents newly parsed DNS fields.
packages/infoblox_nios/data_stream/log/fields/fields.yml	Adds field definitions for new DNS enrichment fields.
packages/infoblox_nios/data_stream/log/elasticsearch/ingest_pipeline/pipeline_dns.yml	Updates grok patterns and adds enrichment/derivation steps for NIOS 9 DNS logs.
packages/infoblox_nios/data_stream/log/_dev/test/pipeline/test-dns.log-expected.json	Updates expected output to validate new parsing/enrichment.
packages/infoblox_nios/data_stream/log/_dev/test/pipeline/test-dns.log	Adds representative NIOS 9 named log samples across categories.
packages/infoblox_nios/data_stream/log/_dev/test/pipeline/test-dhcp.log-expected.json	Updates DHCP expected fixture timestamps (year changes across the file).
packages/infoblox_nios/changelog.yml	Adds 2.2.0 changelog entries for the DNS parsing fix and enhancements.

Review details

• Files reviewed: 7/8 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[vera-review-bot]

🟢 No issues across the latest commits a3d9e52.

A new commit triggers another review — at most once every 15 minutes. I skip the PR while it's approved or has merge conflicts.

🤖 AI-Generated Review | Vera Review Bot - v0.3.0 | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

[ilyannn]

Note: This review has been drafted with 🤖 Cursor/Claude Opus 5 under my supervision.

I checked the premise and the regression risk against a real cluster rather than off the grok, by running every fixture line through the published 2.1.2 pipeline and diffing the result against this PR's expectation file.

The premise holds. All 15 new lines extract none of dns.question.name, type or class on 2.1.2 — the bug reproduces for every category touched here (queries with an ECS suffix, query-errors, security, xfer-in, notify, dnssec). The 0x20-encoding case works too: Www.eXaMple.cH lands as www.example.ch.

No regressions. Full-field sweep over all 48 fixture lines: nothing lost on the 32 pre-existing ones, and two of them are fixed as a side effect (line 6 query failed, line 13 received notify now contribute the query name to related.hosts). The only fields dropped are infoblox_nios.log.dns.message on the three new ECS queries lines, which is intentional — they now match the structured alternative instead of the %{CLIENT} %{GREEDYDATA} catch-all, so they behave like every other parsed query line.

Nice touches worth keeping: the ecs_client_subnet group description disambiguating ECS-the-option from ECS-the-schema, the RCODE allow-list keeping internal BIND tokens out of dns.response_code, and appending the subnet address to related.ip.

Approving. One substantive comment below on dns.question.class that I'd like you to consider before merge, one on test coverage, and two nits — none of them blocking.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[Copilot]

🟢 Approval recommended

The pipeline, fields, docs, and fixtures are updated consistently to cover the NIOS 9 parsing changes and derived ECS fields without any confirmed defects in the reviewed diffs.

Review details

• Files reviewed: 7/8 changed files
• Comments generated: 0 new
• Review effort level: Lite

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: cde80f7

History

• 💚 Build #48914 succeeded a3d9e52
• 💔 Build #48913 failed 6e43179

[vinit-chauhan]

@ilyannn - I've addressed your comments in the last commit. Could you please give it another look?

[ilyannn]

Re-reviewed at cde80f7 — thanks, this addresses everything. Nice call applying the class fix to all four zone/transfer patterns rather than just the new one.

Verified the result: the expected-output file adds 283 lines with zero deletions, so none of the 48 pre-existing documents changed — the %{DATA} → %{WORD} tightening is regression-free. The new multi-view fixtures come out as dns.question.class: IN plus infoblox_nios.log.view: internal/external, event.outcome: success on the approved line confirms that branch finally executes, and the bare [ECS] line parses without a half-populated subnet object. No error.message or failure tags anywhere in the 52 docs.

One side effect I hadn't expected: bounding the class to %{WORD} also fixes RFC 2317 classless-delegation zone names, which contain a slash of their own.

notify: zone 0/25.2.0.192.in-addr.arpa/IN: sending notifies (serial 42)
  before: dns.question.name = '0'                         dns.question.class = '25.2.0.192.in-addr.arpa/IN'
  after:  dns.question.name = '0/25.2.0.192.in-addr.arpa' dns.question.class = 'IN'

Two small things before you queue it, neither needing another round from me:

1. Changelog. The bugfix entry doesn't mention that dns.question.class no longer carries the view suffix, or that infoblox_nios.log.view is now populated from zone and transfer lines. For a multi-view deployment that's a visible change on lines which already parsed — anything filtering dns.question.class: "IN/internal" stops matching after the upgrade — so it's worth a sentence in the release notes.

2. BADSIG. IANA assigns two names to RCODE 16: BADVERS (RFC 6891, EDNS) and BADSIG (RFC 8945, TSIG). You added BADVERS plus the whole rest of the TSIG family, so BADSIG is now the one case that won't reach dns.response_code while BADKEY and BADTIME will — and it's the most common of that group, since it's what a transfer failing on a mismatched TSIG key reports.

Spotted while re-reading, but out of scope here: line 24 (updating zone) is the last remaining %{DATA:dns.question.class} capture, and unlike the query patterns it has no %{VIEW}? — so in a multi-view deployment those lines miss this alternative entirely and land on the catch-all. Happy to file that separately rather than grow this PR.

Approval stands either way.

This comment has been drafted with 🤖 Cursor/Claude Opus 5 under my supervision.

[ilyannn]

LGTM as said above

[ilyannn]

One more thing, on the proposed commit message rather than the code — since that block becomes the squash commit, it's worth getting right.

"A trailing EDNS Client Subnet suffix on queries lines also blocked any match" isn't quite what happened. Simulating one of the new fixtures against published 2.1.2:

queries: client @0x7f8692d47168 89.160.20.128#42985 (git.example.com): query: git.example.com IN A -E(0)C (192.168.0.3) [ECS 67.43.156.0]

  error.message                  : None
  tags                           : None          <- no _grokparsefailure
  client.ip / client.port        : 89.160.20.128 / 42985
  infoblox_nios.log.dns.category : queries
  infoblox_nios.log.dns.message  : "(git.example.com): query: git.example.com IN A -E(0)C (192.168.0.3) [ECS 67.43.156.0]"
  dns.question.name              : None          <- the only real loss

The suffix blocked the structured query alternative, so the line fell through to the %{CLIENT} %{GREEDYDATA} catch-all — which is exactly why this PR drops infoblox_nios.log.dns.message on those three lines. As written, the message would send a future reader looking for grok failures that never occurred. (The neighbouring sentence about notify/transfer/DNSSEC is accurate — "silently dropping dns.question.*" is the right description there.)

Two smaller things in the same block: it predates cde80f7, so it doesn't mention the dns.question.class bound or the new infoblox_nios.log.view capture; and 0x20 encoding is applied by the querying resolver for spoofing entropy rather than by BIND, which logs the QNAME verbatim as received (hence Www.eXaMple.cH).

Suggested replacement:

[infoblox_nios] Fix NIOS 9 named log parsing

NIOS 9 prefixes named log lines with a logging-category token
(e.g. `queries:`, `security:`). The notify, zone-transfer, and
DNSSEC-validation grok patterns lacked that prefix, silently
dropping dns.question.* fields. A trailing EDNS Client Subnet
suffix on `queries` lines had the same effect: those lines fell
through to the catch-all alternative, which kept client.ip and the
raw message but none of dns.question.*.

Fix both by accepting the optional category prefix on all affected
patterns and adding an ECS_CLIENT_SUBNET pattern definition for
the suffix. Normalise dns.question.name to lowercase after
extraction (DNS names are case-insensitive, and resolvers may
0x20-encode them, which BIND logs verbatim).

Bound dns.question.class to a single token on the zone and
zone-transfer patterns, and capture the optional BIND view into
infoblox_nios.log.view. Previously a multi-view deployment logging
`zone name/class/view:` put `IN/internal` into the ECS
dns.question.class field.

Parse the message tail for query-errors, security, xfer-in, and
notify categories to extract failure_reason, action, query_context,
and transfer status. Derive ECS event.outcome and dns.response_code
from those values; raw BIND tokens stay in infoblox_nios.log.dns.*.

Also cosmetic: the Author's Checklist says the fixtures cover "all four categories" — it's six now (queries, query-errors, security, xfer-in, notify, dnssec).

For what it's worth I checked the linked issues too, and both Closes lines are right: all nine sample log lines in #16636 map to fixtures in test-dns.log.

This comment has been drafted with 🤖 Cursor/Claude Opus 5 under my supervision.

[elastic-vault-github-plugin-prod]

Package infoblox_nios - 2.2.0 containing this change is available at https://epr.elastic.co/package/infoblox_nios/2.2.0/