| Status | Draft for discussion — ICANN87, Bali, October 2026 |
| Version | 1.0 — September 2026 |
| Authors | Leo Angelo · Hafiz Farooq |
Technical appendix: proposed minimum daily-delta profile
The minimum profile a CZDS daily delta should satisfy: functional requirements, an event schema, the canonicalization questions to resolve, and integrity and operational requirements.
A1. Functional requirements §
- One daily delta per TLD per published daily snapshot transition.
- Available only after the relevant daily snapshot is finalized.
- Available only to users with active authorization for the relevant TLD zone file.
- Full daily snapshot remains downloadable under current access terms.
- Explicitly support baseline creation, delta replay, correction, and recovery.
A2. Suggested event schema §
{
"tld": "example",
"schema_version": "1.1",
"baseline_id": "2026-10-16T00:00:00Z",
"previous_sequence": 4821,
"sequence": 4822,
"source_snapshot_timestamp": "2026-10-17T00:00:00Z",
"publication_timestamp": "2026-10-17T00:12:10Z",
"previous_snapshot_hash": "...",
"resulting_snapshot_hash": "...",
"canonicalization_profile": "czds-delta-1: RRSIG/NSEC/NSEC3 excluded; TTL changes emitted as RRSET_TTL_CHANGED; owner names lowercased",
"events": [
{
"event_type": "DOMAIN_ADDED",
"owner_name": "example.example.",
"rrsets": {
"NS": { "ttl": 3600, "rdata": ["ns1.provider.example.", "ns2.provider.example."] },
"DS": { "ttl": 3600, "rdata": ["12345 13 2 ..."] }
}
},
{
"event_type": "DOMAIN_REMOVED",
"owner_name": "former.example."
},
{
"event_type": "RRSET_MEMBERS_CHANGED",
"owner_name": "another.example.",
"rrset_type": "NS",
"added": ["ns1.newprovider.example."],
"removed": ["ns-old.provider.example."],
"resulting_rdata": ["ns1.newprovider.example.", "ns2.provider.example."]
},
{
"event_type": "RRSET_CREATED",
"owner_name": "signed.example.",
"rrset_type": "DS",
"ttl": 3600,
"rdata": ["54321 13 2 ..."]
},
{
"event_type": "RRSET_DELETED",
"owner_name": "unsigned-again.example.",
"rrset_type": "DS"
},
{
"event_type": "RRSET_TTL_CHANGED",
"owner_name": "tuned.example.",
"rrset_type": "NS",
"previous_ttl": 86400,
"ttl": 3600
}
],
"manifest_signature": "..."
}
Note: DOMAIN_ADDED carries the initial RRset data (delegation targets and DS material), not merely the record types present. The delegation state at creation is the most-consumed field for security and research use; omitting it would force consumers back to the full snapshot for every addition and defeat much of the delta's value.
Design notes on the 1.1 schema:
DOMAIN_ADDEDandDOMAIN_REMOVEDstay as delegation-level convenience events, answering the most common consumer need without RRset assembly, while all other transitions use the four genericRRSET_*types. This replaces the earlierDELEGATION_CHANGEDwithRRSET_MEMBERS_CHANGEDon the NS set, which is more general: the same event type covers NS changes, glue changes, and any future in-scope RRset without inventing per-type events.resulting_rdataon membership changes lets a consumer verify converged state per event without replaying from baseline; cheap to include, high verification value, and consistent with the integrity requirements in A4.canonicalization_profileas an explicit, versioned field means the noise-exclusion rules are declared in-band rather than assumed, and can evolve without breaking consumers.
The exact format can be JSON, line-delimited JSON, a DNS-oriented binary representation, or another efficient standardized encoding. The policy goal is not a specific serialization format; it is deterministic semantics, verifiability, and interoperability.
Worked example from a live zone §
The schema above applied to consecutive daily CZDS deliveries of the .net zone, about 32.16 million in-scope records per snapshot. Snapshots are dated by their generation time (the SOA serial), not by download day: each daily delivery carries the generation from 00:00 UTC of the previous day. One test name, zone-delta.net, was registered by the proposal authors on 20 September 2026 at 19:19 UTC and re-delegated to different nameservers on 21 September at 12:00 UTC. A reference generator implementing the czds-delta-1 profile was run on each pair of consecutive snapshots; a full .net pair takes about four minutes.
The lines of the full file for the test name, by snapshot generation:
generated 2026-09-20 00:00 UTC (registered later that day: not present)
generated 2026-09-21 00:00 UTC
zone-delta.net. 172800 in ns launch1.spaceship.net.
zone-delta.net. 172800 in ns launch2.spaceship.net.
zone-delta.net. 86400 in ds 27062 13 2 106E2DDFCB22B19B4D8038706B8B12D2B968396B476BE642B2C3417E99455F0F
generated 2026-09-22 00:00 UTC
zone-delta.net. 172800 in ns noah.ns.cloudflare.com.
zone-delta.net. 172800 in ns sue.ns.cloudflare.com.
The events for the test name in each pair, verbatim from the generator, with each pair's manifest header:
{
"tld": "net", "schema_version": "1.1",
"baseline_id": "2026-09-20T00:00:18Z", "previous_sequence": 1, "sequence": 2,
"source_snapshot_timestamp": "2026-09-21T00:00:19Z",
"previous_snapshot_serial": "1789862418", "resulting_snapshot_serial": "1789948819",
"previous_snapshot_records": 32156839, "resulting_snapshot_records": 32156414,
"previous_snapshot_hash": "sha256:15a4e2c9df62c19383ad6dac487d099259da3bef275d03b6623eabbc1bb19e5c",
"resulting_snapshot_hash": "sha256:a7076764065fb4a79c2e605ecc1b6766af7bd8453d2231187a9592c89a786b3c",
"events": [ ... 23,704 events: 6,417 DOMAIN_ADDED, 6,801 DOMAIN_REMOVED, 271 RRSET_CREATED, 306 RRSET_DELETED, 9,909 RRSET_MEMBERS_CHANGED ...
{
"event_type": "DOMAIN_ADDED",
"owner_name": "zone-delta.net.",
"rrsets": {
"DS": { "ttl": 86400, "rdata": ["27062 13 2 106E2DDFCB22B19B4D8038706B8B12D2B968396B476BE642B2C3417E99455F0F"] },
"NS": { "ttl": 172800, "rdata": ["launch1.spaceship.net.", "launch2.spaceship.net."] }
}
}
]
}
{
"tld": "net", "schema_version": "1.1",
"baseline_id": "2026-09-21T00:00:19Z", "previous_sequence": 2, "sequence": 3,
"source_snapshot_timestamp": "2026-09-22T00:00:19Z",
"previous_snapshot_serial": "1789948819", "resulting_snapshot_serial": "1790035219",
"previous_snapshot_records": 32156414, "resulting_snapshot_records": 32164437,
"previous_snapshot_hash": "sha256:a7076764065fb4a79c2e605ecc1b6766af7bd8453d2231187a9592c89a786b3c",
"resulting_snapshot_hash": "sha256:399dcf5e836609909d79eb84a9f0bca4b2c21ecf894f887ffcaecefa9506746b",
"events": [ ... 30,091 events: 10,387 DOMAIN_ADDED, 6,844 DOMAIN_REMOVED, 432 RRSET_CREATED, 673 RRSET_DELETED, 11,755 RRSET_MEMBERS_CHANGED ...
{ "event_type": "RRSET_DELETED", "owner_name": "zone-delta.net.", "rrset_type": "DS" },
{
"event_type": "RRSET_MEMBERS_CHANGED",
"owner_name": "zone-delta.net.",
"rrset_type": "NS",
"added": ["noah.ns.cloudflare.com.", "sue.ns.cloudflare.com."],
"removed": ["launch1.spaceship.net.", "launch2.spaceship.net."],
"resulting_rdata": ["noah.ns.cloudflare.com.", "sue.ns.cloudflare.com."]
}
]
}
Three observations. The registrar's default nameservers came with a DS record of their own, so the addition carries both RRsets and the re-delegation is reported as two events: the NS membership change and the deletion of the old DS. The resulting hash of the first pair is the previous hash of the second, which is the chain a consumer replays. And each daily .net delta is 24,000 to 30,000 events against 32 million records, a ratio that is the case for a delta in one number. A further event, RRSET_CREATED for a new DS record, will be appended once the test name is signed at its new nameservers.
The complete artifacts, every event with the manifest: pair 2026-09-20 to 21 (JSON) and pair 2026-09-21 to 22 (JSON).
A3. Canonicalization questions to resolve §
- The atomic unit is the RRset, the unit DNS validates and DNSSEC signs; delegation-level events (domain added, removed, delegation changed) are views over the NS, DS, and glue RRsets. Should the profile also expose a per-record view for consumers that want one?
- A TTL change with identical membership is emitted as its own low-noise event type,
RRSET_TTL_CHANGED, so consumers can observe or ignore it. Should TTL-only events be omitted from the default artifact and offered as an opt-in? - Are SOA changes omitted, represented separately, or used only as snapshot metadata?
- How are case, sorting, whitespace, and presentation-format differences normalized?
- Which glue records are included and how are they associated with delegations?
- DS changes are in scope as registrant-driven events; RRSIG/NSEC/NSEC3 are excluded by default as signing artifacts. Should the profile offer an opt-in to include them?
- How are corrections, regenerated snapshots, and late arrivals represented?
- What constitutes a domain removal when NS records disappear but other records remain?
A4. Integrity and operational requirements §
- Signed manifest or cryptographically verifiable hash chain.
- Baseline and resulting-state hash values.
- Monotonic per-TLD sequence number.
- Explicit retention and replay policy.
- Status endpoint for current sequence, publication time, correction notices, and known incidents.
- Public test vectors and reference validation tooling.
- Versioning and deprecation policy for schema evolution.
A5. References §
- ICANN CZDS Help: describes CZDS as a portal for requesting access to participating zone files and notes daily update behavior.
- ICANN Registry Agreement / Specification 4 framework: provides the zone-file access obligations and controls for new gTLD registry operators.
- DarkDNS: Revisiting the Value of Rapid Zone Update (Sommese, Akiwate, Affinito, Müller, Jonker, Claffy): background on the short-lived-domain visibility gap and rapid updates.
- IANA .ai delegation record: confirms the Government of Anguilla as the ccTLD manager.
- Identity Digital materials: background on Identity Digital's registry-services role for .ai and other namespaces.