Andrew Sullivan wrote: > Dear colleagues, Dear colleagues,
my reply to Andrew inline (I don't cover all points tho) > > > (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. 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. > > 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 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. > > 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. 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. > > 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 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 > > Best regards, > > Andrew > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
