Subject: [dnsext] Name equivalence: Another no protocol change solution

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Sep 2010 17:30:49 +0100

The problem to me seems to be divided into (at least) two:

1. Apparent pseudo-regulatory requirement to ensure TLDs operate with
   recursive sameness. This is making TLD1 == TLD2.

2. Requirement within a TLD for some sort of equivalence (possibly not
   recursive) but notably not driven by a third party's perceived
   requirements. This is making foo.TLD == bar.TLD.

Problem 1 can, it seems to me, be solved by DNAME. DNAME only doesn't
do the job when there is a record at the apex, because DNAME+CNAME
can't coexist. Few if any TLDs have records at their apexes.

Problem 2 cannot in general be solved by DNAME (DNAME+CNAME problem),
as foo.tld may well exist. This can, however, in general be solved
by provisioning algorithms.

It is not particularly neat solving what looks like one problem with
two solutions, but closer inspection suggests the problems are
in fact different.

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 13 Sep 2010 14:26:05 +0100

> by provisioning algorithms.

	Alex,

	Are you assuming either
	(a) that cascaded sameness requirements won't arise. or
	(b) that the multiplicity (cardinality?) of a "sameness
	    bundle" will always be small?

	ATB
	Niall O'Reilly

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Sep 2010 14:57:22 +0100

Niall,

> 	(a) that cascaded sameness requirements won't arise. or

If by cascaded sameness you mean what I defined as recursive
sameness, I am assuming it only arises for TLD sameness, or
more accurately for problem statement 1. This is handled by
DNAME as far as I can tell. No one has (I think) given a
requirement for recursive sameness for problem statement 2,
and indeed it is often a disadvantage.

> 	    bundle" will always be small?

Well, there is more than one type of multiplicity.

If we are talking about label multiplicity, i.e.
     a1.b1.c1.d1
and
     an.bn.cn.dn
are equivalent for all values of n, thus creating an O(n^k)
problem, then DNAME solves this to the extent it is used.
As for (2) my current view is that at the application layer
you already have an O(n^k) problem, so we are not, at least,
making things much worse than at the application layer.
I suppose yes, I am assuming that in scenario 2, the range
of n is small.

If we are talking about problem types similar to what
I understand the Greek tonos problem to be, we have
a high "cardinality" within the label, so using case
of letter to indicate sameness we need
      abcabcabc
      ABCABCABC
      abcABCabc
      AbCaBcAbC (etc.)
all to be the same. No solution I've yet seen apart from
synthesis based solutions (which could be added to 2) fix
this as DNS's smallest unit of lookup is the label rather than
the constituent parts thereof. So what I propose is no
worse than any of the non-synthesis based protocol solutions,
and anyone wanting to add synthesis (plus online signing) can
do so orthogonally to what I propose.

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 13 Sep 2010 15:47:59 +0100

> problem, then DNAME solves this to the extent it is used.

	Unless a subsidiary zone apex (for example, 'c' above
	might be delegated from 'b') needs data other than
	a DNAME.

> all to be the same.

	This might be seen as a pathological case of
	label multiplicity, where k=1 and n=2^p.  Examples
	with p as great as 5 seem not to be exceptional.

> No solution I've yet seen apart from
> this

	Thanks for making that explicit.

> as DNS's smallest unit of lookup is the label rather than

	Fair enough!

	Niall O'Reilly

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Sep 2010 16:05:31 +0100

> 	might be delegated from 'b') needs data other than

I must be missing something. How can c be delegated from b?

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 13 Sep 2010 17:03:49 +0100

On 13/09/10 16:05, Alex Bligh wrote:
> --On 13 September 2010 15:47:59 +0100 Niall O'Reilly
> <[email-masked]> wrote:
>

	D'oh!
	You're not.  I'm sorry.  I meant b from c.

	/Niall

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Sep 2010 17:20:11 +0100

> 	You're not.  I'm sorry.  I meant b from c.

OK, that is less confusing!

So you mean:

