[ratelimits] Referrals incorrectly limited.

[Vernon Schryver]

> From: Joe Abley <jabley at hopcount.ca>

> I like this approach (forcing TC=1 so that clients are forced to
> handshake) but I do worry slightly that enough brain-dead middleware
> exists in the world that tcp/53 is unavailable sufficiently that "almost
> hall" might need to be degraded to "some".
>
> "almost all". Also, "sufficiently unavailable". Words are hard.

Before starting to worry about brain-dead middleware blocking tcp/53,
I'd think about junk blocking udp/53 and stop worrying about either.
Being liberal in what you accept doesn't involve pandering to the
willfully benighted.

There are also plenty of reports of junk that ignores TC=1, but TC=1 is
only a finally defense against false positives.  Any legitimate DNS
client worth caring about will spread at least 3 requests over several
seconds.  Unless there is a concurrent attack forging the client's IP
address, the client is one of a mob behind a NAT box or in an ISP
server farm recovering after a power failure, or other relatively
unlikely cases, what is the false positive problem?

The case at hand involves rate limiting 66 referrals per second and
forcing the abusive DNS client to slow down.  If those clients are 
remotely legitimate and even if they ignore TC=1, they were not blocked
but only forced to slow down.  Except that RIPE apparently wants to
answer abusive traffic from universities at full speed, would there
be any question?


Vernon Schryver    vjs at rhyolite.com