----- Original Message -----
From: "Andrew Sullivan" <a...@shinkuro.com>
To: <dnsop@ietf.org>
Sent: Saturday, October 17, 2009 12:33 AM
Subject: Re: [DNSOP] new draft about idn tld variants implementation
>A couple clarifying questions and remarks inline.
>
> On Fri, Oct 16, 2009 at 10:42:05AM +0800, YAO Jiankang wrote:
>
>> 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.
+1
> 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.
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
> 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.
pls see above.
>
>> 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.
>
> 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.
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
> 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.
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.
>
>> > (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.
>>
>> 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?
>
> 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.
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.
> 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.
>
>> > 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.
>>
>> 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.)
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.
>
>> my suggestion is that apply the NS in the root and apply the DNAME
>> in the second level.
>
> 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).
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
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> a...@shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