$ORIGIN c1.d1.
	b2	IN DNAME b1.c1.d1.
	b1	IN NS ns.example.com.

or do you mean glue records with the DNAMEd zone:	
	b2	IN DNAME b1.c1.d1.
	b1	IN NS ns.b2.c1.d1.
	ns.b2.c1.d1.	IN	A	192.0.2.2

If the latter, the answer is, I think "don't do that!".

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 13 Sep 2010 17:36:31 +0100

>      b1    IN NS ns.example.com.

	That's what I had in mind, with a bunch of MX, SRV, and
	whatever else belonging to b1.c1.d1. as well, and needing
	to be projected (mirrored, shadowed, ...) onto b2.c1.d1.

> If the latter, the answer is, I think "don't do that!".

	Indeed. 8-)

	/Niall

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Sep 2010 17:49:56 +0100

> 	to be projected (mirrored, shadowed, ...) onto b2.c1.d1.

Right, and the coexistence of those other records is the problem, yes?
> recursive sameness. This is making TLD1 == TLD2.
...
> can't coexist. Few if any TLDs have records at their apexes.

By assumption (last sentence) there are no records that need to
be at b2.

IE I am assuming problem 1 (need for recursive sameness beyond
that which provisioning could give us) only applies in circumstances
where coexisting records do not exist. So far the only use
people who have said "provisioning doesn't work for this" are
TLDs.

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 13 Sep 2010 20:15:57 +0100

Alex,

> By assumption (last sentence) there are no records that need to

	I don't see how that "last sentence" applies to a delegated
	zone apex or to its mirror images under "sameness".

> people who have said "provisioning doesn't work for this" are

	I think you may be missing what they mean when they make that
	statement.  I don't believe it's the provisioning of a handful
	of equivalent TLD zones that gives them cause to say this.
	That can't be beyond the intellectual and material resources
	of a TLD registry.

	Their trouble with provisioning, as I understand it, lies not
	between them and the root, or within their own bundle of
	equivalent TLD zones, but between them and their registrants,
	to whom they want to be able to offer a group of domains which
	are dependably coupled, and remain so without extraordinary
	requirements for expertise and effort on the part of the
	registrants or their agents (registrars, DNS hosting providers).

	What the TLD registries appear to need is a means to tie a
	whole bundle together so that it can be managed by or for the
	registrant with no more trouble than if a single, traditionally
	delegated zone were involved.  Parallel delegation is easy for
	the TLD registry, but burdensome for the registrant.  Pseudo-
	delegation using DNAME in the TLD zone in parallel with a zone
	cut deprives the registrant of the means to populate all but one
	of the supposedly equivalent apices (apexes?).  Provisioning
	offers only these two approaches today, and so doesn't support a
	credible service for TLD registries to offer to their particular
	communities.

	Of course I'm projecting my notion of somebody else's problem.
	It would be helpful if one or other of those somebodies would
	confirm what they mean by "provisioning doesn't work for this".
	I'll be quite content to learn that I'm wrong, should that be
	how it turns out, because we'll have gained some clarity.

	Niall O'Reilly

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Sep 2010 20:37:02 +0100

> 	credible service for TLD registries to offer to their particular

That's what I thought the problem was the first time, but it surely can't
be that, because TLD operators of any size generate their zonefiles through
a database extraction anyway, and I can't believe doing that would make
extraction any harder.

What was being suggested was that the requirement could not be addressed
by provisioning (and, to achieve recursive sameness, by registrant/registry
contract) because a third party (here ICANN) wanted to ensure that sameness
was enforced upon the registry by a mechanism stronger than any agreement
ICANN might have with that registry.

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 13 Sep 2010 20:51:49 +0100

> a database extraction anyway, and I can't believe doing that would make

	I don't think their problem is with their own TLD zone(s),
	for just the reasons you suggest.
	Until one or two of the TLDers involved speak up,
	we may as well keep our breath to cool our porridge ...

	ATB

	/Niall