Subject: [dnsext] Possible equivalence solution: CLONE RR

From: Doug Barton <[email-masked]>
Date: Wed, 28 Jul 2010 02:54:42 -0700

I sent the message below back in December, and although I've tried to
prioritize finding the time to write a draft for it, I obviously
haven't. However as I said in the jabber room today, I still think that
this is not only a viable solution, it solves several of the problems
mentioned in today's session without introducing new ones.

So ... at this point I guess I'm committing to writing a draft, and
prior to my actually accomplishing that I'd like to make sure that the
idea stays on people's RADAR.

Meanwhile I'd like to clarify my idea a little more. In the brief
example below I focused on zone equivalency because in my mind the IDN
TLD use case is a big driving factor for this (as well as a driver in
regards to the urgency of finding a solution). But as I have envisioned
it, there is no reason that a CLONE RR couldn't apply at any level of
the tree. The idea I have in mind at its most fundamental is that
whenever a CLONE RR is encountered that the server treat the variant "as
if" what was really queried for was the preferred label. The
authoritative server can handle this all itself for non-CLONE resolvers,
and everything will work except DNSSEC, and without CNAME synthesis and
its attendant problems. A CLONE-aware resolver would be able to generate
requests for the preferred label internally, and validate DNSSEC
signatures for the preferred label. There's room to quibble on setting
the AD bit for variant answers.

more to come ...

Doug

-------- Original Message --------
Subject: Re: [dnsext] cloning zones
Date: Tue, 15 Dec 2009 12:46:05 -0800
From: Doug Barton <[email-masked]>
Organization: http://SupersetSolutions.com/
To: Andrew Sullivan <[email-masked]>
CC: [email-masked]

Andrew Sullivan wrote:
> No hat.
> 
> On Tue, Dec 15, 2009 at 03:38:54PM +0000, Jim Reid wrote:
>> A zone is a zone: an independently managed part of the name space. A DNS 
>> protocol extension to "clone" zones -- if that's what we're talking about 
>> here -- is not the way to solve what looks to be a provisioning problem. 
>> Just generate N zone files (or equivalent) from the same data source and 
>> we're done. Hardware's cheap. DNS engineer time isn't.
> 
> Now our problem is that we're not actually solving the use case.
> We're saying, "You, zone person, solve this."

