Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

[Andrew Sullivan <[e-mail]>]

On Fri, Nov 06, 2009 at 11:25:14PM +0800, YAO Jiankang wrote:

> Fortunately, you are the chair of dnsext, not dnsop. otherwise, I
> may lose the opportunity :)

Just for the record, in a case where I act as a chair, I try very hard
to reflect the will of the WG even if it is not my judgement that it
is a good idea.  I should hope that participants hold me to such a
standard, and call me out in case they find I am not acting that way.
A recent example was the WG's decision to pull back the sha-2 draft
from the IESG because it did not like the aliasing mechanism in it.

But you point out something important: I didn't note in my review that
I comment only as a participant of DNSOP and not in any other
capacity.

> if you read the draft carefully, the draft does not enforce which
> method must be used. we provide many possible solutions.

I believe I did read the draft carefully, and it seems to me that it
is written in such a way that it fails to address the basic issue
bothering me: different delegations are, by their very nature,
dangerous for this purpose and therefore should not be used.

> since ICANN has approved the IDN ccTLD track, in a few months, there
> will have some IDN tld and its variant appearing in the root soon.

I am aware that ICANN has made that decision.  It bothers me when
ICANN makes policy decisions with technical implications without,
apparently, having worked through all the technical implications.  But
anyone who has been in any technical environment in all of history has
probably had that experience.  Just because we have to do something
doesn't mean we have to do something wrong, and I am of the opinion
that using the NS strategy is wrong.  The draft does not recommend
against it, so I oppose the draft as it stands.

> from your current wording, it seems that you oppose this draft
> because that the solution proposed is not your favor.  you does not
> oppose that the IDN TLD variants issue should be resolved.

If you want my real opinion, it is that the very idea of variants is
deeply mistaken, imports into the administration of the DNS a large
number of semantic issues that do not belong there, and involves a
number of naïve linguistic assumptions some of which were proven to be
false by (among others) Quine many years ago.  But, since the crest of
the slippery slope is already behind us, we need to address the idea
of variants in its own terms.  That means that the RNAMEs of a variant
must be precisely equivalent to all the other RNAMEs of which it is a
variant.  If that is not what "variant" means, then a more rigorous
definition of "variant" is necessary.  If it is what "variant" means,
however, then there is no way that separate delegations for the
different variants actually offers the precise equivalence needed.
DNAME does not, either, but it is much closer and therefore less
harmful to the idea that the two variants of one another are the same.

> if that is true, the reason that you oppose the draft is not reasonable.

I don't see how that follows.  My reason is that the draft leaves open
a possibility that I consider fundamentally harmful to the operation
of the DNS.  Why do you think that is an unreasonable position?

> I hope that you as the DNSEXT co-chair has much knowlege about DNS
> protocols, could you provide more constructive suggestions to help
> this draft

I think my review offers a constructive suggestion: the draft should
actively suggest that using different NS records to delegate variants
is mistaken, because it does not guarantee the child sides of the
respective zone cuts are in fact the same.  As an alternative, it
could recommend that tools be developed to ensure that the child side
of a variant RNAME is always only a DNAME to the "primary" name, and
that any delegation that fails to meet this requirement be immediately
removed from the parent zone.  The fact is that this would still
potentially introduce more than 24 hours of potential confusion (since
the root zone is published twice a day and the TTL on NS records from
the root is longer than 24 hours).

> the first time you opposed this draft is that you said that this
> draft is not in the scope of the WG and you prefer the DNAME.  I
> cite the DNSOP charter sentences to prove that it is in the charter.

The message at
http://www.ietf.org/mail-archive/web/dnsop/current/msg07698.html does
not say that the draft is not in scope of the WG.  I did argue that
there was a particular claim in the draft that didn't belong in output
of the WG; I'm delighted the subsequent update took that feedback into
consideration.  Moreover, your characterization above appears to
ignore just about every substantive remark I made in the
aforementioned review.

> now, you just simply say that "I am strongly opposed to the draft"
> and have no contructive suggestions.

This is simply false.  My suggestions remain the same as before: the
draft should recommend against using NS records to delegate two
different name spaces that are somehow supposed to be the same.  

I also suggest that the draft should make it quite plain to everyone
-- and particularly, to those who have to make policy about DNS
namespaces -- that there is as a matter of fact _no_ way to have two
namespaces be identical.  DNAME comes closer than anything else, and
therefore it is the only reasonable choice for this purpose. 

That is the primary suggestion I made in response to the -00 draft,
and it remains my suggestion now.  

> if we put DNAME into the root,  pls take a look at this presetation:
> https://www.dns-oarc.net/files/workshop-200911/Ziqian_Liu.pdf,
> 
> in May 19, 2009, the China Telecom network collapsed due to the too
> much queries to DNS recursive servers .
> 
> if dname is put into the root , the accidents similar to May 19
> affairs of China Telcecom network collapsing, and the attacked
> recursive servers happen to be dname-unware, all the attacks to
> recursive servers will directly go to the root since dname-unware
> resolvers or recursive servers has the TTL zero.  some root servers
> may be down. Do you want to see this being happened?

Your argument above is twofold.

First, it depends on an analogy between the China Telecom network
failure and the root nameserver system.  It is more or less impossible
for me, from my vantage point, to evaluate that analogy, because I
know almost nothing about the China Telecom deployment.  Given that
the presentation seems to have a large number of recommendations on
how to avoid this, and given that some of those recommendations appear
to be technologies widely deployed in the root server operations, it
seems at least possible that the similarity is not enough to conclude
that what happened to the China Telecom systems could also happen to
the root nameservers.  Any argument from analogy depends on the degree
of similarity of the two analogues, and so the more relevant
dissimilarities there are, the weaker the argument.  As I argued
before, I think the DNS operators have to evaluate what the real risk
is here. 

Second, it implicitly relies on the premise, "Either DNAME or NS,"
which is a conclusion that comes from the premise that we must have
variants.  But I claim NS is not appropriate because it does not make
the two delegations equivalent.  Therefore, we must use DNAME.  If
DNAME does not work because it imposes too much load, then we simply
don't have the ability to support variants.

I further argue that, if we suggest it possible to use NS records for
"variants", we're not actually adding variants at all.  We're adding
new TLDs, and that's all there is to it.  Some TLDs might have
contractual restrictions on what is allowed in them.  So, just as
.aero is only allowed things that conform to the policies of SITA, one
might have a TLD that is required to contain all and only delegations
in some other zone.  But that is entirely a contract matter, it is
firmly in the domain of ICANN and outside this WG's purview, and we
should not dress that contractual rule up as some sort of technique to
implement "variants".  It isn't, because there's no technical
mechanism that ensures TLD1 and TLD2 contain the same data.  I predict
-- indeed, I'd bet a pretty good meal on this -- that an NS-based
mechanism to implement the desired variant technology will result in a
new clasee of occasional inconsistencies that are sometimes
observable.

I hope this makes clearer what I'm trying to say.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.