If it is a public dynamic DNS provider, the provider should try to list on the public suffix list (https://www.publicsuffix.org/). Other dynamic DNS providers have done so already.
dedyn.io already is on the Public Suffix List, so subdomains don’t count. For dedyn.io itself, as I said, the last certificate was requested in February.
Any other ideas why I can’t request a new one? In my opinion, this should not happen.
I suspect this may be a bug in the rate limiting code in Boulder, and how it interacts with public suffixes. If dedyn.io is on the public suffix list, that means each subdomain gets its own rate limiting bucket. For instance:
Unfortunately, the code that implements this makes an assumption that no rate limit bucket is a subdomain of another rate limited bucket. Specifically CountCertificatesByName “counts, for each input domain, the number of certificates issued in the given time range for that domain and its subdomains.” In this case, that gives the wrong answer for dedyn.io, since there are a large number of certificates issued for subdomains of dedyn.io.
I’ll file an issue and get it fixed. In the meantime, a partial workaround would be to issue a certificate with all of those FQDNs except the exact “dedyn.io” one. I realize that’s unsatisfactory, but it looks like https://dedyn.io isn’t currently serving a valid certificate, so it wouldn’t be much worse than the situation today.
Good news! The rate limiting bug you encountered here has been fixed in production. You shouldn’t encounter this problem for the dedyn.io domain going forward.
Apologies on the long turn around time for this! We had a few unrelated incidents occur that delayed this being activated in production. I appreciate your patience