Add sslip.io to private list

[cunnie]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _psl TXT record in place in the respective zone(s).

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• This request was not submitted with the objective of working around other third-party limits.

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, and responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms to them.
• The submission follows the guidelines on formatting and sorting.

---

For PRIVATE section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies and cause other issues, and the rollback timing is acceptable. Proceed anyways.

---

Description of Organization

sslip.io is a DNS service that, when queried with a hostname with an embedded IP address, returns that IP address, e.g. 127-0-0-1.sslip.io resolves to 127.0.0.1. This makes sslip.io a private domain that "issues subdomains to mutually-untrusting parties". I certainly don't trust some of these parties — although most sslip.io users are legitimate, a small minority are scammers, hucksters, and grifters, and for those a maintain a blocklist of IP addressesses that don't resolve.

I'm Brian Cunnie, [email protected], and I run sslip.io. I wrote almost all the code, and I maintain the four DNS name servers of sslip.io.

Organization Website: https://sslip.io

Reason for PSL Inclusion

I'd like to be included in the PSL for cookie separation due to each subdomain belonging to a different party. And, like I said earlier, some of these parties are completely untrustworthy.

In the spirit of transparency, know that I have a rate limit increase request open with Let's Encrypt, but they've been very responsive with previous rate limit increases, and is not the reason why I'm requesting being added to the PSL.

Number of users this request is being made to serve:

Tens of thousands of users; it's hard to get an exact number, but I know that the servers respond to 7,000+ DNS queries/second.

DNS Verification

dig +short TXT _psl.sslip.io
"https://github.com/publicsuffix/list/pull/2206"

Results of Syntax Checker (make test)

PASS: libpsl_icu_fuzzer
PASS: libpsl_icu_load_dafsa_fuzzer
PASS: libpsl_icu_load_fuzzer
============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 3
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
Making check in tests
  CC       common.o
  CC       test-is-public-all.o
  CC       test-is-cookie-domain-acceptable.o
  CC       test-is-public.o
  CC       test-is-public-builtin.o
  CC       test-registrable-domain.o
  CCLD     test-is-cookie-domain-acceptable
  CCLD     test-is-public
  CCLD     test-is-public-builtin
  CCLD     test-is-public-all
  CCLD     test-registrable-domain
PASS: test-is-public-builtin
PASS: test-is-public
PASS: test-is-cookie-domain-acceptable
PASS: test-registrable-domain
PASS: test-is-public-all
============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

[wdhdev]

• Expiration (Note: Must STAY >2y at all times)
  • sslip.io expires 2028-08-15
• DNS _psl entries (Note: Must STAY in place)
  • _psl.sslip.io
• Tests pass
• Sorting
• Reasoning/Organization description
• Non-personal email address

---

I noticed in your commit cunnie/sslip.io@0c3c5aa, you are attempting to get around Let's Encrypt rate limits by applying to the PSL. If you are only applying for the sole purpose of evading that limit, we request you resolve it with LE directly. However it should be fine as it seems you are applying for cookie separation due to each subdomain belonging to a different party (please correct me if I'm wrong).

[cunnie]

Wow, @wdhdev , I am impressed with your responsiveness! It was but a draft PR, and you chimed in with a helpful comment! You're my hero!

[wdhdev]

No worries! I've known about your service for a while as it is used by default with the Coolify.io project, so thought I'd just give a early review to save some time, I'm aware everything might not be in order yet as it is a draft PR :)

(Also just an FYI, I'm not a maintainer of the PSL, I'm simply a volunteer)

[groundcat]

Unfortunately, as currently stated in the Non-Acceptance Factors:

We do not accept entries for use as DNS wildcards, such that e.g. 1-2-3-4.foo.tld resolves as IP address 1.2.3.4. This basically projects the security properties of the IP address space onto the domain name space, and we don't feel that is safe. IP addresses can be dynamically allocated to multiple mutually-untrusting parties; domain names generally are not.

That said, a relevant discussion thread remains open at #1349

[simon-friedberger]

The obvious issue with using IP-based domains is that, if an IP gets reassigned to a different user it creates an opportunity for a MitM attack for the previous user who may still have a valid certificate. While this may be unlikely or difficult to control, people place a lot of trust in secure connections and jeopardizing them is unacceptable.

Most similar services which are on the PSL use hashes or randomized hostnames to make them unique per user.

[wdhdev]

ngrok does the same however and they are listed on the PSL. Last time I checked, they use the host's IP address in the hostname.

[simon-friedberger]

The reasoning for not doing it is also explained in this old comment by Ryan: #1349 (comment)
Quote:

You can address this need with myservice.TLD, with the third subordinate label being a unique user identifier (mitigating the cross-user attacks obtaining the same IP), and the fourth subordinate label being the IP. This is, fundamentally, what Plex does, and the eTLD+1 is always {user}.myservice.example

And there is an exception we have been making for organizations which ensure that only their own IP address space is used and who are therefore in a position to control usage and warn users.

ngrok does the same however and they are listed on the PSL. Last time I checked, they use the host's IP address in the hostname.

I don't know ngrok so I cannot immediately speak to that but in their most recent PR they stated:

A domain in that situation would look like 84c5df439d74.ngrok.dev, or 3a5c10d67779.eu.ngrok.io if the agent is configured to use the European region (one of seven regions available).

Note: Personally, I am not such a big fan of hashes or other long randomized identifiers for anything a user might see. It's just an opportunity for social engineering because users will not check them.

[cunnie]

Hey @simon-friedberger @wdhdev @groundcat

I'm closing this PR; based on your thoughtful, timely, and nuanced discussion, I feel that sslip.io doesn't fit the acceptance criteria.

I can't thank you enough for reviewing my PR, and for all the work maintaining the Public Suffix List. You're the unsung heroes of the internet.

I'll check in periodically to see if the acceptance criteria changes, and may re-open the request if that's the case.