SAC053: recommendation not sufficiently backed by report's observations and findings

[Peter Koch <pk@xxxxxxx>]

First, I cannot but congratulate SSAC for socializing the term
'dotless domain' approaching the end of a campaign that with neither 
hesitance nor regret has been using the 'leading dot' as genuine part of a
TLD name.  The consistent lack of technically correct language may
indeed be indicative of the nature of the problem.

The report SAC053 could be more elaborate and precise in delivering 
the background.  Contrary to the text in section 2, the 'trailing dot' 
may be used to explicitly mark a domain name as 'fully qualified' (borrowing
syntax applied to DNS zone files, that an enduser rarely ever
gets exposed to), but is not part of the name.  So, "www.icann.org"
of course _is_ a fully qualified domain name - proper context provided.

The report notably finishes without ever mentioning RFC 1535 "A Security 
Problem and Proposed Correction With Widely Deployed DNS Software", 
an important specification of and recommendation for the handling of DNS 
search paths.

When looking at applications, which are at the core of handling (to
avoid the phrase 'interpreting') the names and deciding whether they
are to be subjected to search path expansion, the report focuses
on "the web".  In looking at email, references go to predecessors of
the most recent applicable standards, RFC 5321 and RFC 5322.

The report correctly identifies the handling of names as only partly being
a DNS and more of an applications issue, where applications traditionally
elude standardization.

  Recommendation: Dotless domains will not be universally reachable and the 
   SSAC recommends strongly against their use. As a result, the SSAC also 
   recommends that the use of DNS resource records such as A, AAAA, and MX 
   in the apex of a Top- Level Domain (TLD) be contractually prohibited where 
   appropriate and strongly discouraged in all cases.

The recommendation is unclear in using the "such as" clause and thus not
giving an exhaustive list, either positive or negative, of RR types that
should be "prohibited" (or "allowed", respectively).  
Also, RRs like SRV, while logically applying to the TLD zone apex, are 
physically placed further down the tree.  On the other hand, future
applications that might be unambiguous about the FQDN nature of their
input, would be unnecessarily constrained.

I am not convinced that, based on the reasoning provided in the report, an
outright prohibition of certain RR types is necessary or sufficient to
alleviate the problem of unmet user expectations.  It appears more important
to me to have applicants sign a waiver of any cure or "fix" for certain
application scenarios that already have proven not to universally work.
Especially, there is no (IETF) standard to reasonably change to "make dotless
domains work". And, ceterum censeo, changing Internet standards does not fall 
into ICANN's remit.

-Peter Koch

Disclaimer: These comments are provided solely in personal capacity and do
 not necessarily reflect the views of any organisation the submitter is
 affiliated with or employed by.