add mittwald product domains

[ins0]

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 pr will not aim to workaround any rate limitations

• 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

Organization Website:
https://www.mittwald.de

Mittwald.de is a web hosting company in Germany and provides a wide range of hosting solutions
and domain registration services.

We're providing tools that support efficient website management and development workflows
for our customers, this requires various pre-configured subdomains (mittwald named and whitelabel domains)
for easy access and configuration of our products without the need for our customers to purchase a domain first.

My name is Marco Rieger, and I work as a Software Engineer here at mittwald and acting on behalf of the Security team of mittwald which I'm also part of.

Reason for PSL Inclusion

Examples for simplification only based on webspaceconfig.de

Customers will be provided with default subdomains for their purchased products. This follows the pattern p[id].webspaceconfig.de additionally customers will be provided with custom subdomains based on their
installed managed applications eg. [appId].p[id].webspaceconfig.de.

By being included in the PSL, mittwald ensures that cookies are correctly scoped to their domains, preventing potential security risks such as cross-domain cookie sharing.

Number of users this request is being made to serve:

• The affected domains listed in this PR will affect approximately ~300k customers instances.

DNS Verification

sh-3.2$ dig +short TXT _psl.mydbserver.com 
"https://github.com/publicsuffix/list/pull/2171"

sh-3.2$ dig +short TXT _psl.webspaceconfig.de 
"https://github.com/publicsuffix/list/pull/2171"

sh-3.2$ dig +short TXT _psl.mittwald.info
"https://github.com/publicsuffix/list/pull/2171"

sh-3.2$ dig +short TXT _psl.mittwaldserver.info
"https://github.com/publicsuffix/list/pull/2171"

sh-3.2$ dig +short TXT _psl.typo3server.info
"https://github.com/publicsuffix/list/pull/2171"

sh-3.2$ dig +short TXT _psl.project.space
"https://github.com/publicsuffix/list/pull/2171"

Results of Syntax Checker (make test)

Making clean in po
Making clean in include
Making clean in src
rm -f ./so_locations
Making clean in tools
 rm -f psl
Making clean in fuzz
 rm -f libpsl_icu_fuzzer libpsl_icu_load_fuzzer libpsl_icu_load_dafsa_fuzzer
Making clean in tests
 rm -f test-is-public test-is-public-all test-is-cookie-domain-acceptable test-is-public-builtin test-registrable-domain
Making clean in msvc
Making check in po
Making check in include
Making check in src
  CC       libpsl_la-psl.lo
  CC       libpsl_la-lookup_string_in_fixed_set.lo
  CCLD     libpsl.la
Making check in tools
  CC       psl.o
  CCLD     psl
Making check in fuzz
  CC       libpsl_fuzzer.o
  CC       main.o
  CC       libpsl_load_dafsa_fuzzer.o
  CC       libpsl_load_fuzzer.o
  CCLD     libpsl_icu_fuzzer
  CCLD     libpsl_icu_load_fuzzer
  CCLD     libpsl_icu_load_dafsa_fuzzer
PASS: libpsl_icu_load_dafsa_fuzzer
PASS: libpsl_icu_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       test-is-public.o
  CC       common.o
  CC       test-is-public-all.o
  CC       test-is-cookie-domain-acceptable.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-all
  CCLD     test-is-public-builtin
  CCLD     test-registrable-domain
PASS: test-is-public
PASS: test-is-cookie-domain-acceptable
PASS: test-is-public-all
PASS: test-is-public-builtin
PASS: test-registrable-domain
============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
Making check in msvc

[wdhdev]

• Expiration (Note: Must STAY >2y at all times)
  • mydbserver.com expires 2027-02-13
  • webspaceconfig.de expiry is not reported by registry
  • mittwald.info expires 2027-10-24
  • mittwaldserver.info expires 2027-07-10
  • typo3server.info expires 2027-08-18
  • project.space expires 2026-10-26
• DNS _psl entries (Note: Must STAY in place)
  • _psl.mydbserver.com
  • _psl.webspaceconfig.de
  • _psl.mittwald.info
  • _psl.mittwaldserver.info
  • _psl.typo3server.info
  • _psl.project.space
• Tests pass
• Sorting
• Reasoning/Organization description
• Non-personal email address

[ins0]

@wdhdev were renewed the domains, please note that .de tld don't have this option (https://kb.centralnicreseller.com/domains/tlds/de) thus the reason why no expiration date is reported.

Is there a difference when excluding the asterik in the domains?

[wdhdev]

@wdhdev were renewed the domains, please note that .de tld don't have this option (kb.centralnicreseller.com/domains/tlds/de) thus the reason why no expiration date is reported.

All good, I've excluded that domain from that requirement. All of the other domains seem to be renewed >2y, so this PR is ready to be merged.

Is there a difference when excluding the asterik in the domains?

If you have an entry without an asterisk, for example mydomain.com, mydomain.com is normally treated as a TLD (like .com, .net, etc.), so subdomain.mydomain.com would become almost as if it was a "root" domain name. However if you have an asterisk in your entry like *.mydomain.com, subdomains at the 3rd level (e.g. subdomain.mydomain.com, othersub.mydomain.com) become treated as TLDs, so a subdomain at the 4th level (e.g. test.example.mydomain.com) is then treated as if it were a "root" domain.

My advice is if you are only issuing subdomains at the 3rd level (e.g. 1234asdf.mydbserver.com), remove the asterisk as then 1234asdf.mydbserver.com would be treated as a TLD, instead of it's own domain. If you are issuing subdomains at the 4th level for users (e.g. user1.us.mydbserver.com, user2.uk.mydbserver.com) and not at the 3rd level, then keep the asterisk.

[ins0]

Ok looks good then and we're ready to go. Thanks @wdhdev @groundcat

[wdhdev]

@ins0 To confirm, you no longer want wildcard entries?

[ins0]

@wdhdev no since we're creating subdomains at the third level p123.webspaceconfig.de and down to the 4th appName.p123.webspaceconfig.de like u suggests the version without the wildcard should be correct