On ICANN and the glut of new gTLDs

[Ryan Sleevi]

TL;DR: 

- Are there concerns with making 127.0.53.53 a special (reserved) IP, that Chromium handles differently and redirects the user to a detailed network error page warning them of impending doom?

Context:

As some may or may not know, ICANN has let lose the floodgates of new gTLDs. There's somewhere between 10-20 being approved every week, and hundreds-to-thousands waiting to be approved.

One of the issues that ICANN is facing is the possible collision of names with suffixes that network operators were, effectively, "squatting" on, because they weren't delegated by IANA. For example, domain.home or or intranet.corp are two common examples in wide use (a number of home routers use .home, and .corp has been widespread enough that even large software vendors, like Microsoft, were recommending it for years)

As these new names come up, ICANN is (rightfully) worried about collisions with local networks. They've even put together a nice paper on it (with tons of technical detail) - https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf

One of the proposals from ICANN is, when delegating a new gTLD, to have that gTLD (and all bits) resolve to 127.0.53.53. If you notice, this is part of the IANA-reserved 127/8 loopback address, so it's the same as "localhost", with 53 being the UDP port DNS is over. The address is chosen to make it easier to search for when people see problems.

To help ICANN in this - which is to say, to help the users who have been squatting on DNS names that may find themselves broken by new gTLDs - what's are peoples reactions to adding logic in Chrome reflecting the ICANN policy?

This would be something like:

Adding support to the DNS resolution flow that if it picks up that it resolved to 127.0.53.53, redirect the user to an error page / help article?

Adding net-dev because of the obvious net impact, but security-dev is likely also interested in the security aspects of these collisions (while .corp and .home are being suggested to become RFC1918-reserved, since they're defacto standards, other names, like mail.host, might soon become attacker controlled and with valid certs)

[Chris Bentzel]

Seems reasonable for us to support if this gets adopted - not sure how
we would explain the issue in an intelligible-by-the-general-public
way though. Is there an IPv6 equivalent address being used as well for
AAAA resolutions? Are they looking for browser vendors to signal a
vote of confidence here?

There's other possible corner cases to consider, especially with
built-in resolver. For example, if the local configuration uses search
suffixes, would we try to continue discovering with those if the
global DNS namespace returns 127.0.53.53? I think we might need
something like so intranet name resolutions would trump global
resolution if no results are returned.

Also: would we escape the URL loading sequence as early as possible if
the special IP address is returned, or would we try to fetch content
at the 127.0.53.53 address and only display the error page if it
fails? This would still allow enterprises to do their own custom error
page, and is not much different than typo-squatting services in terms
of security risk.

[Ryan Sleevi]

Not that I recall.

> Are they looking for browser vendors to signal a
> vote of confidence here?

Yeah, basically. The report mentioned earlier spells out a number of problems identified through the study and comment. The recommendation is for new gTLDs to have a cooling off period where they go into this no-mans-land, in the hope of signalling at least some of the (unknown quantify of) affected users.

Note that there is already a cooling off period baked in, in order to allow CAs to begin revoking such certificates (as, unfortunately, CAs believed such non-assigned names could be validated to the level of assigned names). Rather than having nothing resolve, the proposal is to take advantage of this window and actively 'break' things, with ISVs helping users be alerted, and admins being able to query/analyze logs.

>
> There's other possible corner cases to consider, especially with
> built-in resolver. For example, if the local configuration uses search
> suffixes, would we try to continue discovering with those if the
> global DNS namespace returns 127.0.53.53? I think we might need
> something like so intranet name resolutions would trump global
> resolution if no results are returned.
>

I don't think we should. The report actually covers this, as its part of why the problem exists to begin with.

> Also: would we escape the URL loading sequence as early as possible if
> the special IP address is returned, or would we try to fetch content
> at the 127.0.53.53 address and only display the error page if it
> fails? This would still allow enterprises to do their own custom error
> page, and is not much different than typo-squatting services in terms
> of security risk.
>

I would think the moment we pick it up from the resolver, we begin diverting the response. I'm not sure how you imagine enterprises customizing this, since it redirects to the loopback. Users would have to be running web servers on port 80 for that to work, and that seems extremely unlikely.

For the sake of consistency, my thought is that our connect jobs would abort with a new Net error code, and all the places we are (unfortunately) doing manual DNS resolution and connection logic would similarly be updated.

But I think the TCPConnectJob / StreamSocket::Connect are the most likely places work this in.

I don't have a good answer for the UDP case (QUIC, WebRTC), other than, similarly, "fail with special error code"

[Chris Bentzel]

Read the document and looked like they didn't have an answer for this yet.

This was a mistake on my part - for some reason I was thinking RFC1918
style address rather than loopback.

[Eric]

BTW I am exploring some implementation options for this:

https://code.google.com/p/chromium/issues/detail?id=431085

[Eric]

Oops wrong URL!

... Should be: https://code.google.com/p/chromium/issues/detail?id=470704