Subject: [dnsext] Position statement of Jiankang Yao on DNS name equivalence

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 15 Feb 2010 23:46:38 +0800

Dear all,

    below are my comments to the solution space:

>1. Do Nothing 

the wg should do something to solve dns name equivalence. 

ICANN need it for IDN TLD variant; users need it for about identical resolution of internet name variants;

registry or registrar need it for dealling with bundling names.

>2. Recommend the problem be solved as a matter of provisioning 

The WG should do something. other wg can not solve it. 

>3. Recommend the problem be solved in zone master servers: "clone" 

I support both zone clone and bname are used for solving name equivanlence. different users can select different methods : bname or zone clone based on their own needs.

>4. Provide operational guidance for supporting the goal using CNAME only 

>It is probably actually impossible to obtain the desired behaviour using only CNAME. But CNAME could be used as a mechanism to provide "aliases" for any terminal >name. 

partial solving the problem.

>5. Solve the problem using DNAME at the parent. 

>In combination with some provisioning tools, DNAME might be an adequate solution to this issue. DNAME entails some server-side processing, however. 

DNAME is not suitable for being deployed in the root.

>6. Recommend delegation to zones using DNAME at the child 

>Instead of using DNAMEs at the parent side, the parent could delegate as though the zone is a completely different zone, but require as a matter of contract that the >variant zones include a DNAME for the name, and all and only DNS RRs for non-DNS-control records must also match. (So, for instance, NS records in the variant, >and the SOA record or any RRSIG record, need not match. But for every A record at the main name, there must be a corresponding A record at each variant name, >and for every A record at a variant name, there must be a corresponding A record at the main name.) 

may work, but also entails some server-side processing due to the synthesized CNAME with TTL zero.

>7. Alter the specification of DNAME 

>7.a to permit combination with CNAME 

>The combination of CNAME and DNAME would allow an entire tree to be aliased without difficulty. This is a backwards-incompatible change, however. 

agree.

>7.b To follow DNAME target if requested type does not exist with the DNAME 

>This change basically changes the DNAME from translating below the target to translate to the target when ever the DNAME rules apply at the QNAME. 

this also has some backwards-incompatible problems.

>8. Do (7) except with a new RRTYPE 

>This is the "BNAME" proposal, more or less.  http://tools.ietf.org/id/draft-yao-dnsext-bname-01.txt 

:) I support this.

>9. Provide an aliasing mechanism that points to an NS record, and which is not allowed to be part of a chain. 

not suitable for ICNN IDN TLD variants.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 Feb 2010 09:04:28 -0500

Thanks, Yao, for your response to the position statement.
I wish other members of the working group had responed to it so we could 
have had some questions answered before our Interim meeting.

Below are few points that I would like to understand better.

> The WG should do something. other wg can not solve it.

I kind of agree with this, but the working group may lay down a solution 
that is out-side the strict "protocol" space and a
different WG may work on it.

> I support both zone clone and bname are used for solving name equivanlence. different users can select different methods : bname or zone clone based on their own needs.

In my personal mind I think "clone" type solution is the "short term" 
solution, but the one question what is the "long term" solution?

>> It is probably actually impossible to obtain the desired behaviour using only CNAME. But CNAME could be used as a mechanism to provide "aliases" for any terminal>name.
>

Why, please explain why you think DNAME will not work there.
We know that some people have argued that DNAME in the root would couse
too much overhead to do the CNAME synthesis, but that is FUD.
Silightly bigger issue is Root and TLD's in general have is that their
provisioning systems assume that the zones will ONLY contain NS records
this on its own may not be sufficient reason to reject this particlular
approach.
If there is a differen reason that resticts the this solution or any 
other @parent solution, I would like it on the table.
Note: change in operation or contracts required, IMHO is not sufficient.
All parties invoved MUST be willing to adopt to the solution proposed 
for it to have a chance to succeed.

For the record DNAME@parent has the has the potentail to have one
of lowest operating costs of all solutions, as there is no need to 
maintain a "clone" or do DNSSEC for the clone.

>> Instead of using DNAMEs at the parent side, the parent could delegate as though the zone is a completely different zone, but require as a matter of contract that the>variant zones include a DNAME for the name, and all and only DNS RRs for non-DNS-control records must also match. (So, for instance, NS records in the variant,>and the SOA record or any RRSIG record, need not match. But for every A record at the main name, there must be a corresponding A record at each variant name,>and for every A record at a variant name, there must be a corresponding A record at the main name.)
>

Almost any protcol change has either backwards-incompatible problem or
a "wait-for-deployment" problem. The question is going to be which one
is are we going to tolerate and which one we think can be deployed
faster.

