Hi. I am one of the authors of (http://www.icann.org/en/groups/ssac/documents/dotless-domain...) this report mentioned in there. Our study included a much broader scope than SAC 053 mentioned in the article. The idea was to take a very broad, holistic, view of the key infrastructure and systems on the Internet and determine the risks dotless names may pose. How would behavior be different with dotless names, etc. Our report basically answers your question, I think, so I won't answer it here :)

How are you actually going to prevent someone from returning an A record? (possibly as part of a targeted attack)

I suspect ICANN are thinking about the long game - if, as a matter of policy, there are no valid dotless domains, then developers of user agent software are unlikely to attempt to resolve them (other than using a search list or hosts file) in the first place.

But current clients all handle single label names via normal DNS resolution.

This is how many office PCs find their file servers. People are not going to give up the habit of using single label names on the LAN just so ICANN can start collecting rent on that namespace.

The IAB put out a statement “Dotless Domains Considered Harmful” that explains some of the risks if ICANN changed the rules to allow them. As it stands, they were already prohibited and this resolution reaffirms that.

http://www.iab.org/documents/correspondence-reports-document...

> As it stands, they were already prohibited and this resolution reaffirms that.

Slight nitpick: they were prohibited only without prior ICANN approval (second whereas). Companies like Google attempted to get that approval (Google wanted "search"), which spurred ICANN into making a decision about what circumstances they would allow them. This decision essentially states ICANN won't approve any dotless domains.

But I thought "* Considered Harmful" was considered harmful?

Presumably to stop someone from registering a new top-level TLD "reports", putting an A record on it, and then your attempt to access an intranet site http://reports/ suddenly going somewhere you didn't expect.

There's also the case when someone is googling "restaurants" and there happened to be a malicious http://restaurants. website.

if your internal systems where set up correctly that would not happen,. your local DNS should override any external records.

If I added an A record for google.com to bing.com's ip address on my internal dns no one would see google.com

Until your user takes the company laptop to the coffee shop.

Or another common scenario.

User takes laptop home and forgets to enable the company VPN.

In some intranets, users might be relying on mDNS (Bonjour) or WINS (SMB/CIFS) name resolution, rather than static DNS; both of those mechanisms, by default, get resolved at lower-priority than DNS (because they're quite slow, so you don't want your computer checking them first every time), so if there's a real DNS entry it'll get used.

mDNS is actually in the list FIRST in at least Ubuntu, check /etc/nsswitch.conf.

Linux's mDNS support is split into two parts--mDNS presence (which uses cached/recently broadcast-announced values), and mDNS resolution (which doesn't.) If you don't have a name cached, the first part won't know about it, so you'll hit DNS lookup before failing back to full mDNS resolution. Basically, it becomes a race condition of when you last brought the machine up.

The SSAC report on dotless domains[0] has information on possible security related risks that might occur for these types of domains.

Additionally, this informational Network Working Group draft has information on the status of existing dotless domains, without expressing an opinion on security or stability[1]

[0] - http://www.icann.org/en/news/public-comment/sac053-dotless-d...

[1] - http://tools.ietf.org/html/draft-hoffine-already-dotless-02

I don't find it necessary for security. One way of safeguarding security across the board is to use reserved words like "intranet" for the intranet (duh) and "localhost" for the same machine. THE END

That alone won't address all of the concerns. Another study they did, related just to their gTLD stuff, was to see which dotless name queries get leaked to the root servers. This name collision report is quite interesting and addresses the question of which names are probably in common use: http://www.icann.org/en/about/staff/security/ssr/name-collis...

Anyhow, our research and testing (I am one of authors of one of the studies mentioned in the posted article) found that the issues found with SAC 053 have the potential to be much more wide spread. There is also a scary problem called universal XSS.

There were no real smoking gun security issues, so you can make a pretty decent argument about the security impact not being too great (we had many such debates internally), but we are talking a core Internet system. The namespace collision issue is huge.

I see what you mean regarding namespace collision, but if we always set a standard based on the lowest common denominator we'll end up being stuck with practices that were followed because there was no reason not to.

As for the universal XSS, this can be solved at the browser and page level. First the gTLD as any other level should be explicitly declared in the script URL from the open page and second the browser blocks all the rest.

Page 7 of the report gets into the details a bit, from what I understand things like localhost where it's assumed that it's internal, and other assumptions made previously with regards to MX records/CAs.