Ingesting DNS telemetry

Configure your consumer using Connecting a Kafka consumer and the shared SIEM ingestion guide. Use the DNS feed schemas for field types, action catalogs, and complete payload examples.

Map operations and platform logs

Parse each Kafka value as a JSON object. The operations and platform feeds provide these fields where applicable:

Field	SIEM use
`timestamp`	Source event time
`customer_id`	Customer scope
`server`	Source host
`zone`	DNS asset or zone; absent for some repository-level operations
`actor`, `actor_type`	Executing or observing component
`action`	Event type for rules and dashboards
`log_level`	Severity
`message`	Analyst display text
`event_id`	Operations-log replay deduplication
`production_sha`	Approved configuration revision in operations records
`approved_by`	Approver identities in applicable operations records
`serial`	Zone version when supplied

Set timestamp as event time and retain its original nine fractional digits in the raw record. Store ingestion time separately. See Time provenance for the atomic-clock reference and DNS alignment assurance. Use action and structured fields for rules rather than parsing message.

Correlate a DNS change

Group operations records by customer, zone, and production_sha. Follow change-approved, change-validated, and zone-change-applied to distinguish authorization, validation, and successful deployment. Use the applied serial to associate platform signing and propagation records.

Sort by source time while preserving those causal relationships. Knot may emit signing events during a transaction before the operations tool emits its successful completion event. Arrival order and timestamp order alone do not define the deployment sequence. Deduplicate operations records by event_id when replaying data.

Map query detail

dns.queries.detail has a response schema with no log action or operations event_id. Use these fields for response inspection:

Fields	SIEM use
`timestamp`, `server`, `customer_id`, `zone`	Response time and serving context
`qname`, `qtype`, `rcode`	Queried name, record type, and result
`query_transport`, `src_v4`, `src_v6`	Client address family and source
`ecs_v4`, `ecs_v6`	EDNS Client Subnet when supplied
`answer`, `answer_v4`, `answer_v6`	Returned answers

The producer selects at most 1,000 detail events per second per sink using uniform reservoir sampling above that threshold. CNX then applies your subscription's sampling level before customer delivery: by default, up to 100 records per second across the fleet.

Request full fleet delivery from CNX if your consumer and SIEM can handle up to 10,000 records per second. This provides your full producer-selected stream, with producer sampling still in effect. See the query-detail reference for both sampling stages. Use detail for individual response inspection and sampled traffic analysis.

Customer delivery sampling applies only to query detail. Operations logs, platform logs, and query summaries have no customer sampling filter.

Map query summaries

dns.queries.summary contains aggregates rather than individual responses:

Fields	SIEM use
`timestamp`, `window_seconds`	Window start and duration
`server`, `customer_id`, `zone`, `rcode`	Grouping dimensions
`count`	Classified response count for that group and window

Sum count across servers for the same zone, response code, and window. Summary counts are independent of detail sampling. All query delivery remains best effort; interpret gaps using the DNS delivery behavior.