| Status | Draft for discussion — ICANN87, Bali, October 2026 |
| Version | 1.0 — September 2026 |
| Authors | Leo Angelo · Hafiz Farooq |
| Formats | Written proposal · Slides · PDF |
Verifiable incremental zone data through CZDS
1. Summary §
CZDS should offer an optional, access-controlled, verifiable daily delta for every TLD zone file a user is already authorized to receive: additions, deletions, and delegation or RRset changes, under the same access rights, with less duplicated work.
The proposal does not seek a new entitlement to data. It seeks a better delivery format for data that authorized users can already receive and independently compare. Today, each approved consumer downloads a full zone file, retains or processes an earlier copy, and independently performs essentially the same comparison. CZDS is already the centralized access mechanism; it is the natural place to centrally package a deterministic, standardized change set.
The desired outcome is better efficiency, common semantics, lower barriers for legitimate users, and stronger operational integrity. Put simply: if a party is already authorized to retrieve a TLD's daily zone file, CZDS should also offer that party a verifiable daily delta, what was added, removed, or changed, rather than requiring every authorized user to download and diff two full snapshots.
2. The proposed service §
- Baseline / recovery / independent verification
- ADD: domain or RRset appears
- DELETE: domain or RRset disappears
- UPDATE: delegation / RRset changes
Principle: supplement full zone files; do not replace them.
The service is additive, not disruptive. The daily full zone file remains the baseline for new users, recovery after missed updates, independent audit, and data rebuilds. The delta is an opt-in companion output, and an approved user can obtain deltas only for TLDs for which that user retains active zone-file authorization.
In a first phase the delta can be generated centrally by CZDS from the consecutive daily snapshots already available through the existing architecture, with minimal new registry work. The sensible default is one signed, sequence-numbered delta artifact per TLD per daily publication cycle, with every entry explicitly tagged by change type: a complete, replayable transition rather than a collection of loosely related files. A later phase can, if desired, permit registries to publish or attest to authoritative deltas under a common technical profile.
This is not a proposal to replace zone-file access. It is a companion synchronization product: retain the full snapshot as the authoritative baseline, and make the incremental change set available to authorized users who do not need to repeatedly reconstruct it.
3. The current inefficiency, what fixing it delivers, and who benefits §
- Registry daily snapshot
- CZDS distribution
- Many authorized users each download full snapshot N
- Each user stores, parses, normalizes and diffs snapshot N against N-1
- Each user independently derives the same daily changes
Same source data. Same calculation. Repeated by every consumer.
The issue is not whether zone access should exist; it already does. The issue is repetitive work at ecosystem scale. For each TLD, all downstream recipients repeat bulk transfer, parsing, normalization, storage, and comparison to derive broadly the same change set, and the cost grows with larger zones and with the number of legitimate consumers. The present model effectively requires every participant to build the same miniature data-engineering platform. That is not a source of meaningful market differentiation; it is duplicated network transfer and duplicated computation.
The current approach also produces inconsistent results. Consumers implement different parsing, ordering, TTL, RRset, and nameserver-change logic. A delegation change can appear as several individual NS record additions and removals; a common interpretation is better than hundreds of private interpretations.
| Fixing it delivers | Practical result |
|---|---|
| Less duplicated bulk transfer | Lower bandwidth, storage I/O, and processing cost |
| Common change semantics | Consistent interpretation across users |
| Better integrity and auditability | Replay, verification, reproducibility |
| Lower barrier to legitimate use | Researchers and smaller security teams can participate |
| Retained full files | No loss of baseline, rebuild, or audit capability |
Who benefits, and how. The same change record works for each constituency of the Commercial Stakeholders Group (CSG):
| CSG constituency | Benefit |
|---|---|
| Business users (BC) | New and changed domains visible to security and brand teams at publication time, with no bulk-download infrastructure to build; smaller teams participate on equal footing. |
| Brand owners (IPC) | A watched or confusingly similar name appears as an explicit, timestamped, signed event; delta records provide verifiable evidence of when a domain appeared or changed. |
| ISPs and connectivity providers (ISPCP) | Delegation and DNSSEC changes as early operational and abuse signals, consumable directly by resolver and abuse pipelines. |
Same data, same cadence, same approved recipients; delivered sooner, interpreted identically, verifiable by anyone.
The benefit is ecosystem-wide rather than a convenience for commercial consumers: security teams can focus resources on detection rather than bulk ingestion, researchers can reproduce work against a common published change record, and registries gain consistent downstream interpretation of technical changes. It also means fewer redundant large transfers and bulk parses across the ecosystem. The benefit is not that one user downloads fewer bytes; it is that an ecosystem stops recreating the same mechanical transformation thousands of times and competes instead on the value created from the data.
4. Requirements for a reliable delta §
A synchronization protocol, not a text file called "diff."
- Canonical record/RRset representation, with explicit delegation-change classification
- Baseline ID, sequence numbers, timestamps, signed manifest/hashes
- ADD / DELETE / UPDATE semantics; correction and supersession rules
- Replay window and full-file fallback for safe recovery
"Diff" must not mean a naive line diff of two text files. A zone file is DNS data; a robust protocol works on normalized DNS records or RRsets. For domain-intelligence use, identifying a delegation transition matters more than separately listing NS additions and removals, and a consumer must be able to verify a complete chain from one known baseline to the next. The output therefore needs deterministic semantics, sequence continuity, integrity verification, recovery, and an authoritative full-snapshot fallback. The technical appendix specifies a minimum profile, the event schema, and the canonicalization questions a requirements assessment would resolve.
5. No privacy concerns: what is not published §
| In scope: derived from the existing published zone | Not in scope |
|---|---|
| Domain names already present in the zone | Registrant name |
| DNS RRsets, principally delegation-related records | Registrant email address |
| NS, DS, glue, and relevant record changes | Registrant telephone number |
| Add / delete / update events | Registrant postal address |
| Timestamps, sequences, hashes, correction metadata | WHOIS or RDAP registration data |
| Existing approved-recipient access controls | Lead lists, identity enrichment, or contact data |
This is not a WHOIS or RDAP proposal. It does not expand access rights.
The proposal is limited to DNS records already present in the published zone file. The delta has no registrant name, email, telephone, postal address, account information, or identity-enrichment layer; it contains only a standardized change record derived from the DNS information already in the authorized zone file. An approved recipient can already derive the same daily list from two approved full snapshots. The daily delta changes the computation and delivery method, not the entitlement or the daily observation time.
If there is a concern about unwanted solicitation based on newly visible domain names, that is a policy question about the existing zone-file regime and permitted use. It is not evidence that this proposal discloses registrant contact data.
6. Benefits for businesses §
The proposal commoditizes duplicate diffing, not commercial intelligence. A basic daily list of added, deleted, or changed zone entries is a low-level infrastructure output, distinct from a domain-intelligence product offering cross-source coverage, history, enrichment, scoring, classification, real-time delivery, dashboards, and support. Commercial differentiation remains in:
- Multi-TLD and ccTLD coverage
- Near-real-time delivery and resilience
- Long-term history and replay
- Data quality assurance and reconciliation
- Passive DNS, RDAP/WHOIS where permitted, certificates, IP/ASN, hosting, and web signals
- Risk, abuse, brand-protection, and market analytics
- APIs, alerts, workflow integration, SLAs, and support
The market opportunity shifts upward: validation, accuracy monitoring, semantic normalization, vertical solutions, and premium distribution become more important. CZDS should not become an enrichment or analytics vendor. A standardized daily delta should not be confused with passive DNS, threat intelligence, historical analytics, registration-data enrichment, or a commercial API platform; those remain differentiated markets. The proposal simply removes a duplicated, low-value extraction step for parties already authorized to obtain the raw data.
7. Proof of concept, and the requested next step §
7.1 Proof of concept completed §
A working delta generator implementing the profile in the technical appendix was run against consecutive daily CZDS deliveries of the .net zone, about 32 million records. One test name registered by the proposal authors, zone-delta.net, was changed on purpose on consecutive days: delegated at registration, re-delegated to different nameservers, and DNSSEC-enabled with a DS record. The generator reports each change as one event of the expected type, with every RRSIG excluded as signing noise, and each manifest carries the serials and hashes of both snapshots so that any recipient of the same two files can verify the result.
The full-file lines, the events and the manifest headers are the worked example in the technical appendix.
7.2 Phase 1: limited daily-delta pilot §
- An initial set of gTLD zones
- Existing approved zone-file users only
- Daily full snapshots retained
- Deterministic format, sequence chain, hash/signature, replay endpoint
- Published test vectors, validation guidance, and transparent metrics
Pilot metrics should be defined in advance: bytes avoided per participating consumer; processing time avoided; completeness and hash-verification rate; delta publication latency after the daily snapshot; missed-sequence and recovery behavior; registry and CZDS operational cost; user adoption and implementation feedback.
7.3 Requested outcome and vehicle §
The CSG constituencies - BC, IPC and ISPCP - are asked to support a documented request to ICANN org:
- Support from the CSG constituencies (BC, IPC, ISPCP) and other GNSO participants for the approach.
- Vehicle: a CSG-supported letter to ICANN org (GDS / CZDS Operations), copied to the GNSO Council, requesting a scoped feasibility and requirements assessment.
- Deliverable: a written disposition: pilot, roadmap commitment, deferral with rationale, or rejection with rationale.
The request is deliberately narrow, so that supporters can say yes and so that "yes" has a defined meaning: a measured next step with full files retained, the same approved users, deterministic deltas, published metrics, and a written decision path for whether and how to scale. Any of the four dispositions is acceptable as long as it is documented and reasoned.
8. Food for thought: sub-daily visibility §
Register / delegate → abuse use → remove
Domain absent from both daily snapshots
→ invisible to daily snapshot and daily-delta analysis
Daily deltas reduce duplicated computation. They do not reveal activity between daily snapshots.
A domain that is registered, delegated, used, and removed entirely between the two daily observation times appears in neither daily snapshot nor the corresponding delta. A domain present at one snapshot and removed before the next does appear, as a deletion. The phenomenon has meaningful DNS-abuse and research relevance, and the solution space, sub-daily or rapid zone updates, requires a separate policy and technical discussion because it changes the publication cadence and may require registry agreement changes or voluntary mechanisms.
This is related but separate. Daily deltas remove duplicated work today; access-controlled visibility between snapshots is a natural later enhancement, on its own carefully scoped policy and technical track.
9. Scope beyond gTLDs §
- Now: gTLD daily-delta pilot under existing access controls
- Next: study access-controlled sub-daily visibility
- Optional extension: voluntary adoption by ccTLD managers with national-authority agreement
Scope principle: mandatory discussion for ICANN-contracted gTLDs; a voluntary, sovereign-choice adoption path for ccTLDs. ccTLD managers are not generally subject to the same ICANN contractual framework as legacy and new gTLD registries; the aim is technical interoperability and voluntary participation, without implying any authority to mandate it.
The immediate request is deliberately narrow: support for a BC letter seeking a gTLD daily-delta pilot, under unchanged access controls and with full snapshots retained. Compute the change once; distribute it securely to the parties already entitled to receive the underlying zone data.