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. 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. > 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. 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. > > (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. 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.) > 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). Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
