[ratelimits] what does "same response" really mean?

[Vernon Schryver]

> From: Bob Harold <rharolde at umich.edu>

> I checked a packet trace, and I only see one query for just "hp.com".
> Also note that the source port number changes each time, except that
> the "drop" and "slip" entries show the same port # as the previous
> line, because it is the same query that was logged with query logging.
>  (So packets that are dropped or slipped get two lines in the
> named-query log file.)  Why does the "drop" or "slip" say only
> "hp.com", when the query was for "welcome.hp.com" ?


Was this an example from the original message to the mailing list?

23-Jan-2013 08:48:17.503 queries: info: client 1.2.3.4#50066: query: welcome.hp.com IN A + (5.6.7.8)
23-Jan-2013 08:48:17.503 queries: info: client 1.2.3.4#50066: slip response to 99.118.80.0/24 for hp.com IN A  (000030ec)

My guess is that the rate limiting bucket/block/counter for
"hp.com IN A" was used because hp.com was the nearest known parent
name for welcome.hp.com.
The nearest known parent names are used for errors and referrals.
Otherwise there would be no rate limiting on <random>.example.com.
That would be a Bad Thing in two different kinds of scenarios.
It could allow an open recursive server reflect a flood of typical 1 KByte
DNSSEC NXDOMAIN responses at a victim,
or it could get the server rate limited by the authoritative server.
Disabling a site's name service is an important part of many classic
security attacks.

The RRL log entries say when they are for errors.  I'll see if it is
easy to find and pass along enough information so that referral log entries
and show themselves.  It might not be easy and so cheap enough to
justify.  The parent name is easy to get because of the way the
main bind9 query recursion loop works.  Given the lack of value of
RRL on recursive servers, it would be hard to justify many CPU
cycles for it.


Vernon Schryver    vjs at rhyolite.com