>> This is the "BNAME" proposal, more or less.  http://tools.ietf.org/id/draft-yao-dnsext-bname-01.txt
BNAME is one possilbe solution not the only one :-)

> not suitable for ICNN IDN TLD variants.
Please explain why ?

On the face of it this is equivalent to BNAME@parent w/o
chain following.

	Olafur

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 16 Feb 2010 22:32:51 +0800

----- Original Message ----- 
From: "Olafur Gudmundsson" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: "Andrew Sullivan" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 16, 2010 10:04 PM
Subject: Re: [dnsext] Position statement of Jiankang Yao on DNS name equivalence

> maintain a "clone" or do DNSSEC for the clone.

ICANN has evaulated and discussed dname many years. so that there is still no conclusion about dname.
one reason I think might be that the current RFC2672 specify the synthesized CNAME with TTL zero, which will cause many problems to root servers.

other reason might be that since DNAME only maps the descendants, not itself. so many registry representives do not prefer them.
some like them, some dislike theme.

I submitted a draft about "draft-yao-dnsop-idntld-implementation" in dnsop and discussed in the last ietf meeting.
one solution is suggested to use dname, but no one prefer it. You may follow some discussions in the dnsop list about "draft-yao-dnsop-idntld-implementation"
for more information.

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Feb 2010 14:49:45 +0000

> still no conclusion about dname.

That may be true. But it doesn't matter. ICANN isn't in a position to  
make technical decisions about the DNS protocol or define standards.  
That's the job of this WG and our colleagues in dnsop.

> other reason might be that since DNAME only maps the descendants,  
> not itself. so many registry representives do not prefer them.

This may well be true too. However there should be strong technical or  
engineering reasons to support non-trivial changes to the DNS  
protocol. IMO these need to be on firmer grounds than some people  
don't like certain protocol features or the operational impact of  
using them.

---

From: Chris Thompson <[email-masked]>
Date: 16 Feb 2010 15:39:58 +0000

On Feb 16 2010, YAO Jiankang wrote:

>one reason I think might be that the current RFC2672 specify the synthesized
>CNAME with TTL zero, which will cause many problems to root servers.

Regardless of whether it would really cause "many problems", this is fixed
in draft-ietf-dnsext-rfc2672bis-dname, which would have been an RFC by now
if it hadn't been for ... well, enough of that. But I see that ISC have got
bored with waiting for it, and implement TTL(synthesized CNAME) = TTL(DNAME)
in BIND 9.6.2 and 9.7.0.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Feb 2010 16:12:02 +0000

> From: Jim Reid <[email-masked]>
> Date: Tue, 16 Feb 2010 14:49:45 +0000
> 

-1.  see below.

> > other reason might be that since DNAME only maps the descendants, not
> > itself. so many registry representives do not prefer them.  some like
> > them, some dislike theme.
> 
> protocol. IMO these need to be on firmer grounds than some people don't
> like certain protocol features or the operational impact of using them.

also -1.

we are engineers here, and these folks are our customers.  just as we got
it wrong with NSEC by making something technically correct which our
customers "didn't like" thus leading to another several-years delay in
dnssec deployment while we did NSEC3, so it is that if ICANN or the TLD
folk "don't like" DNAME for various reasons, then it's the wrong solution,
no matter whether *we* consider it adequate to *their* purpose.

we can ask for better documentation as to their dislikes.  we can try to
workshop with them to make sure that they really don't like it and that
their dislike isn't a matter of misunderstanding or mistakes in testing.
but if they really and truly "do not like" our proposed solution, then we
have to carve it in granite and work by the light of it.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Feb 2010 16:26:44 +0000

> Date: 16 Feb 2010 15:39:58 +0000
> From: Chris Thompson <[email-masked]>
> 
> ... But I see that ISC have got bored with waiting for it, and implement
> TTL(synthesized CNAME) = TTL(DNAME) in BIND 9.6.2 and 9.7.0.

and we're going to have egg on our face if we guessed wrong about the
likely standardization outcome.  but it looked so close, for so long...

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 16 Feb 2010 16:33:56 +0000

On Tue, Feb 16, 2010 at 04:12:02PM +0000, Paul Vixie wrote:
>
> we are engineers here, and these folks are our customers. 

+1.

> have to carve it in granite and work by the light of it.

....Which is why the requirements work of "What *do* you need?" is so
important.

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Feb 2010 17:00:53 +0000

On 16 Feb 2010, at 16:12, Paul Vixie wrote:

> if ICANN or the TLD folk "don't like" DNAME for various reasons,  
> then it's the wrong solution, no matter whether *we* consider it  
> adequate to *their* purpose.

I agree Paul.

