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

[Alex Bligh <[e-mail]>]

Niall,

--On 13 September 2010 14:26:05 +0100 Niall O'Reilly <[e-mail]> 
wrote:

> On 09/09/10 17:30, Alex Bligh wrote:
>> 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.
>
> 	Alex,
>
> 	Are you assuming either
> 	(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.

> 	(b) that the multiplicity (cardinality?) of a "sameness
> 	    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