Re: [DNSOP] new draft about idn tld variants implementation

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

On Thu, Oct 15, 2009 at 09:22:53PM +0800, Yao Jiankang wrote:
> Dear all,
> 
> comments are welcome. thanks. 
> 
> Yao Jiankang
> CNNIC
> ------------------------------------------------------------------------------------
> 
> http://www.ietf.org/id/draft-yao-dnsop-idntld-implementation-00.txt

I have reviewed the aforementioned draft, and I have some comments.  I
make these remarks as a participant in this working group, and with no
other hat on.

First, I am uncomfortable with the structure of the draft.  It would
be better if sections 3 and 4 were simply expositions of the different
proposed strategies, and then if section 5 provided the advantages and
disadvantages of the different alternatives.  As it stands, the draft
would be better called "draft-yao-no-dname-at-dns-root-00.txt",
because it makes a rather one-sided argument.

The draft presents a number of reasons why DNAME might not be
ideal for creating variant names within the DNS root.  These
reasons boil down to the following, on my reading:

    0.  DNAMEs do not redirect an entire tree.

    1.  DNAME is too new.

    2.  EDNS1 might make DNAME stop working.

    3.  The zero TTL of the synthesized DNAME could result in
    significant load at the root name servers.

    4.  CNAMEs might not get synthesized in every case where they
    should.

    5.  People who are delegated variants using DNAMEs might do the
    wrong thing.

I want first of all to reject out of hand (5) as a plausible argument,
particularly in the TLD space.  For TLDs, if we think (5) is a serious
problem, then the delegation shouldn't be in place anyway.  "The
delegate side is incompetent to run DNS" is a reason not to provide a
delegation, and nowise a reason not to use a perfectly good feature of
the protocol.  (Besides, if we started enforcing "competent with the
DNS" rules too stringently, we might have to shut down significant
chunks of the DNS.  Some days I think it a miracle that anyone can
resolve any name at all.)

(4) is basically an argument that the protocol doesn't work.  It's
just a bogeyman, as far as I can see: there is no argument whatever in
the draft that authoritative servers that provide DNAME sometimes by
accident fail to provide the synthesized CNAME where it is needed.
Perhaps, then, the draft is worried about clients that appear to the
server to understand DNAME, but that don't.  I'm first of all not that
sympathetic to arguments that implementations that are plainly broken
need to be accommodated forever.  But in any case as the draft argues,
dname-bis contains a provision that the CNAME be synthesized even when
not apparently strictly needed.  Since we can reasonably assume that
the root servers, of all the authoritative servers in the world, are
the most likely to have the sorts of protocol clarification we're
talking about, it is therefore unreasonable to argue that DNAME is
less suited to this use in the root than it might be elsewhere.

(3) is not, so far, an argument we have been hearing from the root
nameserver operators.  But in any case, this is a load and
provisioning issue, and is not an argument that can properly be made
about whether a given technology as such should be selected for a
given purpose.  It is rather a consideration that needs to be taken
into account when someone makes a decision to support variant labels.
It is an important operational consideration, and operational
constraints have to be taken into account when making deployment
decisions.  That's an issue to be debated in the root server
operators' fora, or at ICANN, but not here I think.

(2) appears to be a supposition that DNSEXT will simply fail to do its
job.  Obviously, if one were to standardize EDNS1, one would need to
take the effects on DNAME into account.  But this premise in any case
cannot be a reason to reject a given part of the DNS protocol, because
the premise can be generalized: if someone makes a future change that
is incompatible with the existing deployed DNS, then the existing
deployed DNS might break.  This is trivially true, but not a useful
guide to practical action.  

(1) seems just to be a way of rolling together the items above: it
doesn't really function as a separate premise.  After all, IDNA is
only from 2003, and it's being fixed with a protocol that hasn't even
made it out of the IETF yet, but the draft plainly supposes that IDNA
is going to be part of the problem set to be solved.  So the mere fact
of novelty is certainly not enough to push DNAME out of the running.

So we come to (0).  This is one issue that is a genuine possible
problem, since it makes the variant sort of a "second-rate" version of
the principal name: a number of things that people do today will break
if one tries to use just DNAMEs for the purpose of variants.  However,
that issue is not actually one we have to confront in the TLD space,
where nearly everything is delegation.  In fact, this issue, which
might cause trouble for DNAMEs being used for variants at other levels
of the tree, actually makes DNAMEs well-suited to the top level.
Moreover, it is possible to work around this stricture with DNAMEs at
lower levels, because DNAME does not prohibit other non-redirecting
records at the zone apex where a DNAME lives.

I reason, therefore, that while there might be issues with using DNAME
to support variants at the DNS root, the draft before us does not make
an effective argument for that position.

Now, let us consider whether supporting variants with alternative
delegations (the NS strategy) in fact achieves the goal that variants
are supposed to achieve -- that is, to make two completely equivalent
name spaces.  The answer is, "No."  For as the draft points out, by
adding another NS record, one creates a completely different
delegation.  There is nothing whatever about an NS delegation of $name
that links it in any way to an NS delegation of $variantname.  Once
the delegation is in place, there is no way for the parent to be sure
that everything under $name and $variantname are the same.  Indeed, a
strategy of using different delegations for the variants would not
actually be creating variants at all: it would be creating new TLDs,
period.  For large TLDs, it would in fact be impractical to ascertain
whether everything under the two delegations all matched.  And since
the underlying zones would have to be maintained separately (or else
generated from some proprietary database not specified anywhere we are
considering), there is every reason to believe that the different
zones _would_ diverge, and that the goal of creating just another name
for the same zone would be foiled.

Therefore, it is my view that the draft provides all the premises
needed to support the opposite of one of its important conclusions:
for the purposes of adding variants to the DNS root zone, the right
way to proceed is to use DNAMEs.  There may be a practical issue with
using DNAMEs at levels underneath the top level; I haven't thought
about that case enough to decide whether the issue is insuperable.
Certainly, all of the phishing issues that the draft is apparently
worried about avoiding are in fact made worse by NS-style delegation
than by the use of DNAME.

Best regards,

Andrew

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