----- Original Message ----- From: "Andrew Sullivan" <a...@shinkuro.com> To: <dnsop@ietf.org> Sent: Friday, October 16, 2009 4:44 AM Subject: Re: [DNSOP] new draft about idn tld variants implementation
> 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. thanks for your kind review. > 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. we may adjust it in the next version. > 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. 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. > > 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. 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 > 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.) pls see above, we do not afraid the tld delegation side, but afraid of the side below the TLD. > > (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. 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. > > (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? > 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. 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 > > (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. 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. > > (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. 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 > of novelty is certainly not enough to push DNAME out of the running. 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. > > 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. 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. > > 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. pls see the discussions above. > > 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. 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. > > 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. 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 > 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
