Rate limit reached based on the error message, but logs says different

Are we still talking about PSL names?

1 Like

How do you mean?

1 Like

My understanding is that PSL names aren't limited by the 50 certs per domain limit.
But now that I hear myself say that... It doesn't sound right either!
All unique domains should be limited by the 50 new certs per domain per week.
The PSL simply augments our original TLD reality to now include endings that are not TLDs (but they are treated as such).
So what constitutes a unique domain name in that sense?
I'd have to say: One section plus a TLD (or a PSL entry).
So that BLAH.(PSL-entry) would be treated equally just as BLAH.(TLD).
And sub.BLAH.(PSL-entry) would be treated equally just as sub.BLAH.(TLD).
And sub2.sub.BLAH.(PSL-entry) would be treated equally just as sub2.sub.BLAH.(TLD).
Whereas sub2,sub.BLAH.(TLD) isn't given any extra certs per week and is included in the 50 for BLAH.(TLD), I'd have to say that:

Makes it seem like that could get 100/week, but it shouldn't.

That said, how does one handle BLAH.(PSL-entry) when PSL-entry is "*.sub.example.com"?
"BLAH.*.sub.example.com" doesn't seem likely to be what is used for comparison.

I leave you with more questions than answers - LOL

1 Like

The PSL just moves the label for the definition of the domain from which the rate limit is determined.

Without PSL entry:

  • 50 certs per week for example.com

PSL entry example.com:

  • 50 certs per week for foo.example.com
  • 50 certs per week for bar.example.com
  • et c.

PSL entry *.example.com:

  • 50 certs per week for baz.foo.example.com
  • 50 certs per week for bla.foo.example.com
  • 50 certs per week for etc.bar.example.com
  • et c.
6 Likes

I follow that. But, doesn't the Rate Limit Adjustment Request Form allow for more than 50 per "identity". That form asks whether submitter wants the limit increased "per account" or "per domain". I think "per domain" in this context means per PSL entity but in any event it is talking about allowing more than 50.

What am I missing?

3 Likes

I don't think you're really missing anything.

The rate limit adjustment form is, as far as I know, a entirely separate thing from how the rate limits are calculated with use from the PSL as far as I know. I think if you request a rate limit adjustment for cloudera.site, the new rate limits would be applicable for all subdomains of cloudera.site.

But maybe @lestaff can help us understand this a little bit more.

4 Likes

Okay I'll see if I can provide enough info to clear everything up :smiley: Wish me luck!

We usually (barring exceptional circumstances or holidays) release a new version of Boulder to production every week. You can see when we tag a new version of Boulder in its Releases page. Those tags go to Staging, then to Prod, over the couple days after they're signed and published. The latest update to the PSL is included in the most recent release-2021-11-02 tag, so it will most likely be deployed today.

@Osiris's analysis of how the Public Suffix List works in Comment 24 is correct. Adding the wildcard to the entry in the PSL makes it so that every top-level subdomain of the listed domain is treated as though it is on the list directly; i.e. on the PSL, listing "*.cloudera.site" is equivalent to manually listing every possible subdomain of "cloudera.site". Since every top-level subdomain of cloudera.site is on the PSL, every second-level subdomain is subject to the default 50-certs-per-week ratelimit.

Now it gets a little complicated. Entries in the PSL are what are called "eTLD+1"s: "Effective Top Level Domains, Plus One". An eTLD is something that acts like a TLD (i.e. can have arbitrary subdomains registered under it), so things like ".com" or ".co.uk" or, in this case, "cloudera.site". And then an "eTLD+1" is anything under that, like "letsencrypt.org" or, in this case, "a465-9q4k.cloudera.site". Even though that exact string isn't on the PSL, it effectively is, because "*.cloudera.site" is on the PSL.

Our certificates-per-name rate limit is applied at the level of eTLD+1s. That means that our rate limit overrides also operate at that level. So we can add an override for "a465-9q4k.cloudera.site" (and in fact, looking at our internal overrides, we already have). We could add a separate override for "other-example.cloudera.site". We cannot apply a rate limit adjustment for "cloudera.site", because that domain is no longer on the PSL (only "*.cloudera.site" is). And I'm pretty sure we can't apply a rate limit adjustment for "*.cloudera.site", because that would be a little bonkers.

(edit: lmao italics; thanks griffin!)

8 Likes

I think your *s got trimmed there at the end, @aarongable, so you ended up with italics. You can escape them with \.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.