What *I* am saying is that there is no way to solve the "variant" use
case (whether that's at the TLD level or higher) without trusting the
delegee to Do The Right ThingTM.

Furthermore, I am saying that there is no way to truly make what you
and Ed seem to be describing (treat every variant as an exact,
functional duplicate of the "front end" domain in every way, for every
purpose, including DNSSEC) without changes to the resolvers, which is
problematic politically as well.

> Suppose that I am the operator of example.org, and I have a local
> policy that alternative spelling of "the same word" [1] must always be
> delegated the same way.
> 
> If I delegate color.example.org and colour.example.org to the same
> delegee, how can I be certain that color.example.org and
> colour.example.org _really are_ the same?  

You can't, and you never will be able to. I actually have an idea that
I'll add to the end of this message, but no matter what c!3VeR h4cKz
we come up with the end result is always going to be that we have to
trust the delegee.

So first of all, I repeat my request for a clearer definition of the
problem, political thorns and all. Those who have a distaste for
trying to craft technical solutions to solve policy disputes are free
not to participate.

Meanwhile, I knew I should have posted this last night because it's
related to the subject of your message and I don't want to sound
derivative, but my idea is a completely new RR called CLONE. In the
parent, you configure your zone thusly:

domain		NS	ns1.domain.tld.
...
domain		DS	blah

variant1	CLONE	domain
variant2	CLONE	domain
...

Since Paul already said he's feeling agreeable towards config file
support for this kind of idea, in a BIND server you might do something
like this for the variants (assuming "normal" configuration of
domain.tld):
zone "variant1.tld" { clone "domain.tld"; };
and you're done.

Now obviously the tricky part comes in the interaction with the
resolvers. This is all very rough of course, but a CLONE-aware
resolver would know what to do when it receives that response. My idea
of what it should do is to "internally transpose" the string
"variant1" with "domain" so that if an end user asks for
"www.variant1.tld" and the resolver receives a CLONE response that
says "variant1.tld == domain.tld" it can substitute "domain.tld" for
queries, DNSSEC validation, etc.; then return the answers to the end
user _with no mention of "domain.tld" whatsoever_. We would probably
want some sort of flag to indicate that it was a CLONE response, but
if we're actually going to make the two domains "the same" then there
cannot be any actual difference in the ANSWER, ADDITIONAL, or
AUTHORITY sections.

What to do with non-CLONE-aware resolvers is obviously the tricky bit.
My vote would be that if the resolver does not understand CLONE that
the authoritative server simply sends the requested information as if
the resolver had actually asked for "domain." Unless I'm missing
something obvious that would work for all purposes except for DNSSEC,
but with the root being signed with SHA-2 we've got some software revs
coming up to handle DNSSEC anyway. How a resolver signals that it does
or does not understand CLONE is left as an exercise for the reader.

I should also add that both child and parent should have useful
responses to a CLONE qtype, which could be used by interested parties
to (sort of) verify that both ends of the delegation are doing what
they are supposed to do, assuming once again that they can both be
trusted not to forge the responses.

Enjoy kicking this one around,

Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 28 Jul 2010 07:12:20 -0400

Doug,

Your note reads similar to what I recall writing, that the IDN urgency 
(at layer 9 or somewhere) was more correctly characterized as the 
SC/TC issue, and with far less specificity in the zones subject to 
pre-delegation review by the IANA function and allied actors, for 
"variants" generally, and (deep breath, your point) that the scope of 
any "equivalence" mechanism should not be over constrained to 
equivalence between any nodes in a tree which share the same direct 
parent.

Others wrote notes similar, IIRC.

Eric

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Jul 2010 14:46:58 +0000

doug,

in <draft-vixie-dnsext-dnsshadow-00.txt> the following text appears:

   3.7. No changes are required for recursive nameservers, stub
   resolvers, or applications.

for SHADOW, this was a design invariant.

can you say the same for the CLONE RR?

paul

---

From: Doug Barton <[email-masked]>
Date: Wed, 28 Jul 2010 11:18:10 -0700 (PDT)

On Wed, 28 Jul 2010, Eric Brunner-Williams wrote:

> Doug,
>
> Your note reads similar to what I recall writing, that the IDN urgency (at 
> layer 9 or somewhere) was more correctly characterized as the SC/TC issue, 
> and with far less specificity in the zones subject to pre-delegation review 
> by the IANA function and allied actors, for "variants" generally,

To the extent I understand what you're saying here I'd like to point out 
that the conclusions you seem to have drawn about the landscape are not 
necessarily the same ones I have come to. More specifically it is my 
understanding that there is a general class of what I loosely refer to 
as "IDN ccTLD issues" that extend into other scripts in addition to the 
SC/TC problem, but do have similar characteristics to it. I think that 
draft-yao-dnsext-identical-resolution-01 is an excellent start on 
describing this.

> and (deep breath, your point) that the scope of any "equivalence" 
> mechanism should not be over constrained to equivalence between any 
> nodes in a tree which share the same direct parent.

I would like to see us develop a solution that does not have "same 
direct parent" as a requirement, yes.

> Others wrote notes similar, IIRC.

Agreed. I hope it was clear from the previous round of discussion that I 
don't claim a unique, or comprehensive view of either the problem(s) or 
the solution(s).

Doug

-- 

 	Computers are useless. They can only give you answers.
 			-- Pablo Picasso

---

From: Doug Barton <[email-masked]>
Date: Wed, 28 Jul 2010 11:38:19 -0700 (PDT)

> can you say the same for the CLONE RR?

No, in fact I am specifically anticipating a "resolver" element (where 
that includes all 3 categories you so ably describe above) in order to 
make DNSSEC work at the label level instead of at the zone level. If we 
agree that the variant labels need to be equivalent in functionality to 
the preferred label, then DNSSEC is a requirement. I don't see any way 
to provide DNSSEC support for the variants without a resolver component 
(although I'd be glad to be proved wrong on this.)

Back in December my original concept of CLONE RR was heavily influenced 
by your discussion of what became SHADOW in the sense that I agree quite 
strongly that we need a solution that puts as much as we can on the 
authoritative side in order to deploy as rapidly (and un-messily) as 
possible. My read of the IDN community who is interested in this 
solution is that they would generally be accepting of a solution that 
says, "You can get everything except DNSSEC today, and getting DNSSEC is 
simply a matter of educating your userbase on deploying new resolver 
code." (Of course I'm anticipating that people will find other uses for 
this, but IMO if we can't solve the IDN problem then there's no point in 
doing the work.)

So you and I share a lot of common ground in our thinking here. The 2 
things I don't like about SHADOW are primarily that it's zone-based as 
opposed to "arbitrary label based," and the "heaviness" of having to 
essentially duplicate an entire zone in the server. Of course you know a 
lot more about implementing name servers than I do, so it may be that 
you're right about the duplication issue and my concept of "as if" is 
totally off the mark. But that's why I need to write a draft so that we 
can discuss it further.

Doug

--