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

From: [email-masked]
Date: Thu, 15 Oct 2009 14:43:52 +0100

> comments are welcome. thanks. 

There are, in my opinion, two problems with the DNAME method that affect 
the application layer that are rarely mentioned.  Perhaps this is because 
I am wrong about them and they are not real problems, so feedback would be 
useful.

1.  "Host:" headers

If a registry (or other parent zone) unilaterally adds DNAME records that 
alias a new IDN label to a current ccTLD style ASCII label, application 
servers which are only configured to accept requests for the ASCII form of 
the label will reject requests made using the IDN form.

i.e. if your Apache server is configured with:

  ServerName www.cnnic.cn

it will reject requests for www.cnnic.中国 unless the appropriate 
ServerAlias is also configured.

2.  SSL Subject Names

Similarly an SSL request for the IDN version of a domain name will fail 
unless the SSL certificate also includes a "Subject Alternate Name" for 
the IDN version.

Whilst the same problems can also occur with the NS method, I believe that 
the risk for confusion is much reduced if the creation of each IDN label 
is controlled by the domain owner, and not done automatically by the 
parent.

The domain owner can then make the choice for themselves whether to 
support both IDNs and ASCII labels, and configure their web servers etc 
appropriately.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Oct 2009 16:44:06 -0400

Dear colleagues,

On Thu, Oct 15, 2009 at 09:22:53PM +0800, Yao Jiankang wrote:
> Dear all,
> 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
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Oct 2009 09:03:38 +1100

In message <[email-masked]
> ServerAlias is also configured.

	So what?  And for www.cnnic.xn--xxxxx.  Once the DNAME is
	in place operators will put the alias in place. 

> support both IDNs and ASCII labels, and configure their web servers etc 

	Again, so what?

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 16 Oct 2009 10:42:05 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 16, 2009 4:44 AM
Subject: Re: [DNSOP] new draft about idn tld variants implementation

> I have reviewed the aforementioned draft, and I have some comments. 

thanks for your kind review.

> I
> disadvantages of the different alternatives.

we may adjust it in the next version.

>  As it stands, the draft

DNAME also has many advantages. It is the disadvantages(or problems) which may block the use of DNAME in the root.
so we emphasize the problems.

of course, we can also add more advantages into the document of the future version.

> problem, then the delegation shouldn't be in place anyway. 

if we dname is used in the root, all dns administrator of the names below the TLD should have the dname knowledge. 

I am sure that the TLD delegation side has enough power or expertise to run DNS.

" .example" is run by TLD delegation;
"xx.example" is run by xx DNS administrator;
"yy.example" is run by yy DNS administrator;
"zz.example" is run by zz DNS administrator;
"aa.zz.example" is run by aa DNS administrator;
xx and yy may have the knowledge of DNAME, but zz and aa may not.

if zz and aa have not the dname knowledge, they may mis configure it:

for example: aa.zz.example     86400  IN      A       192.168.1.1

> "The

pls see above, we do not afraid the tld delegation side, but afraid of the side below the TLD.

> less suited to this use in the root than it might be elsewhere.

since root is very important, its running need stable technology.
any technolgy that may cause some problems or lead to some potential problems in the future
should be evaluated in detail. if the rooth has the problems, it will impact the whole internet.
only single domain name's problem is a single domain's problem; it will not impact the whole internet.

> into account when someone makes a decision to support variant labels.

in the future, there will have thousands of IDN TLD in the server; one IDN TLD in the root may have little impact on the performance of the root server.

how about  thousands of IDN TLD?

> operators' fora, or at ICANN, but not here I think.

but the DNSOP charter says " 4. Publish documents concerning the operations of the root and
      TLD services, and DNS resolvers."  http://www.ietf.org/dyn/wg/charter/dnsop-charter.html

> guide to practical action.  

it may be trivial problem, but the trivial problem in the root may impact the whole internet.
the trivial problem in your domain name may still be trivial.

> is going to be part of the problem set to be solved.

the new IDN TLD is put in the root as the form xn--abcd with NS record.

these are old to DNS servers.

>So the mere fact

maybe, there is a little misunderstanding.
my view is :
dname is a good technology, it may good for secod level domain, but not proper for the root.

> records at the zone apex where a DNAME lives.

in the draft, I consider "DNAMEs do not redirect an entire tree." as the character of the dname technology.
it is not be considered as the reason why dname should not be used in the root server.

> an effective argument for that position.

pls see the discussions above.

> for the same zone would be foiled.

idn tld and its variants are different string in the root.

the internet users expected that they should be same or equivalent in the dns resolution.

so in this draft, we suggest the technology combined with some policy to achieve this goal.

> than by the use of DNAME.

my suggestion is that apply the NS in the root and apply the DNAME in the second level.

This draft brings an issue: the internet user wants the idn tld and its variant should be same or equivalent or identical in the dns resolution. how to achieve this goal?
this draft also propose a possible solution.

I think that the issue is in the scope of DNSOP since the charter says " Publish documents concerning the operations of the root and
      TLD services, and DNS resolvers."

