[bind10-dev] hooks in recursive server processing

Jerry Scharf scharf at isc.org
Fri Jan 21 00:45:46 UTC 2011


[It sounds like spam bots are what he is after.]

The ability to drop packets without processing is something different 
again from being able to change the way the query is processed once it 
is decoded. For my $.02, this kind of work makes a case for having a 
receptionist that catches all packets and can apply these kinds of 
things before sending them on to the auth or recursive engines. If you 
have multiple module instances taking queries directly from the O/S, 
then you need to figure out how to keep common data structures for the 
buckets with asynchronous processes.

In response to the comment of "adding their own code." One subtle point 
of this is it would be best if the work could be done externally to the 
auth or recursive modules. That way a set of binary modules for the 
basic server could remain unchanged and have the alternate query 
processing added by starting a new module and doing some config changes. 
(It can work that way in my fantasy world, reality is often a different 


On 01/20/2011 07:08 AM, Stephen Morris wrote:
> On 19 Jan 2011, at 23:51, Jerry Scharf wrote:
>> Hi,
>> I am slogging through every single response we got for the DNS operational survey. We asked people for any ideas that they would want.
> I'm at the UK Network Operators' Forum meeting and at lunch was speaking to a person from Ericsson who was interested in BIND-10.  He was after the ability to filter incoming packets to a resolver and to drop packets from addresses that were sending too many.  (He suggested a token-bucket approach - if you exceed more than a certain number of packets in a fixed time (say a few seconds), packets are dropped until the bucket receives more tokens.)
> The reason for this request is to do with mobile networks; sending too many packets (and responses) uses bandwidth.  The ability to limit traffic to heavy users allows the network to be fairer to the rest.
>> One person asked for the ability to "doctor" responses and a second person asked to be able to have an external module be called whenever there is a cache miss. To me, these seem to roll together as a slow version of inline filtering of the cache fill.
>> As you look at the design of the cache fill section, it would be nice if the design has the ability to a) route the cache fill request to a different module and b) have that module be able to call back into the upstream processing side of the cache fill. I am not saying anything about figuring out how to manage the capability or how the messages will be handled, I just want to say that this would be a nice thing that others could use.
> I take this as meaning that we should make it simple for people to add in their own code (and not just around the cache).  Either add in dummy calls at significant points and allow users to replace them, or supply documentation on  the process flow and indicate where additional code could be added.
> Stephen

More information about the bind10-dev mailing list