How should we handle "private suffixes"

[simon-friedberger]

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:

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:
john-kurkowski/tldextract#330
#2104

[Tooa]

Should we add internal or *.internal?

What is the sentiment on adding .internal to this list?

Adding .home.arpa had consequences for selfhosters using the DNS in their local network (example). Wonder if it is safe to migrate to .internal instead?

[simon-friedberger]

@Tooa Afaiu the problem with the home.arpa example was that people used home.arpa as a domain not as a suffix, right? Because with myservice.home.arpa everything should work fine.

My current opinion is that we should add .internal. I assume it makes much less of a difference for .internal because many algorithms will treat the last label as the suffix anyway. So tooa.internal will have .internal whether we add it or not, while for home.arpa without an entry it was just .arpa.

[dnsguru]

I have a 'if it ain't broke, don't fiddle with it' attitude generally, and on this one I recommend against changing the status quo PSL-wide on .internal

Because there's no clear way to know if it will break things or not and what they are. Because of the organic nature of one-way propogation that is in place with the PSL, if it breaks stuff, there's no rollback or 'ofuq' lever.

That said, if Mozilla has a strong feeling on this, browsers or other integrators / software can do what they do and make any additions or removals from the PSL after downloading it.

One idea here, that is less all-or-nothing : Mozilla could add it to their own browser version and propogate it to test the affectation first, and let it bake in before we decide for the whole internet.

I suspect it will be less disruptive to browsers and more disruptive to non-browser, existing use cases that are in place. For .internal to be added - because .internal is in wide use due to i* guidance, defaults (MacOS and others use on self-lan for non-browser stuff) and user behaviours (unfortunately, this is not easy to measure because it will be on private networks that data scientists would likely be unable to measure).

[dveditz]

Shouldn't we handle .internal the way we handle the domains reserved by rfc2606/rfc6761 (e.g. .example, .test, .invalid)? Those are not in the PSL itself, but in some cases browsers choose to treat them as TLDs. I'm a bit surprised "internal." is not included in https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml which is supposed to help people find things like this.

In talking about the ".home.arpa" issue Simon said "None of this is registrable because it is for internal use only", but that's only true in theory. In practice https://1.6.0.0.8.0.0.b.e.d.0.a.2.ip6.arpa/about is a live website. This isn't something the PSL needs to worry about: it falls squarely in "play stupid games, win stupid prizes" territory. The hacker space that owns the domain is aware and perfectly fine with that.

[peterthomassen]

I don't think .internal has any relation to a public suffix, so should not be included.

[simon-friedberger]

I don't think .internal has any relation to a public suffix, so should not be included.

Is this just based on the fact that it is not "public" in the sense that it is intended for private networks?

[peterthomassen]

Yes.

I do understand that certain browsers may want to treat .internal like they treat public suffixes, but that does not make it a public suffix. .internal being on it would be very surprising to anyone who has not followed the discussion, because its presence is incompatible with the name of the PSL.

(Food for thought: What would be a good alternative name for this list if things like .internal were included? I.e., how would the category of suffixes the includes public suffixes and things like .internal be called? Do we want to the PSL to represent this category, and why? -- As long as all of these things are unclear, it seems to be me that it's better to stick to the policy implied by the name, and not include .internal.)

[dnsguru]

(Food for thought: What would be a good alternative name for this list if things like .internal were included? I.e., how would the category of suffixes the includes public suffixes and things like .internal be called?

"Suffix List". ;)

[simon-friedberger]

I think people who want to determine if a string is a URL using the PSL would want .internal included. And they would want the algorithm to return "none" instead of the last label when no matching label is found.

[dveditz]

That was my argument for .example and .test in #1537 and I was shot down. See also #2, #209, and pr #1515 where others made the same request.

.internal should be treated the same as those (either way; I care more about consistency than the decision)

[peterthomassen]

And they would want the algorithm to return "none" instead of the last label when no matching label is found.

If I'm not mistaken, this is essentially replicating the DNS root zone, which I'm not in favor of to do here.