Subject: [dnsext] zone clones

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Dec 2009 11:24:15 +0000

if the problem statement was "how can i make these clone names work as
e-mail and web addresses" then something involving CNAME could work,
even something like CNAME+DNAME, or ENAME which would mean CNAME+DNAME.
however, if these clone names would only work as application layer
QNAMEs and not as intermediate QNAMEs (like MX targets and NS targets)
then the clone names would always be second class.

since my working problem statement is "how can i make these clone names
work everywhere a normal first class name would work" then nothing
involving CNAME will work and it's going to take some kind of delegation
and some kind of zone service.  i view the added DNSSEC load of signing
the clone names as an economics problem, solveable in silicon, and not
a concern.  however, to be truly first class names, all updates to any
clone must be reflected in the other clones.  so, some kind of on-wire
support will be needed at the zone apex, in the zone's authority servers.

i take it as a given that any cloned zone will be able to upgrade all
of its authority servers on a flag day, and that a mix of upgraded and
nonupgraded servers at a zone apex is an explicit nongoal.  i also take
it as a given that any solution requiring that all applications and/or
stub resolvers have to be upgraded before the first zone can be cloned
is off the table.  so, no CNAMEs (synthetic or otherwise), no mix of old
and new authority servers, and no changes to stubs, apps, or forwarders.

the (new, upgraded once we figure out what they're supposed to do) apex
authority servers will have to be able to look at the zone content, not
just out-of-band configuration, to learn that a zone is part of a group
of clones, and to learn the identities of the other clones.  on the 
primary master, an update to one has to be treated as an update to all.
while it would be nice if it was possible to hold the content of the
zone only once and to serve it under multiple apexes, this would require
late binding for relative names (and thus a new AXFR specification) and
would require some very careful programming if DNSSEC was in use.  so,
each clone's content will be transferred and stored independently, and
the primary master will be responsible for reflecting updates and/or
"zone reloads" at all clone apexes.

i'm contemplating something like a "clone group" or "zone clone group"
where the apex would have, in addition to the normal SOA and NS RRsets,
a new CLONE RRset (not the same as what doug barton's been proposing but
using the same RR name he's been talking about).  the authority server
would see the CLONE RRset at the zone apex and know to populate its zone
table with all clone names not just the original zone's name.  changes
to the CLONE RRset would result in changes to every authority's zone 
table.  every CLONE would have its own IXFR/AXFR.  the one primary master
would serve all clones of the zone.

so, the current state of my thinking about this would look like multiple
delegation NS RRsets, not all of which need be in the same parent zone,
and then a corresponding CLONE RRset at the zone apex, telling the primary
master to reflect all updates and reloads across not just the zone's apex
but the clone-set's apexes as well, and telling both the primary master
and all secondary servers to populate their zone tables with not just the
zone apex but all clones as well, and telling the secondary servers to do
separate IXFR/AXFR separately for the zone apex and for each clone.

atomicity of clone content would not be guaranteed.  it would be possible
for the "base zone" serial number to increment, and for the primary server
to take some period of time reflecting this change across the "clone group",
and for some secondary servers to have pulled the "base zone" deltas over
and to have pulled some of the "clone group" deltas over but not all of
them yet, and for some "clone zones" to have lower serial numbers for some
period.

there would be no new support for clone groups in the delegating zones,
since not all clones would be delegated from the same parent.  these would
look like parallel NS RRsets.  the only way to know whether a zone is a
clone would be to query for the CLONE RRset at that zone's apex and to
see whether the zone's apex is listed as a target of a CLONE RR.

i'm still clarifying my thinking, which is why i'm brain dumping here 
rather than writing an I-D (yet).

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 21 Dec 2009 12:33:21 +0000

> my working problem statement is "how can i make these clone names
> work everywhere a normal first class name would work"

	That reads as if non-apex nodes should be amenable
	to cloning, but the rest of your message seems to
	consider only entire zones.  Was that your intention?

	Best regards,

	Niall O'Reilly

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Dec 2009 16:58:39 +0000

> Date: Mon, 21 Dec 2009 12:33:21 +0000
> From: Niall O'Reilly <[email-masked]>
> 
> Paul Vixie wrote:

since i am not considering any CNAME-based solutions, then apex-vs-wholezone
has been overtaken by events.  i'm looking at this as first class names and
rrsets for the entire zone, no exceptions.

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 21 Dec 2009 18:54:41 +0000

> rrsets for the entire zone, no exceptions.

	I think this means exactly what I was hoping for, but I'm not
	sure.

	You clearly "have the bit between your teeth", so it's probably
	best I leave you in peace and look forward to your next
	brain-dump (or initial draft!).

	Best regards,
	Niall O'Reilly

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Dec 2009 09:39:52 +1100

> rather than writing an I-D (yet).

This is a impossibility except for leaf zones.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]