You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As @dnsguru correctly points out there is a bit of a category error if we add .internal to the public suffix list since it is not a public suffix but quite the opposite, it is for internal use only. The same applies to .home.arpa but since .arpa is on the list for all the tests that I know of not having .home.arpa makes things worse.
Specifically:
"Is X a valid (public) URL?" anything.home.arpa will be accepted either way. home.arpa would currently be considered valid even though it is a suffix and should not be.
"Is X a registrable domain/eTLD+1?"
None of this is registrable because it is for internal use only but because .arpa is already on the list home.arpa will be considered registrable. If we add .home.arpa the error stays essentially the same but now for anything.home.arpa.
"Is X the same site as Y?"
As it stands printer.home.arpa and nas.home.arpa are considered to be the same site (home.arpa) meaning your session cookies may be overwritten and the browser won't know which password to autofill.
On the other hand, we could consider that the correct solution would be to remove .arpa entirely.
Since .arpa currently only has
Domain
Description
arpa
Reserved exclusively to support operationally-critical infrastructural identifier spaces as advised by the Internet Architecture Board RFC 3172
e164.arpa
For mapping E.164 numbers to Internet URIs RFC 6116
in-addr.arpa
For mapping IPv4 addresses to Internet domain names RFC 1035
ip6.arpa
For mapping IPv6 addresses to Internet domain names RFC 3152
iris.arpa
For locating Internet Registry Information Services RFC 4698
uri.arpa
For resolving Uniform Resource Identifiers according to the Dynamic Delegation Discovery System RFC 3405RFC 8958
urn.arpa
For resolving Uniform Resource Names according to the Dynamic Delegation Discovery System RFC 3405
it is not obvious that there are any actual public suffixes here. (N.B. This seems to be incomplete according to https://www.iana.org/domains/arpa)
Or even more heavy-handed, we might introduce a new sublist // ===BEGIN LOCAL DOMAINS=== or something similar to give people an option to specify "Yes, this is a suffix, but not a public one."
One reason not to have such domains on the list at all, is that they fundamentally behave strangely compared to other URLs. Since people regularly switch networks anything associated with printer.internal is often an error. Additionally, .internal was only recently reserved and many people also use .local. The internal DNS is not visible to anyone so administrators can choose a made up TLD like .companyname or something that works publicly. And something that works publicly could be something they control like .companyname.com or (horrible) something they do not even control like newyork.office.com (this was a recent fritz.box incident).
The text was updated successfully, but these errors were encountered:
I personally think it's worth including these domains on the PSL, even if they are for internal use only, as it is still good for cookie separation as you mentioned.
This was prompted by discussions in #2220.
As @dnsguru correctly points out there is a bit of a category error if we add
.internal
to the public suffix list since it is not a public suffix but quite the opposite, it is for internal use only. The same applies to.home.arpa
but since.arpa
is on the list for all the tests that I know of not having.home.arpa
makes things worse.Specifically:
anything.home.arpa
will be accepted either way.home.arpa
would currently be considered valid even though it is a suffix and should not be.None of this is registrable because it is for internal use only but because
.arpa
is already on the listhome.arpa
will be considered registrable. If we add.home.arpa
the error stays essentially the same but now foranything.home.arpa
.As it stands
printer.home.arpa
andnas.home.arpa
are considered to be the same site (home.arpa
) meaning your session cookies may be overwritten and the browser won't know which password to autofill.On the other hand, we could consider that the correct solution would be to remove
.arpa
entirely.Since
.arpa
currently only hasspaces as advised by the Internet Architecture Board
RFC 3172
RFC 6116
RFC 1035
RFC 3152
RFC 4698
RFC 3405 RFC 8958
RFC 3405
it is not obvious that there are any actual public suffixes here. (N.B. This seems to be incomplete according to https://www.iana.org/domains/arpa)
Or even more heavy-handed, we might introduce a new sublist
// ===BEGIN LOCAL DOMAINS===
or something similar to give people an option to specify "Yes, this is a suffix, but not a public one."One reason not to have such domains on the list at all, is that they fundamentally behave strangely compared to other URLs. Since people regularly switch networks anything associated with
printer.internal
is often an error. Additionally,.internal
was only recently reserved and many people also use.local
. The internal DNS is not visible to anyone so administrators can choose a made up TLD like.companyname
or something that works publicly. And something that works publicly could be something they control like.companyname.com
or (horrible) something they do not even control likenewyork.office.com
(this was a recentfritz.box
incident).The text was updated successfully, but these errors were encountered: