How should we handle "private suffixes"

[simon-friedberger]

This was prompted by discussions in https://github.com/publicsuffix/list/pull/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:

1. "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.
2. "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.
3. "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 3405 RFC 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).

[wdhdev]

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.

[simon-friedberger]

@mozfreddyb I hope I am not misrepresenting it but I believe your comment was

Should we add internal or *.internal?

[simon-friedberger]

Moving over the see also-s: https://github.com/john-kurkowski/tldextract/issues/330 https://github.com/publicsuffix/list/pull/2104