Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

[Alex Bligh <[e-mail]>]

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