if it is the issue, we may discuss the solution in more detail in this working group.

thanks a lot for Andrew's kind review.

Yao Jiankang

> 
> Best regards,
> 
> Andrew
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Sebastian Castro <[email-masked]>
Date: Fri, 16 Oct 2009 17:54:38 +1300

Dear colleagues,

my reply to Andrew inline (I don't cover all points tho)

> operators' fora, or at ICANN, but not here I think.

I think it's a valid concern about the load at the root servers and
agree it doesn't correspond here to discuss it. If ICANN/root_operators
decide to implemente the IDN TLD variants by using DNAME, every query
for a name under the variant will go to the roots. If within the TLDs
receiving their IDN variants are two or three 'big' and the variants are
popular, the query load may increase heavily in a short period of time.
I insist the argument per se doesn't belong to this discussion, but
should be considered later.

> records at the zone apex where a DNAME lives.

I agree with this. At .NZ we have been checking the DNAME alternative to
implement a variant for a IDN SLD (māori.nz will be equivalent to the
existant SLD maori.nz). In our particular case, being maori.nz a
delegation-only zone, the use of DNAME doesn't break things. But from
the experience from Greece (who has been using DNAME for a few years),
using DNAMEs for domain names use in emails, that will break things.

> for the same zone would be foiled.

Actually there is a way to implement the variant by delegation that
assures the aliasing: a DNAME record on the apex of the variant zone.
That alternative is indicated in the RFC.

Even if that alternative is not used, you are assuming the zones would
diverge. That is stepping on the implementation the registry uses: if
they feed their zone generation with the same data and different origin,
there is no reason to doubt they will generate diverging zones.

> than by the use of DNAME.

My conclusions are the draft, to be considered for discussion, should
include the benefits and issues related to both alternatives (DNAME at
the root versus delegation). The current version is a summary of the
potential issues with DNAMEs only.

Also there are some structure and wording issues. For example, the
abstract and the introduction are the same.

Probably I will continue the discussion of this document to provide a
more fine grained criticism.

cheers

Sebastian Castro

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Oct 2009 16:32:42 +1100

In message <[email-masked]>, Sebastian Castro writes:
> for a name under the variant will go to the roots.

No they won't, only non-DNAME aware resolvers will go back to the
roots.  DNAME aware resolvers will perform the synthesis locally
using the cached DNAME.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Oct 2009 12:33:27 -0400

A couple clarifying questions and remarks inline.

> if we dname is used in the root, all dns administrator of the names below the TLD should have the dname knowledge. 

Ah, so your worry is that, if we have example. and
variantexample. DNAME example, then if anyone configures
www.somedomain.variantexample, it will be occluded?  Yes, that's
true.  But it seems to me that this is actually a _reason_ to prefer
the DNAME approach rather than not.  For if we simply have two
delegations (example NS, variantexample NS) then we'll also have the
problem that someone could easily configure www.somedomain.example A
1.2.3.4 and www.somedomain.variantexample A 2.3.4.5, and there would
be nothing at all to prevent this.  This is in fact exactly why I
think the DNAME approach is the only reasonable one.  Otherwise, what
happens is that we just create alternative namespaces.  There is
simply no way to prevent that under plain delegations, and there's
certainly no way to test it.

> any technolgy that may cause some problems or lead to some potential
> problems in the future should be evaluated in detail. if the rooth
> has the problems, it will impact the whole internet.  only single
> domain name's problem is a single domain's problem; it will not
> impact the whole internet.

I completely agree, but the draft has nothing like an argument in it
to the effect that there is anything "unstable" about DNAME.  If you
want to make that argument, it is open to you; but at the moment the
argument really just consists of vague suggestions that something
might be bad.  We cannot make operational decisions simply on the
basis of fear, uncertainty, and doubt.  If there's a real problem with
the protocol itself, you need to make the argument, and not just say,
"Well, maybe there could be a problem someday."  There _could_ be a
problem with any RRTYPE.  For instance, someone decided to overload A
records in order to indicate spam sources; that's not a reason never
to use A records.

> in the future, there will have thousands of IDN TLD in the server;
> one IDN TLD in the root may have little impact on the performance of
> the root server.
> 

I don't know, neither do you, and anyway we're not root nameserver
operators.  The right way to handle this is to point out the load
issue, and then ask the operators of the name servers to say whether
they can handle the projected increase in load.  That would require,
among other things, studying the number of cases where a 0-TTL CNAME
would be generated.  Therefore, this is a practical consideration that
needs to be taken into account, and not a reason in itself either to
reject or accept DNAME.  I agree that the root operators need to look
at this and their feedback will be important.  But you can't use it as
a premise that DNAME is necessarily the wrong choice, because you
haven't shown that the load will seriously affect the root name
servers.  All you have shown is that it might; and that's not enough.
Merely adding more records will _also_ affect the root name servers.
Is that therefore reason to conclude, out of hand, that we can add no
more?  Apparently not, if the recently published study is to be
believed.

> it may be trivial problem, but the trivial problem in the root may
> impact the whole internet.  the trivial problem in your domain name
> may still be trivial.

To clarify: I was not saying that the problem is trivial, but that the
proposition, "If someone makes a future change incompatible with the
existing deployed DNS, then the existing deployed DNS might break," is
trivially true.  The consequent is literally contained in the
antecedent of the conditional sentence: the "incompatibility" in the
first part _just means_ "might break" in the second part.  This is
related to the fear, uncertainty, and doubt I mentioned above: it's
always true that someone could make a future incompatible change that
breaks everything.  But we rely on the protocol community not to do
that.  So if your argument depends on that premise, you have to show
that the entire protocol community will take leave of its senses.
(Now, some would argue that we have ample proof of such leave-taking;
but that's an argument you need to make.)

> my suggestion is that apply the NS in the root and apply the DNAME

By "DNAME in the second level", I understood you to be suggesting that
the root delegates variants by NS records, and then TLDs and below
uses DNAME to support variants.  But maybe you mean something else:
the root delegates the variants via NS records, but on the child side
at the apex all the variants but one are DNAMEs.  If this is what you
mean, then actually I don't think there's any difference in these
approaches, provided that the parent enforces that the target of the
variant NS has exactly the SOA and the DNAME at the apex.  I wouldn't
oppose a document that said that (although I think it would be tedious
to support this arrangement).

 Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 19 Oct 2009 10:56:44 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, October 17, 2009 12:33 AM
Subject: Re: [DNSOP] new draft about idn tld variants implementation

> true. 

+1

> But it seems to me that this is actually a _reason_ to prefer
> be nothing at all to prevent this. 

there is no perfect technology to do this.  the draft suggests that the two domains should be allocated to the same registrant.
The registrant can configure www.somedomain.example  and www.somedomain.variantexample to the same IP address or not.
Most registrants will configure the two domains to the same IP address.
even they do not point to the same address, it does not matter since they belong to the same registrant. One aim of this draft is to use some technology combined with some policy to prevent the future possible phishing.

> This is in fact exactly why I

pls see above.

> might be bad. 

in the draft, I listed some dname issues that need to be considered.
and then give some suggestions or guidelines.

> We cannot make operational decisions simply on the

maybe some wording in my draft need some adjusting. in the draft, I describe some characters or issues of the DANME as the problems.
some characters of the DNAME are not suitable for being implmented in the root.
DNAME is a good technology. In many places, we can apply this technology. for example, in some second level domain, we can apply dname as this draft suggests.

> servers.

I do not say that dname in the root is the wrong choice. I say that it is not proper.
the title for secton 5.2.1. in the draft is "  DNAME is not proper for IDN TLD variants" and this section also
list some reasons.

If DNAME technology is put into the root, the root must consider more issues than NS record.

>All you have shown is that it might; and that's not enough.

   The Section 4.1 of [RFC2672] specifies that DNS clients sending
   Extended DNS [EDNS0] queries with Version 0 or non-extended queries
   are presumed not to understand the semantics of the DNAME record, so
   a server which implements this DNAME specification , when answering a
   non-extended query or the query with the Extended DNS Version 0
   [EDNS0], SHOULD synthesize a CNAME record for each DNAME record
   encountered during query processing.

if the current DNAME server may implement it like this way:

if {Extended DNS [EDNS0] queries with Version 0 or non-extended queries are received}
then do { synthesize a CNAME record for each DNAME record}
else do {the DNAME record without the CNAME}

now the EDNS1 appears. The DNS clients with [EDNS1] may not know the DNAME.

so the tradional DNAME server will not  synthesize a CNAME record for each DNAME record when the EDNS1 appears.

I also list some other issues that might occlude the use of dname in the root server.
you may consider that it is not enough to preclude the  use of dname in the root server.
of course, if all these issues raised are trivial to the root server operations, we can still conider the DNAME to be used in the root.

> to support this arrangement).

thanks for your understanding.

the advantages of  applying the NS in the root and apply the DNAMEin the second level is that
the root serve can still add the more NS records as the normal procedure.
most of the second level domain owner may choose the DNAME. A litfle of them may still perfer the NS records.
so whether the dname is used in the second level is decided by the registrant.

Yao Jiankang
CNNIC

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Oct 2009 08:28:02 -0700

Andrew may have not made his point clear to the authors, but I think it is an important one: you need to treat the two options the same if you want the DNS community to take this document seriously. If this were just meant as an Informational RFC that stated the way CNNIC was thinking, of course it is not important to be balanced, but the intended status of this document is BCP, which is essentially like standards track.

If later versions of this document boil down to "technical problems with DNAME and policy enforcement problems with NS", that's fine. However, such a document would probably not become a Best Current Practice because it is simply stating a tradeoff. We have no operational experience to say which side of the tradeoff is "best".

--Paul Hoffman, Director
--VPN Consortium

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 20 Oct 2009 09:06:31 +0800

Dear Hoffman,

       thanks a lot for your comments and suggestions.
      we will update it according to your kind suggestions.
   
Yao Jiankang
CNNIC