Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
Alex Bligh <alex@alex.org.uk> Fri, 06 November 2009 19:07 UTC
Return-Path: <alex@alex.org.uk>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7548B3A683A for <dnsop@core3.amsl.com>; Fri, 6 Nov 2009 11:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.946
X-Spam-Level:
X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49TByysqSS18 for <dnsop@core3.amsl.com>; Fri, 6 Nov 2009 11:07:06 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [217.147.82.63]) by core3.amsl.com (Postfix) with ESMTP id 3C8B83A6832 for <dnsop@ietf.org>; Fri, 6 Nov 2009 11:07:05 -0800 (PST)
Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id E9A42C2DA3; Fri, 6 Nov 2009 19:07:26 +0000 (GMT)
Date: Fri, 06 Nov 2009 19:06:38 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Andrew Sullivan <ajs@shinkuro.com>, dnsop@ietf.org
Message-ID: <8F5D82447C5F8BC6B50CD983@Ximines.local>
In-Reply-To: <20091105205921.GL17456@shinkuro.com>
References: <20091105205921.GL17456@shinkuro.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2009 19:07:07 -0000
I have read this draft. I do not think it should be adopted in current form. My reason is essentially that this draft appears to be mixing operational and/or technical considerations with matters which are essentially policy which should be determined at the local internet community level. What the authors state is recommended may well be right for one TLD, but not for another. The flaw in the argument starts early on, in my view. Under section 2 > the original IDN TLD and its IDN TLD variant SHOULD be > identical in the DNS resolution. For example, the ".com" is > identical to ".COM" in the DNS resolution. This is not a valid comparison. ".com" is identical to ".COM" because, for historical reasons, the comparison of DNS names is performed in a case insensitive manner. However, ".COM" is not identical to ".C0M" (that's a zero), or ".il" to ".i1" at the protocol comparison level. The fact that two labels appear similar (or even identical) does not *at a technical level* (i.e. in the scope of this working group) mean that there should be an RFC2119 "SHOULD". I quite agree that ICANN should not allocate a TLD to one operator, and a variant of that TLD to anyone but that operator. That is a laudable policy, but probably outside the scope of this group. That doesn't necessarily mean they should allocate variants at all, but if they do, how they are handled should it seems to me not be prescribed here. There must be some situations where the variant is a perfectly acceptable alternate way of expressing the same name, some where the variant is a replacement of a historical artifact, and some where the variant is a "phish" (i.e. something that looks just like the original but isn't). Ways to deal with this would include: 1. do nothing 2. block allocation of variant (but put no records in) 3. Put NS records in root (could point to different servers operated by same operator), operator puts minimal information in (compare '.uk' and '.gb'). 4. Ditto with same servers 5. As per (4), but with DNAME at apex of delegated zone. Some seem to be arguing this is legitimate (though I thought not) 6. As per (5) with same servers 7. As per (5) but (for TLDs with second level domains, e.g. ".uk", put DNAME in for the TLD names, e.g. make com.uk a DNAME of co.uk) 9. Put DNAMEs in at the delegation level 10. Synthesize identical zone files Now I am sure there are technical advantages and disadvantages to each of these. It seems to me these are dependent on the problem one is trying to solve. If the only problem is avoiding phishing, I'd go for (2). If the problem is that half the users write the CCTLD using one unicode character, and half with a different but identical looking one (that appeared to be the implication of the example in section 2), then the problem is quite different. I think it's up to the registry concerned (with local community input) to determine the best policy. Sure, we could have a draft which sets out the various technical advantages and disadvantages of different option, but in current form, this isn't it. See, for example (from s3): > Any policy or technology SHOULD be used to guarantee that the IDN TLD > and its variant SHOULD belong to the same registry; the DNS > administrators SHOULD try their best to make the IDN TLD and its > variants be identical in the DNS resolution. That is far too prescriptive. I should probably declare my hand in that I think in most cases the variant stuff is a non-problem (blocking is adequate apart from where the user is likely to mistype themselves), and that attempting to generate DNS equivalence is a non-solution (because end user software, e.g. HTTP requests for web sites which rely on the domain name in the request) will themselves need to handle every permutation of equivalence. In most cases, the appropriate answer is NXDOMAIN. Whilst I can see that there might be other cases, this seems to me to be an issue for local policy, not DNSOP. -- Alex Bligh
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Eric Brunner-Williams
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… YAO Jiankang
- [DNSOP] draft-yao-dnsop-idntld-implementation-01.… Andrew Sullivan
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… YAO Jiankang
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Andrew Sullivan
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Kim Davies
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Andrew Sullivan
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Alex Bligh
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Alireza Saleh
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Andrew Sullivan
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Alex Bligh
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… James Seng
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Paul Hoffman
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Masataka Ohta
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Todd Glassey
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Edward Lewis
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… YAO Jiankang
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… YAO Jiankang
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… YAO Jiankang
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… YAO Jiankang
- Re: [DNSOP] draft-yao-dnsop-idntld-implementation… Andrew Sullivan