[bind10-dev] hardwiring negative cache entries

[Jerry Scharf]

Michal,

The DNS rfcs create a situation where it is impossible to avoid a great 
deal of work for these bogus zones. There are specified limits for how 
long a negative cache entry is allowed to exist, so you keep trying the 
same mistakes over and over. Each time you try it, you need to go 
through the entire upstream query process, which has major impacts on 
the server performance.

Being able to hardwire a response removes the negative cache timers and 
primes the cache so all the upstream processing is avoided. This 
mechanism can also be used to block responses to sections of the 
namespace that the operator determines to be undesirable. This is the 
idea behind Paul's RPZ, and it wants about the same mechanism in the 
cache as the handling of the bogus zones.

The are purists who say that there is only one global namespace, but the 
popularity of views already refutes this as the only view. Adding this 
is just another step in a well grooved path.

Given that the number of these entries that would be wanted over time 
could be large, I agree with Michael's view that datastore elements like 
RPZ are the way to go rather than configuration entries.

In BIND 9, as soon as you do upstream processing, the throughput of the 
server drops severely. We certainly want to reduce this penalty, but at 
some level the drop will always be there.

jerry

On 11/28/2010 2:44 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> On Sat, Nov 27, 2010 at 11:01:08PM -0800, Jerry Scharf wrote:
>> The person said that 40% of their queries are for domains that don't
>> exist. This has a huge negative impact on the recursive server capacity.
>> To solve it, they have created local authoritative zones that return
>> errors and make the performance close to normal. They wanted some way to
>> do this without having to create and operate all these fake zones.
> Well, I don't have experience about operating a DNS server, but I wouldn't
> really be surprised by that 40%, people make typos. Therefore the goal should be
> to write the server so it is not slowed down by 40%, that a negative answer
> shouldn't take more time than positive.
>
> But if I understand you correctly, you put this as an example of a feature that
> nobody would probably thought of beforehead and the system should be flexible
> enough to allow it at any later time without large rewrite. If so, I fully
> agree.
>
> Just what I thought the goal was is to be able to anyone to plug another layer
> in front of the cache (well, in front of anything, that's what we talked about
> on the f2f ‒ this is the extensibility as I understand it). So they would write
> an extension that would check the domain name (assume, for the example, that by
> a regexp, but that does not matter). If it did match, it would return right away
> and never call the cache.
>
> Another one would be, I think we will need a way to ensure some cache entries
> are not deleted too soon (a way to hold them locked or something). If this was
> there, it wouldn't be hard to just dump them into the cache at startup and keep
> them locked infinitely. But that is a more hackish solution.
>
> With regards
>