@schoen, it is.
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:
FQDN | Rate limit bucket
www.foo.dedyn.io | foo.dedyn.io
foo.dedyn.io | foo.dedyn.io
www.bar.dedyn.io | bar.dedyn.io
dedyn.io | dedyn.io
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.
Thanks for flagging this issue!