ICANN bans dotless domains | Hacker News Reader

ICANN bans dotless domains

icann.org

89 pointsitafroma56 comments

An XSS vulnerability on a dotless domain can lead to XSS on the entire tld. See top level universal XSS[1]

[1]https://superevr.com/blog/2012/top-level-universal-xss/

Here's the best part -- these websites are built terribly and are very open to this sort of thing.

After about 2 minutes of looking, I've just found that nic.io (or just io.) basically lets you type arbitrary html into the search boxes. Chrome's built in XSS auditor catches any scripts you put in there, but (at least) Firefox doesn't.

Check it out:

http://io./cgi-bin/whois?query=%3Ca%20href=%22%22%3E%3Cu%3EA...

If you load it in Firefox (or any browser without an XSS auditor) it'll pop an alert, otherwise you'll just see the image I loaded and a link I inserted.

This is ridiculous.

I attempted to notify them of this, but their contact form validator rejects anything I put into it. The whole site is a mess.

Contact the ccTLD compliance (!!) team at ICANN; http://www.icann.org/en/resources/compliance/cctld

Thanks for the link.

According to the article, the problem is local to Internet Explorer though.

Essentially, if "intranet" mode is enabled and a website is hosted locally, IE will ignore browser same-origin policy. So a script from http://networkmachine can access all your cookies.

IE hate is very outdated, but the fact that a website hosted locally can have access to all the data the browser stores is mind-boggling. A nondescript dialog is all that stands to protect users.

And that's why we have http://publicsuffix.org/

Whereas, that was long and detailed, I am still not entirely sure what security and stability risks it is supposed to address.

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...

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

> 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.

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.

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

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.

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.

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

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

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.

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.

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.

Poor Anguilla - http://ai./

WTF! So "ai" is a sub domain of nothing!?

DNS root domains have no names. That makes http://ai/ a fully qualified domain name. But apparently ICANN has now banned such things. Gods know why. My eyes glazed over after the 10th "whereas". That document reads like a legal document. Ugh

> That document reads like a legal document.

That's because it is.

http://news.ycombinator.com./

A trailing period just represents the top of the domain hierarchy. http://reddit.com./ will work just fine.

news.ycombinator.com is actually news.ycombinator.com. with a period at the end. http://ai./ is basically the same as http://com./, except that com doesn't have any IPs configured.

But as far as TLS name matching goes, it's different. Can something with the dot at the end have a different IP?

Nope. If you don't have a "com" domain at your local network, "example.com" and "example.com." point to the same machine.

The TLS domain is matched by the web server, it has no relation to DNS, except that both use the same domains.

> Can something with the dot at the end have a different IP?

I guess or maybe you can do a hostname match. However, I remember back in the days Microsoft used to use http://microsoft.com. as their test site. Now it just yields an error.

That's because Microsoft uses hostname-based virtual hosting in IIS, and IIS happens to not recognize HTTP Host headers with trailing dots. This has nothing to do with IP addressing or DNS. In the absence of a resolver search list — which conventionally only applies to names without trailing dot — "microsoft.com" and "microsoft.com." result in the same DNS query, and therefore the same set of IP addresses.

Whether this behavior is an obscure bug, a security feature, or both, is left as an exercise.

FQDNs have periods at the end. It's just convention that dictates they're not included.

Vatican City (http://www.va/) used to have MX records pointing at va directly (so, pope@va or whatever)

Ukraine (.ua) has an MX record on the TLD. So user@ua is a valid address.

If that's his email it must be irritating getting all the old popes mail.

Edit: Delivery to the following recipient failed permanently:

    pope@va

So did .ai., at least for certain people (or maybe it was just the A record, but A records are enough for mail deliverability in the absence of an MX). I had one, back when I lived next to the .ai. registrar on Anguilla and shared his (very expensive) T1 via 10base2 ethernet.

As far as I can tell they still do:

va. 3600 IN MX 100 raphaelmx3.posta.va. va. 3600 IN MX 10 raphaelmx1.posta.va. va. 3600 IN MX 10 raphaelmx2.posta.va.

Awesome, so when can SSL certs be valid signers for all subdomains now that it can't be abused at the level of tld?

Do you mean like a wildcard certificate? http://en.wikipedia.org/wiki/Wildcard_certificate

Wildcard certificates are only valid for the subdomain level directly under it. [1] If I get a wildcard certificate for example.com (the common name is set to *.example.com), foo.bar.example.com will throw an error.

[1] https://en.wikipedia.org/wiki/Wildcard_certificate#Limitatio...

The specification isn't particularly clear, but it seems to me that RFC 2818 section 3.1 [1] could permit some dangerously broad wildcards like ".com", "www..com", or even ".". Combined with subject alternate names, it may be possible to create a certificate that's valid for almost anything.

[1]: http://tools.ietf.org/html/rfc2818#section-3.1

IIRC, top-level and "match all" wildcard certificates were originally permitted by design (e.g., for intranet and proxy applications), but most modern browsers block them for security reasons.

You may find this interesting: http://www.digicert.com/internal-names.htm (sunsetting of internal name certificates)

Why so many "Whereas" ?

It's legalese for establishment.

I miss having r@ai although it did also cause problems at MIT (due to people using stuff like rstallman@ai[.mit.edu.]

The best address ever was n@ai which was Ian Goldberg (nai, ian).

This contrasts strangely with gTLDs. I feel like it defeats their entire purpose if you need to use a subdomain of them.

As an example, Google wanted some of their applications to be dotless, eg. Http://search and http://app. http://m.techcrunch.com/2013/04/10/google-wants-to-operate-s...

Don't all domains have a dot at the end? Even io is properly io. with a dot.

Reply on news.ycombinator.com