Most hostnames that aren't valid IPv4 addresses, but end in numbers are treated as valid, and looked up via DNS (e.g., http://foo.127.1/). Per the Public Suffix List spec, the eTLD+1 of the hostname in that URL should be "127.1". If that is ever fed back into a URLs, "http://127.1/" is mapped to "http://127.0.0.1/" by the URL spec, which seems potentially dangerous. "127.0.0.0.1" could also potentially be used to confuse users. We want to reject URLs with these hostnames.

Motivation

Most hostnames that aren't valid IPv4 addresses, but end in numbers are treated as valid, and looked up via DNS. Example hostnames: 127.0.0.0.1, foo.0.1, 10.0.0.09, 08.1.2.3. These can be problematic for the following reason: * "http://foo.127.1/" has an eTLD+1 of "127.1", per the public suffix list spec. If that's ever used as the hostname in a new URL, however, as in "http://127.1", it will then get mapped to "http://127.0.0.1/", which is a different host, which is not safe. * "http://127.0.0.0.1" and "http://1.2.3.09", both of which are looked up via DNS rather than failing or being treated as IPv4 hostnames, also seem potentially confusing. While no exploit is currently known here, we want to remove support for these as a preventative security measure. The URL spec has been updated so that any URL with a hostname ending in a number that's not an IPv4 address (including, e.g., http://foo.1./, but not http://foo.1../) is considered invalid. Since this is part of the URL spec, not the DNS spec, we want to reject these URLs are the GURL layer, for URLs with appropriate protocols (http, https, ws, wss, file). For consistency, we should also fail DNS lookup attempts of these sorts of hostnames.

Documentation

Specification

Specification link


Unknown standards status - check spec link for status

Status in Chromium

Internals>Network>DNS


Removed (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

Owner

Last updated on 2021-09-22