Re: [regext] EPP and rate-limiting

["Patrick Mevzek" <[e-mail]>]

On Fri, Jan 17, 2020, at 09:30, Stephane Bortzmeyer wrote:
> Sometimes, some clients are too talkative and, for instance, try
> <create> too often to grab a domain. I'm not sure of the best error
> code to return when such behaviour is detected. HTTP has 429 "Too Many
> Requests" (RFC 6585) but I don't find a proper code in EPP. Any idea?

If you look at what happens in the wild, you can come to the conclusion that there is probably no proper way to handle it in EPP... as many registries with this need do things in very different ways:

- closing the connection (2502) may be a tad too harsh
- some registries are using 2201 (Authorization error)
- some registries just delay the reply for some given amount of time, like if you are allowed one operation per second, you do one, if you do the other in 0.5s after the first one, then its reply will get delayed by 0.5s so that you are back to  "1 per second";
for example one registry will force a 2s delay on any domain:info reply on any domain the registrar does not own
- most often this is often policy, and not always very clearly documented by registries; there is also no real way for registrars to discover those things automatically (rate limiting can be per command or even per object, or depend on time of day, like create will be most severily rate limited in the time of day the registry does its deletion process).
- rules can also be very complicated, like for example one registry has this one:
"Limit:180 per 60 seconds per registrar" and "Limit:60,000 per day per registrar"
- some registries have "hitpoints" instead of rate-limiting: for any kind of EPP errors (which would cover your case of "registrar is trying to create a domain that already exists), you get one point, and after a given amount of points in a given amount of timeframe you get shutdown completely for some given amount of time; there is again nothing standard here, some registries doing that have their own EPP extension for the registrar to know how many hitpoints it has.

And the above list is far from being exhaustive...

-- 
  Patrick Mevzek
  [e-mail]