[ratelimits] Referrals incorrectly limited.

[Vernon Schryver]

> From: john <jbond at ripe.net>

> > I do not understand "not under that attack at the moment" reasoning.

> The point is more that enabling the patch will block legitimate traffic.

Do you disagree with my claim that in almost all legitimate cases not
in the middle of an attack, RRL does not *block* DNS traffic but only
slows it down by forcing legitimate DNS clients to retry or switch to TCP?



> > in-addr.arpa, then they could use a linear contruential random number
> > generator to cover all 4 billion IPv4 addresses as fast as possible
> > without hitting any authority too often.

> I think even if they did this they would still hit the ratelimiting as a
> large amount of the addresses space we are authoritative for has not
> been delegated.  Therefore the user would get many referrals for our
> ns-set.  admittedly this is a gut feeling, i have not look at the actual
> probabilities.

Consider computing the next address by adding 16777259 to the 32
number representing the previous address.  I think that would scatter
requests widely enough to avoid small RRL limits at any DNS server
responsible for a modest number of in-addr.arpa /16 blocks.  It also
doesn't do badly for /8 authorities, although caching should make that
moot.  If 30% of IPv4 addresses is delegated to RIPE, then each hit
on RIPE servers should be separated by hits on 2 other authorities,
thereby slowing the hits on RIPE DNS servers.
16777259 might be improved; it is merely the smallest prime > 2**24.
It might be better to use the multiplicative group instead of addition.


Vernon Schryver    vjs at rhyolite.com