SAC053: recommendation not sufficiently backed by report's observations and findings
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.