Ratelimit for dyndns domain


#1

I am getting the following error when trying to get a certificate for my whitelisted dyndns domain xxxxx.no-ip.biz:

Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: no-ip.biz

I am sure that the rate limit applies as the chances of 6 people having certificates for their *.no-ip.biz domains is pretty high, and most probably not a sign of misuse…

So could you lessen the rate limit for dyndns domains, maybe starting with no-ip.biz? That would help;-)

Thanks for the great service and hope you can help.

Best,
Steffen


How to get allong with dnyDNS services
Certificates for many user-controlled subdomains
#2

Let’s Encrypt uses the public suffix list to resolve TLDs for rate limiting. Dynamic DNS providers can request to be added to this list. See the following link for more details.


#3

I the list (https://publicsuffix.org/learn/) is also used for blocking cookies in Firefox/Chrome so there is an good reson that companys do not like to be on the list.


#4

apparently noip does not want to be on this list (see tlussnig’s reply), so there really would be only one way for me to resolve the issue: letsencrypt would have to whitelist the no-ip.biz domain.

The real question is: is letsencrypt willing to do so?


#5

similar for http://freedns.afraid.org/ domains such as mooo.com


#6

And homenet.org (also from freedns.afraid.org).
Current situation:

There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: homenet.org


#7

No-IP has requested to be added here, so this should be solved soon enough. I don’t believe Let’s Encrypt should implement a separate whitelist for this use-case when there’s already an established process.

I imagine dynamic DNS providers which do not wish to get added for whatever reason won’t do too well in a market with plenty of free alternatives once TLS becomes de-facto mandatory, so this should be just a matter of time.


#8

As of today no-ip seems to work, or at least I got a certificate today :grin:


#9

Still not on the list though:

curl -s https://publicsuffix.org/list/public_suffix_list.dat | grep no-ip
shows no result.


#10

noip.me is not on the public_suffix_list.dat as of 2015-12-11 12:44PM.

And LetsEncrypt does show the following:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: noip.me


#12

Remember that the “certs per domain” rate limit is 5 / 7 days, so as those 7 days expire, more certificates can be issued.


#13

Good to know!

Is that with or without being on the public_suffix_list.dat?


#14

How does that apply to renewals? Is there a risk that someone who has a valid cert for one subdomain could find themselves unable to renew it because people requesting new certs for other subdomains have beaten them to it?


#15

Yep, this applies to renewals as well (which isn’t really different from a “normal” certificate issuance from the server’s perspective). I wouldn’t recommend using this on a domain not listed on the public suffix list if your service is critical. For all other domains, the 7 day rate limit window together with the recommended 2 month renewal period should include enough buffer (1 month) in case you accidentally hit the rate limit on your first or second try.


#16

I see that letsencrypt/boulder GitHub page has the latest public suffix list merged here: https://github.com/letsencrypt/boulder/commit/8478a286f7a8fe8235aa5324571108eab1f9ad99

However, when I try to get a certificate, I still get the note about rate limits.

Shouldn’t the CA (boulder?) already be up to date with the above commit?

When would noip.me be available for cert registration?


#17

noip.me is not on the public suffix list yet, see https://github.com/publicsuffix/list/pull/64

Besides that changes to boulder are deployed to the staging server first and tested for a while before being pushed to production.


#18

I contacted noip support today and (with a lot of patience and kindness) they pointed me to the fact that they made a pull request to put their domains on the publicsuffixes list on December 4. However, the list of domains to be added is quite extensive and the people from publicsuffixes need time to verify the list so please be patient.


#19

I sent an email to the guy at afraid.org asking him to please submit their domains to the public suffix list. This should fix the problem with mooo.com (which i experienced today as well when trying to renew my certificate after the first 60 days…)

EDIT: I also have seen that there is a pull request open (not from the owner of afraid.org) to add all their domains to the public suffix list at https://github.com/publicsuffix/list/pull/79
The admins of the PSL seem however not to eager to merge it in…


#20

I just pinged the issue since it wasn’t really clear what timeline we were talking about. Based on the latest response, it sounds like not weeks, or months, but rather year(s). I had been waiting around since November thinking any day the domains would be added, so I know to stop checking now.


#21

I don’t think I ever said that in my reply.