--On Tuesday, July 16, 2013 11:07 -0400 Ofer Inbar
<cos@xxxxxxxxx> wrote:
>...
> What this brings to mind is that we had a DNS system that was
> vulnerable to the addition of something to the DNS that people
> had expected nobody would make the mistake of doing, but it
> happened and caused damage, and the net reacted by altering
> how DNS software works in order to protect against that
> damage. At the time, the obvious defensive change was "don't
> do implicit domain search". If dotless domains cause damage
> as many people here predict, what I'm saying is that I think
> we'll react similarly, and that I guess the defensive change
> people will widely deploy is to reject A/AAAA/MX records at
> the top level.
Two additional observations about this. Ofer's explanation
about the edu.com example and the resultant ban on heuristic
search is consistent with RFC 1535 and what little I remember of
the history. However...
* The RFC 1535 defensive change was far more practical in 1993
than it is today, just because of the size of the Internet, the
number of deployed DNS servers and resolvers, and the
difficulties of deploying "required" upgrades. So the harm
level or likely duration of harm should dotless TLDs be deployed
is greater today or at least less likely to yield quickly to a
defensive change.
* A different example of searching issues caused a good deal of
disruption when it came up (several years earlier than the
EDU.COM. case) and may be relevant to ICANN's current plans and
their likely effects. In that case, a very large number of
computer science departments in universities all over the world
quite reasonably were delegated domains like
CS.university-name.EDU, often resulting in
host1.CS.university.EDU, host2.CS.university.EDU and email
addresses like username@xxxxxxxxxxxxxxxxx. Whether by relying
on the heuristics that RFC 1535 banned or by explicit search,
institutions set up name completion so that a reference from
within that institution to username@CS (or username2@chem or
username3@art -- you get the idea) worked as everyone expected,
yielding username@xxxxxxxxxxxxxxxxx, etc. Usually, host1.CS
did too -- this is not just about "dotless" domains.
Then the TLD for Czechoslovakia was delegated under the
then-assigned ISO 3166 code of CS and unpleasant things started
happening. Users in some institutions couldn't find Czech sites
at all; others had no problems. In some cases in which search
rather than mere completion was used, some names would be found,
some names wouldn't, and false positives become possible. If
there is advice for ICANN in this it is that, when DNS searching
scenarios are involved, it is not sufficient to worry about
possible conflicts between proposed new TLDs and existing
private-use pseudo-TLDs (such as "local.") Instead, conflicts
with existing second or third-level labels (and perhaps ones
even further down the tree) have to be considered if completion
or search configurations involving those labels might give them
the same appearance as a TLD or subdomains of that TLD.
Whether the IAB should have included any of this in its
Statement is, IMO, another matter. My personal bias is that, if
the IAB starts making Statements about the implications of a
technological choice, they should be comprehensive about the
relevant subject. That principle would call for discussion, not
only of the email issues that started this thread, but the "CS."
case and many of the other issues that have been mentioned. On
the other hand, there are arguments against that principle,
especially when a body like ICANN is concerned and there is
reason to believe that any statement more than a paragraph or
two long will be unread by many people in the intended audience.
Personally, I would have preferred it had the IAB been explicit
about what issues they were and were not addressing if they
decided to avoid a comprehensive discussion -- at least then,
people might be debating their choices but not whether they are
exhibiting their ignorance. But that is just my opinion.
john