Add cloud-ip.biz and ip-dynamic.org for ClouDNS

[boyanpeychev]

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)

ClouDNS is not using this to work around rate-limits of third party services.

• 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

ClouDNS provides free dynamic dns hosting with subdomains.

Organization Website:

https://www.cloudns.net

Reason for PSL Inclusion

We are dynamic dns provider. Each sub-domain name is used by different user. Usually we provide up to 30K sub-delegations per domain.

Number of users this request is being made to serve: up to 30000

DNS Verification

$ dig _psl.cloud-ip.biz txt +short
"https://github.com/publicsuffix/list/pull/2202"

$ dig _psl.ip-dynamic.org txt +short
"https://github.com/publicsuffix/list/pull/2202"

Results of Syntax Checker (make test)

TOTAL: 5
PASS: 5

[wdhdev]

@boyanpeychev Can you please put the PR template back and fill it out, thank you.

[boyanpeychev]

@boyanpeychev Can you please put the PR template back and fill it out, thank you.

Done.

[groundcat]

• Expiration (Note: Must STAY >2y at all times)
  • cloud-ip.biz expires 2027-06-01
  • ip-dynamic.org expires 2027-08-20
• DNS _psl entries (Note: Must STAY in place)
• Tests pass
• Sorting
• Reasoning/Organization description
  • Same requestor as in #1593
• Non-personal email address
  • <[email protected]>

[wdhdev]

@boyanpeychev You have noted that you are looking to get around Cloudflare and Let's Encrypt rate limits, which is not allowed as per our guidelines. (Did you forget to remove them from the template?)

[boyanpeychev]

@boyanpeychev You have noted that you are looking to get around Cloudflare and Let's Encrypt rate limits, which is not allowed as per our guidelines. (Did you forget to remove them from the template?)

Sorry, check by mistake. Fixed.

[wdhdev]

So to confirm, you are not submitting this PR with intentiond to evade Cloudflare and Let's Encrypt restrictions?

[boyanpeychev]

No, we are submitting this PR as all our other domain names, because the end users using the sub-domains want to issue their own SSL certificates.

[simon-friedberger]

(Sorry, misclick.)

Could you please clarify how your users are prevented from getting SSL certificates without a PSL entry?

[boyanpeychev]

From what I know they are unable to make wildcard ssl validations and some services didn't accept them.
As I mentioned, we are providing hostnames to around 30K users per domain name. That never was an questioned before, I believe our first entries here are 7-8 years old.

[wdhdev]

Could it be due to Let's Encrypt rate limits? I've never had issues registering wildcards at the 4th, or even 5th level.

[simon-friedberger]

Okay, this is exactly what we mean by third-party limitations.
And the reason why we ask about them, is that it prevents us from making certain changes to the list if we don't know what people are doing with it.

So please, if you have received complaints from people about not being able to use service X just add service X to the list in the PR template under "We are listing any third-party limits that we seek to work around [...]"

[boyanpeychev]

Well, I was thinking the same, but for some reason two comments above someone told me this is prohibited and I was thinking this is something I have submitted wrong. Updated it.

[simon-friedberger]

Right, this is unfortunately a little confusing. The reason for inclusion must be something other than working around third party limits. So, if you are submitting something because you need separate domains for customers (as you clearly do) that's fine. However, in that case we would still like to know about any third party limits that this is also relevant to.

If you are submitting something only to work around third party limits we ask that you resolve this with the third party directly.

[boyanpeychev]

I still don't understand what is the difference here with our service and AWS for example? Did you ask them to resolve the issue with the third parties? Actually I don't know which are those third parties. You can check back the history with our other domain names. You will get tons of requests after few months for those domain names like the case with cloudns.be about half year ago. Actually the two domain names I'm adding was already in other PR . They was rejected because the requests are not from the owner of the domain names and then I was contacted to make my own PR as an owner. I'm here to help to the community who is using our free services, not to trick someone's limits.

Getting back to the roots of PSL, our domain names which provides free dyndns service are exactly what this list is created for:
"A "public suffix" is one under which Internet users can (or historically could) directly register names. Some examples of public suffixes are .com, .co.uk and pvt.k12.ma.us. The Public Suffix List is a list of all known public suffixes."

Simply everyone who open account in ClouDNS at the moment gets domain from those two for free.

[wdhdev]

@simon-friedberger I think it is fine. They already have other entries on the PSL and it seems they are seeking cookie separation as per their rationale (please confirm this @boyanpeychev). I think they just forgot to remove the part of the template stating they are trying to get around specific limits. They also have specified they are not attempting to get around any limits in their PR template.

[groundcat]

I have a ClouDNS account, which allows me to create subdomains under both cloud-ip.biz and ip-dynamic.org and point these subdomains to specific IP addresses. This aligns with the description in this PR, "dynamic DNS hosting with subdomains," I believe it is a valid reason for PSL inclusion to enable cookie separation for browsers, as I see no reason why ClouDNS would submit this PR solely to bypass third-party limits. Based on historically merged PRs, DDNS services are generally an acceptable use case for PSL inclusion.

[boyanpeychev]

@wdhdev yes cookie separation is also a reason to have our free domain names in this list. Thanks for pointing this!

[groundcat]

From what I know they are unable to make wildcard ssl validations and some services didn't accept them.

@boyanpeychev Slightly off-topic here, but it seems that CAs like Let's Encrypt likely ignore the private section and only use the ICANN section of the PSL. So, for domains in the private section, wildcards are still possible.

According to the Baseline Requirements (latest version):

If using the PSL, a CA SHOULD consult the “ICANN DOMAINS” section only, not the “PRIVATE
DOMAINS” section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which
are listed in the “ICANN DOMAINS” section. A CA is not prohibited from issuing a Wildcard
Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is
demonstrated in an appropriate way.

[simon-friedberger]

@wdhdev I also think it's fine I just wanted to resolve the communication issues. Clearly, they are also getting added because of third-party limits but these are not listed in the PR description now.

From what I know they are unable to make wildcard ssl validations and some services didn't accept them.

Presumably, these are Letsencrypt and Cloudflare, but it would be great to know if there is anything else.

[danderson]

While we're here: another suffix in your block, cloudns.ph, seems to be unavailable. It's currently failing TXT record validation because all authoritative nameservers for that domain are down. Could you please fix it, or remove cloudns.ph from the PSL?

[boyanpeychev]

While we're here: another suffix in your block, cloudns.ph, seems to be unavailable. It's currently failing TXT record validation because all authoritative nameservers for that domain are down. Could you please fix it, or remove cloudns.ph from the PSL?

Name servers are up and running and sub-delegations where working. Fixed the TXT record, thanks!

[simon-friedberger]

@boyanpeychev If you could add a statement that you are working around cloudflare and letsencrypt limits, and whatever else to the initial comment we could merge this.

[boyanpeychev]

@boyanpeychev If you could add a statement that you are working around cloudflare and letsencrypt limits, and whatever else to the initial comment we could merge this.

We have tried to contact the complaining users first to get the whole picture first. Thanks!