Dropping request packets

[Kevin Darcy]

Weldon Goree wrote:

>Jim Reid wrote:
>
>  
>
>>Can I have some of whatever it is you've been smoking? :-) BIND[89]
>>have a number of mechanisms for dropping packets or refusing access to
>>particular clients. The server has access control lists that can be
>>applied to zone transfers, dynamic updates, queries, notifies and
>>recursive queries. Networks can be blackholed. Name servers can also
>>be tagged as bogus so they get ignored. Consult the BIND9 ARM for
>>things like the allow-update, allow-transfer, etc clauses; the
>>blackhole clause and server{} statement. These hooks are there for a
>>reason. Sure, most could also be implemented by a firewall or router.
>>But it can also be BIND's "job" to deal with who gets to access the
>>name server.
>>
>> 
>>
>>    
>>
>Maybe I misunderstood his question. I thought he was asking if he could 
>keep a certain IP address from querying his nameserver. allow-notify, 
>allow-transfer, and allow-update-forwarding don't do that. They set 
>policies on what hosts can send notifies, transfer zone data, and submit 
>dynamic updates, respectively.
>
>What BIND configuration do you know of that will prevent, say, someone 
>at 192.168.1.27 from running nslookup using your nameserver?
>
Prevent them from *running* nslookup? Obviously no such configuration 
exists. But neither can a firewall prevent someone from *running* 
nslookup. The most it can do is drop the packet before it gets to the 
nameserver. The "blackhole" option of BIND does almost exactly the same 
thing, with minimal processing devoted to the request, and no packet 
sent in response.

>>BIND has no way of rate-limiting inbound queries or TCP connections.
>>This is something a router or firewall does.
>>
>> 
>>
>>    
>>
>eh?
>
>options
>{
>    tcp-clients 750;
>    recursive-clients 25;
>    serial-queries 500;
>    etc...
>}
>
>I don't think I'm imagining those...
>
Well, let's consider each of those in turn:

recursive-clients. Depends on how narrowly you want to define 
"rate-limiting", I guess. recursive-clients does not "rate-limit" on a 
packet-by-packet basis, as a firewall or a router might. Rather, it 
controls how many recursive requests can be outstanding 
*in*the*nameserver* at any given point in time. This is *more* useful 
than packet-based rate-limiting if your goal is simply to control the 
performance and/or resource-consumption of your nameserver, since not 
all requests take equal amounts of resources, but on the other hand, it 
is probably somewhat *less* useful than packet-based rate-limiting if 
your goal is, say, to minimize the impact of a DOS attack (since there 
is still a certain amount of processing that occurs even for requests 
that ultimately get denied for quota reasons).

tcp-clients. This is closer to packet-based rate-limiting, since it 
controls how many simultaneous TCP client connections can be active at 
any given time. This is similar to what a stateful-inspection firewall 
might be able to accomplish.

serial-queries. Not really relevant to Jim's statement, since it only 
applies to *outgoing* requests...

                                                                         
                                          - Kevin