ICANN87 · Bali · Commercial Stakeholders Group (CSG) · GNSO · October 2026

Verifiable incremental zone data through CZDS

A proposal for an optional, access-controlled, verifiable daily delta for every TLD zone file a user is already authorized to receive.

Leo Angelo · Hafiz Farooq

zonedata.org

Draft for discussion · Version 1.0 · September 2026

1 · Summary

The proposal in one sentence

CZDS should offer an optional, access-controlled, verifiable daily delta for every TLD zone file a user is already authorized to receive.

Additions
Deletions
Delegation / RRset changes
Same access rights; less duplicated work

2 · The current inefficiency

Same source data. Same calculation. Repeated by every consumer.

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

Every participant builds the same miniature data-engineering platform: bulk transfer, parsing, normalization, storage, comparison.

Consumers also disagree on the result. Different parsing, ordering, TTL, RRset and nameserver-change logic produce hundreds of private interpretations of one change.

3 · Who benefits, and how

The same change record, working for each of you

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.

4 · The proposed service

A supplement to full zone files, not a replacement

Daily full snapshot remains available

Baseline / recovery / independent verification

CZDS delta service

ADD: domain or RRset appears
DELETE: domain or RRset disappears
UPDATE: delegation / RRset changes

Additive, not disruptive. The full file stays the baseline for new users, recovery, audit and rebuilds. The delta is an opt-in companion output.

Deltas only for TLDs the user is already authorized to receive.

Phase 1: generated centrally by CZDS from consecutive daily snapshots. One signed, sequence-numbered artifact per TLD per day.

Whatever the format, it must be verifiable and replayable; a proposed technical profile is published as a starting point at zonedata.org/appendix.

5 · Scope

No registrant data. No new access rights.

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.

6 · Commercial services benefits

CZDS stays infrastructure; the market moves up the stack

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, web signals
Risk, abuse, brand-protection, and market analytics
APIs, alerts, workflow integration, SLAs, and support

A basic daily list of added, deleted or changed zone entries is a low-level infrastructure output.

The market opportunity shifts upward: validation, accuracy monitoring, semantic normalization, vertical solutions, premium distribution.

7 · Proof of concept

It already works: verifiable events from the live .net zone

In the full .net zone file (generated 2026-09-21)

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

In the delta: what a consumer receives, one event per change

Domain added zone-delta.net 2026-09-21
- Nameservers: launch1.spaceship.net, launch2.spaceship.net
- Delegation signer (DNSSEC): key 27062, algorithm 13, digest 106E…5F0F
Domain changed zone-delta.net 2026-09-22
- Nameservers: launch1, launch2 (spaceship.net) replaced by noah, sue (ns.cloudflare.com)
- Other changes reported the same way: delegation signer added, removed or rotated; time-to-live changed
Domain removed none in this sample
- The name leaves the zone; the event carries the last nameservers and signer seen

8 · Food for thought

Voluntary ccTLD adoption

The same technical profile can serve any zone whose manager chooses to publish a delta through it.

Not part of today's request; gTLDs under existing CZDS access controls are the whole ask
Voluntary adoption by ccTLD managers, with national-authority agreement, if and when they see the benefit
One common change format across zones is the ecosystem gain; no policy change is proposed

Questions?

Requested today: support from the CSG constituencies - BC, IPC, ISPCP - for a letter to ICANN org asking for a scoped feasibility assessment leading to a limited pilot: an initial set of gTLD zones, existing approved users, full files retained, published metrics.

No policy change. No new access rights. No registrant data.

Compute the change once. Distribute it securely to the parties already entitled to it.

Proposal, technical appendix, FAQ: zonedata.org · a non-commercial resource

Backup

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 and hashes
ADD / DELETE / UPDATE semantics; correction and supersession rules
Replay window and full-file fallback for safe recovery

Full requirements profile, event schema and canonicalization questions: technical appendix at zonedata.org/appendix