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
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
