Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

[Stephane Bortzmeyer <[e-mail]>]

On Wed, Feb 23, 2011 at 11:47:20AM +0000,
 Suzanne Woolf <[e-mail]> wrote 
 a message of 69 lines which said:

> Per the announcement to the list last night, the -00 of the
> "aliases" problem statement has been posted to the i-d repository.

Well, thanks to the authors, it is a very necessary document and I
appreciate that two courageous persons decided to actually work on it.

This being said, I'm not terribly happy with the result. IMHO, such a
document should be used to help people understand the issues before
claiming "We need variants in the DNS" and I'm afraid it is too
complicated at this stage to fill this role. 

More specifically:

The document does not mention clearly that the starting point is a
difference of expectations between normal humans and IETF
members. Normal humans assume that some names are identical
(color.example == colour.example, café.fr == cafe.fr, wells-fargo.com
= wellsfargo.com, ibm.example = IBM.Example, etc) and the DNS does not
deliver what they want. IETF participants know that my last example
works and not the other three but, when you try to explain that to
normal humans, they don't understand and they are right. It should be
stated from the beginning that we simply cannot provide a DNS
behaviour that will be seen by normal users as "natural" and
"unsurprising" (because of the complexity of the rules and their
language-dependant character). So, we should warn users, not try to
create mechanisms that will *always* fall short of their expectations.

Second, the document seems to assume that the problem is mostly, if
not exclusively, an IDN thing. As the examples above (and the examples
of phishing sites) show, this is far from true. In registries which
are still discussing IDN registration (like .FR, see
<http://www.afnic.fr/actu/nouvelles/271/10-february-2011-idn-workshop-organised-by-afnic>),
some people keep telling that IDN are complicated and we should not
allow them because of this complication. But the examples above show
that IDN are not the only issue. It would be better if the document
clearly stated that. (Another french story: in .FR, the law - not the
registry policies - says that city names are reserved to the city
council, and this is done in a dash-independent way: saint-quentin.fr
and saintquentin.fr are therefore part of the same "bundle". Since the
law is only for cities, not for corporations, saint-gobain.fr and
saintgobain.fr are still distinct. Imagine the user confusion!)

The case (pun intended) of case-insensitivity is a complex one. It is
obviously impossible to change the rules now but the document says
several times that the case-insensitive rule is a good one, which is
not obvious. The case-insensitivity rule is not perfect (in French,
Poussin is a painter and poussin a bird) and users legitimally ask
"why case is not important but a stupid dash is?". The document's only
negative remark about case-insensitivity is about its use in
compression (section 2.3.1), which seems to me an useless detail
(because only implementers see it). I suggest to drop this sentence
about compression: the biggest lack of consistency is not in
compression, it is in the fact that DNS is fuzzy on some criteria
(case) and strict in others (dash, spelling).

The document mentions several times (for instance 3.1.1) the perceived
need to be able to distinguish if a name is a member of a bundle. This
need is not explicitely stated in the Proposed Requirments section (4)
and is questionable. What is the rationale for this unstated
requirment? After all, unless you use DNSSEC, I do not think there is
today a way to tell if a name was generated by a wildcard expansion
(if you want to test, tell me if real-name1.office--enregistrement.fr
is real or synthetic).

The section on Applications (3.3) apparently does not mention the fact
that many application protocols (HTTP and SMTP are two obvious
examples) need to be configured to recognize the bundle. (Which is a
strong argument against a new DNS solution, since it will be useless
anyway.)

Technical nit: I find no mention of RFC 3403 which seems a (corner)
case where even a purely DNS solution would be a problem if a rule
uses the original domain name for rewriting.

Editorial nit: the reference to the IDNA standard is now RFC 5890.