Reports repository format

See The compliance evidence package for why this repository exists and what subscription tier it's part of.

Reports are generated automatically shortly after midnight ICT and cover the previous calendar day (00:00:00–23:59:59 ICT).

Repository structure

latest/
  ksk-attestation.json    Current DNSSEC KSK attestation and DS records
  ds-to-publish.txt       DS records ready to publish at the registrar
  key-status.json         Administrative KSK status
  zone-status.json        Zone deployment status, serial, git SHA
attestation/
  YYYY/
    MM/
      DD/
        manifest.txt      SHA-256 hash and path for each report file
        manifest.tsr      RFC 3161 timestamp token over manifest.txt
YYYY/
  MM/
    DD/
      {zone}/
        01-activity.jsonl       Zone activity recorded during the report period
        02-dnssec.jsonl         DNSSEC-related activity
        03-serving-state.txt    DNS responses observed from multiple vantage points
        04-parent-ds.txt        Parent delegation and DNSSEC validation state

01-activity.jsonl and 02-dnssec.jsonl

One JSON object per line (JSONL), no enclosing array; an empty file means no matching events were recorded during the report period. 02-dnssec.jsonl uses the same schema, filtered to DNSSEC-related activity (signing and key lifecycle events).

Source: CNX's central logging platform, filtered for events associated with the reported zone.

{"time":"2026-08-27T16:57:42.520946Z","host":"pnh-bdc-ns01","source":"knot.service","category":"IXFR","domain":"example.com.","message":"[example.com.] IXFR, incoming, remote 2001:db8::1@53 TCP, key example-transfer., finished, remote serial 2026062557, 0.00 seconds, 2 messages, 27694 bytes"}

The format is intended for direct use by reporting tools, SIEM platforms, and automated analysis systems.

Real-time export. The same activity and DNSSEC events can also be streamed continuously to your own SIEM rather than delivered once a day, with direct support for IBM QRadar collectors — contact CNX to arrange this integration.

03-serving-state.txt

Verbatim kdig output captured at report generation time, from three vantage points:

Queries issued per zone: SOA, NS, DNSKEY. The SOA serial returned by the anycast service should match the hidden master — a mismatch may indicate propagation delay or a node issue, and should be raised with CNX support. The SOA serial itself is managed by the CNX platform after initial provisioning and isn't customer-managed.

04-parent-ds.txt

Verbatim kdig output for the zone's parent delegation and DNSSEC state, queried through a validating resolver: NS delegation at the parent, the DS record at the parent, and the DNSSEC validation result. The AD (Authenticated Data) flag on a successful response confirms the resolver DNSSEC-validated the data; SERVFAIL may indicate a validation failure and requires investigation. For a signed zone, the DS key tag here should correspond to the active KSK described in latest/ksk-attestation.json.

latest/ksk-attestation.json

A valid signature demonstrates the signing key corresponding to the published public key was available to CNX's protected key-management system at report time. hsm_attested: false with an accompanying error field means the attestation didn't complete and requires investigation. See Verifying report integrity for how to check the signature yourself.

latest/ds-to-publish.txt

DS records derived from the current KSK, formatted for publication at the registrar. Two digest types are provided (type 2 = SHA-256, type 4 = SHA-384) — see Publishing and updating DS records. The key tag should correspond to ksk_key_tag above and the DNSKEY observed in 03-serving-state.txt.

latest/key-status.json

The administrative KSK status recorded by the CNX platform, used alongside ksk-attestation.json.

latest/zone-status.json

Current zone deployment status, SOA serial, and the git SHA of the last deployed configuration. A zone should normally report status: current; any other state should be reviewed with CNX support.

Retention and integrity

CNX retains reports according to the retention period defined in your service agreement. Daily reports are committed under CNX's reporting identity, and the timestamped SHA-256 manifest (see Verifying report integrity) provides independent integrity evidence for the retention copy your team mirrors.