But I wasn't saying what you seemed to think I said. And anyway this  
WG can't do stuff in an ivory-towered vacuum. [Apologies for the mixed  
metaphors.] If some folk don't like DNAME/<insert-DNS-annoyance-du- 
jour-here>, I hope that by itself shouldn't trigger wholesale changes  
to the protocol. There has to be something more than "I don't like X"  
or "X is broken" to start a new work item. As Suzanne just pointed out  
that something more could be asking for an explanation of why they  
don't like X or clarification of their actual requirements. That was  
what I was hinting at in my earlier mail even though it wasn't  
explicit as it should have been.

---

From: [email-masked]
Date: Tue, 16 Feb 2010 17:51:23 +0000

> explicit as it should have been.

	thanks for the chuckle... is there any good reason why
	"they" should come to "us" to solve any of their problems?
	its open source and they can solve their own problems - there
	is no reason they couldn't or shouldn't start from the premise,
	"I don't like X" or "X looks broken to me" and make it work the
	way they want.  far too often folks bring an idea forward only
	to be derided and belittled because their problems were not 
	perceived to be interesting or important... not big enough.

	but every now and then, a grass roots idea gets traction.

--bill

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 16 Feb 2010 13:17:54 -0500

On 2/16/10 11:12 AM, Paul Vixie wrote:
...
> no matter whether *we* consider it adequate to *their* purpose.

I looked at this a couple of times and went back and forth on whether 
or not to ... differ.

Ok. Here it is. As usual when I write I misuse pronouns, so the "you" 
that follows is symbolic, not an actual person.

In their world view (the World According to Ira "Garp" Magaziner), 
their requirements arise from a Multi-Stakehlder, Bottoms-Up Process 
(MSBUP). When you're through laughing, recall that until 2003, the 
IETF was formally a "stakeholder", as one of several bodies 
constituting the "Protocol Supporting Organization". The import of 
that is, in _their world view_ the "us/them" dicotomy doesn't exist, 
*we* are part of *them* (queue the great movie about ants in the 
Mohave and LA River storm drains), and it doesn't matter that the PSO 
was defunted in '03, we are still somewhere in the dizzy constellation 
of MSBUP.

Restated, if you think non-ASCII labels is a real requirement, but the 
Elbonian (Lower) "IDN Requirements for Elbonian" mistaken, then you 
may solve for the correct requirement, not the incorrect requirement. 
If you can't think of an Elbonian example, try the Arabic Script IDN 
WG dicta that all labels in Arabic Script be (not "identifiers") 
proper words in the Arabic language. I could go on, but that's a nice 
example of a requirement which is ... off by more than one.

Next, looking to *them* as the source of dissatisfaction with 
existing, or the need for additional mechanism(s), for the problem at 
hand, variants, isn't really correct. The ugly truth is that the 
variants arise from *us*, from the IDN Working Groups of 2000-2003 and 
2008-2010, IDNA and IDNAbis, which in turn adopted a character 
repertoire from a body which began assembling a glyph catalog which 
over time acquired some character properties, and destroyed others 
through "unifications", because we couldn't, or wouldn't, look at the 
many character set standards, most pre-existing, and find a way of 
character sets which did not have to give rise to "variants".

So, as comforting as it is to view the requirements as absurd and 
arising elsewhere, some of the absurdity arises rather closer at home.

> have to carve it in granite and work by the light of it.

The tree equivalence idea is not chrooted in the TLDs, it is far more 
general. The variant problem is simply the equivalency of leaves of 
the same parent node, again, only casually confined to the TLDs.

I spend more time on ICANN than some and I think it is useful to 
retain some perspective about the actual functioning of the MSBUP.

ICANN is free to burn real money getting bespoke specification and 
development work done for them. In fact, they plan to do so in an 
operational problem domain proximal to this one. If "they" end up 
barking for the moon, unrestrained by the hold-overs from the PSO 
exercising Supporting Organization caution, the few members of the 
Board I at least associate with specific technical clue, there is no 
IETF necessity to diligently assemble heaps of canines.

I favor both the CLONE and the BNAME proposals, a lot, I just want to 
point out that we act autonomously, unemployed by ICANN, the ccTLD 
operators, or the current winners of the MSBUP lottery.

Eric

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 16 Feb 2010 21:39:37 +0000

> 	"they" should come to "us" to solve any of their problems?

As EBW just pointed out, who's "us" and who's "them" is....multiply
defined. ("Aliased," even.)

I'm usurping chairs' prerogative (which they're welcome to usurp in
turn) and calling this a rathole. 

There are people with requirements for the technology, there are
people who are capable of making the technology do things (no XORs
here, either), and there are a set of tools for mediating between
them, including open source development, proprietary development, and
standards processes.  Supposedly we are here to engage in the
latter....