Currently, our non-authoritative redis rate limits are logging a lot of errors that look like this:
[AUDIT] constructing rate limit transaction for CertificatesPerFQDNSet rate limit: invalid domain, "www.gitlab.gitlab.git.gitlab.git.gitlab.gitlab.pro.example.com" must be formatted 'fqdnSet': Domain name has more than 10 labels
The fact that it logged this error means that, when we make the redis rate limits authoritative, similar requests will error out and return an error (maybe even a 500?) related to rate limit key construction. This is a problem for 2 reasons:
- This definitely shouldn't be a 500, but most errors coming from checking rate limits (other than rate limit rejections, of course) should be 500s
- The error returned to the user shouldn't have anything to do with rate limits, it should just say that the domain name is too long
Basically, all of the normal sanity checks (are the domain names too long, are there too many domain names, do the domain names end in recognzied TLDs, etc) need to happen before we construct rate limit keys. This happened naturally in the old rate limits system, when limits weren't checked until fairly deep in the RA. It may require some refactoring to ensure it happens with the new redis rate limits.
Currently, our non-authoritative redis rate limits are logging a lot of errors that look like this:
The fact that it logged this error means that, when we make the redis rate limits authoritative, similar requests will error out and return an error (maybe even a 500?) related to rate limit key construction. This is a problem for 2 reasons:
Basically, all of the normal sanity checks (are the domain names too long, are there too many domain names, do the domain names end in recognzied TLDs, etc) need to happen before we construct rate limit keys. This happened naturally in the old rate limits system, when limits weren't checked until fairly deep in the RA. It may require some refactoring to ensure it happens with the new redis rate limits.