DNS feed schemas

Catalog

Subscriptions select feeds individually. The exact granted topics are in connection.yml. See Delivery and compatibility for retention, transport losses, replay, and schema evolution.

Common fields

The JSON timestamp is the event time. Nine fractional digits express resolution; clock accuracy and cross-host alignment are described in Time provenance.

For SIEM field mapping and correlation, see Ingesting DNS telemetry.

Delivery and compatibility

DNS serving continues independently of Kafka and customer consumption. CNX's central logging platform is the durable authority for DNS operations and platform logs. Absence from the SIEM feed does not prove that a source event did not occur. An unsampled summary describes the events counted by its producer, not a guarantee that every summary reaches the SIEM.

DNS records have no inline schema-version field. The topic identifies the feed, and action identifies the log event type where present. Optional fields may be added within the contract. Renaming or removing a documented field, changing its type, or changing an action's meaning requires a versioned contract and a customer migration plan.

Operations log: dns.logs.ops

Every record contains the common fields except that zone is conditional, plus:

Conditional correlation fields:

actor identifies the executing or observing system component. Human approval is represented separately in approved_by. Individual commit authors and merge-request submitters remain in the customer's Git history.

Action catalog

Optional fields depend on the source event. Use action and structured fields for correlation and alert rules; message is display text.

Deployment example

{
  "timestamp": "2026-10-02T09:15:04.123456000Z",
  "server": "dns-master.example.com",
  "event_id": "7b52883921ee5bce81ffad6b1de3208a",
  "actor": "dns-ops",
  "actor_type": "system",
  "action": "zone-change-applied",
  "log_level": "info",
  "customer_id": "123",
  "zone": "example.com.",
  "production_sha": "a1b2c3d4e5f60123456789abcdef0123456789abc",
  "serial": 2026100201,
  "message": "change committed successfully; zone serial 2026100201"
}

The normal change trace is change-approved, change-validated, scheduled record operations, and zone-change-applied. Rejected validation and failed deployment have separate actions. Scheduled record operations describe intention; the applied event confirms the transaction result. Platform events correlate by zone and serial because Knot has no Git-revision context.

Platform log: dns.logs.platform

Every record contains timestamp, server, actor, actor_type, action, log_level, zone, customer_id, and message. actor is dns-master or dns-slave; actor_type is system. The message preserves Knot log text.

Only recognized Knot message shapes are published. If an optional value cannot be extracted, the event is retained with that field omitted.

{
  "timestamp": "2026-10-02T09:15:04.123450000Z",
  "server": "dns-master.example.com",
  "actor": "dns-master",
  "actor_type": "system",
  "action": "dnssec-signing-complete",
  "log_level": "info",
  "zone": "example.com.",
  "customer_id": "123",
  "serial": 2026100201,
  "rrsigs_added": 7,
  "message": "DNSSEC, successfully signed, serial 2026100201, new RRSIGs 7"
}

Query detail: dns.queries.detail

Classified dnstap response events use the following fields:

Query detail has two sampling stages:

Before publishing to your customer topic, CNX selects records from the fleet's query-detail stream according to your subscription's sampling level. The default limit applies across the fleet, rather than separately to each sink.

Request full fleet delivery from CNX if your consumer and SIEM can sustain up to 10,000 records per second. This removes the additional customer delivery sampling and provides the full producer-selected stream for your customer account. Per-sink producer sampling still applies, so full fleet delivery is not a complete record of every DNS query. Delivery remains best effort; use query summaries for counts.

The additional customer sampling applies only to dns.queries.detail. Operations logs, platform logs, and query summaries have no customer sampling filter. Their event selection and transport behavior remain as documented for each feed.

{
  "timestamp": "2026-10-02T09:16:00.123456789Z",
  "server": "dns-edge.example.com",
  "query_transport": "v4",
  "zone": "example.com.",
  "customer_id": "123",
  "qname": "www.example.com.",
  "qtype": "A",
  "rcode": "NOERROR",
  "src_v4": "192.0.2.10",
  "src_v6": null,
  "ecs_v4": null,
  "ecs_v6": null,
  "answer": ["192.0.2.80"],
  "answer_v4": ["192.0.2.80"],
  "answer_v6": []
}

Query summary: dns.queries.summary

Counts include all classified responses observed by the producer, independent of detail sampling. Sum across servers for a customer-wide zone total over the same window. Summary transport remains best effort.

{
  "timestamp": "2026-10-02T09:16:00.000000000Z",
  "server": "dns-edge.example.com",
  "zone": "example.com.",
  "customer_id": "123",
  "rcode": "NOERROR",
  "window_seconds": 60,
  "count": 84000
}

Live-zone correlation

CNX publishes these synthetic TXT records in the deployed zone:

_cnx-customer-id.example.com.    TXT "123"
_cnx-meta.example.com.           TXT "sha=<zone-directory-hash>"
_cnx-production-sha.example.com. TXT "<production_sha>"

_cnx-production-sha identifies the accepted Git revision represented by the live zone. _cnx-meta identifies the source-directory hash used for drift detection. The serial in zone-change-applied identifies the first committed zone version containing the corresponding synthetic records.