Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should we handle "private suffixes" #2235

Open
simon-friedberger opened this issue Oct 24, 2024 · 3 comments
Open

How should we handle "private suffixes" #2235

simon-friedberger opened this issue Oct 24, 2024 · 3 comments

Comments

@simon-friedberger
Copy link
Contributor

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
Copy link
Contributor

wdhdev commented Oct 29, 2024

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
Copy link
Contributor Author

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

Should we add internal or *.internal?

@simon-friedberger
Copy link
Contributor Author

Moving over the see also-s:
john-kurkowski/tldextract#330
#2104

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants