Questions and answers

No. The core design principle is access-control parity. A user receives a delta only for a TLD zone file for which that user already has active authorization. The delta is a standardized representation of changes that the same user could derive today by comparing consecutive authorized daily full snapshots. The proposal changes delivery and duplicated processing, not eligibility or entitlement.

No registrant identity or contact fields are in scope. The delta is limited to DNS records already present in the published zone file and metadata needed to verify synchronization: for example, domain names, RRset or delegation changes, timestamps, sequence information, and integrity hashes. It contains no registrant name, email address, telephone number, postal address, account data, or RDAP/WHOIS record.

An approved zone-file recipient can already identify daily additions or changes by comparing two authorized full files. If the community has concerns about solicitation based on newly visible domain names, that should be addressed as an evidence-based permitted-use and enforcement issue under the existing zone-file regime, not by preserving unnecessary duplicate downloading and computation.

Commercial providers should and will continue to add value. A canonical daily delta is not a replacement for multi-source coverage, passive DNS, historical data, entity resolution, registration-data enrichment where permitted, threat detection, abuse scoring, alerts, dashboards, APIs, SLAs, or professional support.

The proposal only centralizes a mechanical transformation of data CZDS already distributes to authorized users. It lets commercial competition move toward quality, speed, coverage, analytics, workflow integration, and trust rather than forcing every consumer to repeatedly perform the identical baseline diff.

No. The requested service is deliberately narrow: a deterministic, canonical, verifiable synchronization artifact derived from the existing zone-file snapshots. CZDS should not score domains, provide marketing lists, enrich records with registration information, classify abuse, infer ownership, or compete with commercial domain-intelligence products.

They remain necessary for new consumers to establish a baseline, recovery after a missed delta or local data loss, independent verification, forensic reconstruction, and users whose workloads require a full snapshot. The proposal supplements full files; it does not replace them.

The protocol should include a baseline ID, monotonic sequence numbers, previous/current state references, hashes, a defined replay-retention window, and a full-file fallback. A consumer should either replay every missing verified delta in sequence or retrieve a new full baseline and resume from it. This is why a genuine synchronization design is preferable to an unstructured diff file.

Compression helps transfer size but does not eliminate repeated parsing, normalization, storage, comparison, and inconsistent interpretation. A properly structured delta reduces both transfer and duplicated computation, while adding common semantics, sequence continuity, replay, and verification.

For an initial pilot, CZDS can deterministically generate the delta from the daily snapshots it already distributes, minimizing new registry work. The protocol should retain a path for registries to publish or attest to their own authoritative deltas in a later phase if the community finds that useful. The initial decision is therefore not an all-or-nothing choice between central and registry generation.

Any data service can have errors, which is why the design includes canonicalization rules, signed or hashed manifests, source snapshot IDs, sequence continuity, correction/supersession rules, public test vectors, and continued access to the full snapshot. Consumers can independently verify that applying a published delta to a referenced baseline produces the next published state.

Correct, and the protocol embraces that. At the record level, DNS knows only appearance and disappearance; "update" is derived semantics the delta service defines deterministically. The proposed taxonomy operates on RRsets, the unit DNS itself validates and DNSSEC signs:

• RRset created: the first record of a given owner name and type appears. For an NS RRset, this is a new delegation.
• RRset deleted: the last record of the set disappears. For NS, a removed delegation.
• RRset membership changed: the set persists but its contents differ, including full swaps such as a provider migration, which should surface as one event rather than several unrelated adds and removes.
• RRset TTL changed: membership identical, TTL differs. Emitted as a distinct low-noise event type so consumers can trivially ignore or observe it.

Two canonicalization rules keep the delta meaningful: DNSSEC signature and denial-of-existence records (RRSIG, NSEC/NSEC3) are excluded by default, since they churn on every re-signing without any underlying zone change and would dominate delta volume in signed zones; DS changes remain in scope, because they reflect real registrant-driven key events. Delegation-level events (domain added, removed, delegation changed) are defined as views over the NS, DS, and glue RRsets.

The event schema in the appendix reflects this taxonomy.

That is exactly what a limited pilot should measure. The proposal should request a scoped operational assessment with transparent estimates for storage, compute, distribution, support, monitoring, and security. Costs can then be compared with ecosystem-wide duplicated bandwidth and processing that the present design imposes on every consumer. A decision on scale should follow measured results, not assumptions.

No. Daily deltas solve the duplication problem for daily snapshots. They cannot identify a domain that is registered, delegated, used, and removed entirely between two daily snapshot times. That is a separate visibility issue. It warrants a distinct technical and policy discussion of access-controlled sub-daily or rapid zone updates, with careful attention to registry burden, access eligibility, retention, auditing, and misuse safeguards.

The daily-delta proposal is intentionally narrower and can be evaluated under the existing daily-access model. Moving to sub-daily publication changes the timing, operational, contractual, and policy implications. It should be studied separately, potentially starting with voluntary pilots and evidence-driven requirements rather than being bundled into the initial daily-delta request.

No. ccTLDs operate under their own national or local policy and governance arrangements and are not generally subject to the same ICANN registry-contract framework as legacy and new gTLDs. The right approach is to make a proven standard and compatible implementation available for voluntary adoption by ccTLD managers with the agreement of the relevant national authority.

For .ai, the Government of Anguilla is the IANA-designated ccTLD manager, while Identity Digital provides registry services. Any decision on zone-file or delta publication would properly require Anguilla's agreement and follow its applicable policy framework.

The initial daily proposal does not make the underlying daily zone data available to new recipients or at a faster observation cadence. It makes an existing authorized daily comparison more efficient and auditable for the same approved recipients. The design should maintain authorization parity, authentication, logging, rate controls, retention rules, contractual restrictions, and revocation tied to the associated zone-file agreement.

For sub-daily publication, the timing question is different and deserves separate safeguards and policy analysis.

Support from the CSG constituencies (BC, IPC, ISPCP) for a letter to ICANN org and CZDS Operations, copied to the GNSO Council, requesting a scoped feasibility and requirements assessment leading to a limited daily-delta pilot. The pilot should preserve daily full snapshots, restrict delta access to the same approved recipients, define verifiable technical semantics, publish metrics, and produce a clear written roadmap or disposition after evaluation.

Not necessarily, and today a recipient cannot tell without diffing. While preparing the worked example in the technical appendix, consecutive daily CZDS downloads of one TLD on 17 and 18 September 2026 returned the same generation as the 13 September file (SOA serial 1789261812), although the live zone had changed on the 13th; the delivery on 20 September was current. Where in the chain the delay arose is not visible to the recipient, and no conclusion about any party is drawn from a single observation.

A sequenced delta with a publication timestamp and snapshot hashes makes such gaps observable rather than silent: either the sequence does not advance, or it advances with an empty event list, and the recipient knows which. This is one reason the proposed pilot publishes its metrics, including publication latency, from the start.