Add nebius.com storage domains

[zveznicht]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• 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).

• 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.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 30 days.

Abuse Contact:

• Abuse contact information (email or web form) is available and easily accessible.

  URL where abuse contact or abuse reporting form can be found:
  https://nebius.com/report-abuse

---

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

Nebius is a cloud provider with focus on AI workloads. It provides multiples services like compute, gpu, network infrastructure, managed k8s, object storage and so on. Object Storage specifically is the reason for this inclusion.

I am a lead developer of Nebius Object Storage.

Organization Website:
https://nebius.com/

Reason for PSL Inclusion

Our Object Storage service has S3-compatible API. Which means for every bucket users create we provide a subdomain, like foo.storage.eu-north1.nebius.cloud. Also user uploaded objects can be accessed with path-like scheme: for example storage.eu-north1.nebius.cloud/foo/.... This rises security concerns for our users, as setting cookies to base domain can be abused and affect other clients.
So the main and only reason for this PR is to restrict setting cookies to our storage main domains, as it contains users generated (provided) data.

Number of users this request is being made to serve:
It is hard to determine specific number of users, but right now we have around 5K user buckets in our installations.

DNS Verification

> dig +short TXT _psl.storage.eu-north1.nebius.cloud
"https://github.com/publicsuffix/list/pull/2333"

> dig +short TXT _psl.storage.eu-west1.nebius.cloud
"https://github.com/publicsuffix/list/pull/2333"

[simon-friedberger]

Please figure out a different naming scheme. We currently only support wildcards as the first label and because Amazon got this wrong they require an insane amount of entries. Since you are just setting this up now either make it fit
*.nebius.cloud or something similar.

[zveznicht]

Do I understand correctly that the issue here is the number of records we might require in future if we keep creating new entry for each zone?

As far as I can see there is no way to have wildcard over all subdomains of all levels, right? So *.nebius.cloud won't cover something like storage.eu-north1.nebius.cloud? And the only way for us to both have single entry and have multiple regions is to make inverse scheme like {region}.storage.nebius.cloud

[wdhdev]

You could inverse it, that would be ideal. That way you could use *.storage.nebius.cloud. In the long run for us it would be preferred as it would reduce the amount of entries (to avoid something like Amazon's block, in the event of a huge growth on your service).