Re: DNS caches that support partitioning ?

[Raymond Dijkxhoorn <raymond () prolocation net>]

Hi!

> > The cache needs to be big enough that it has a thrashy bit that is
> > getting changed all the time.  Those are the records that go into the
> > cache and then die without being queried again.  If the problem is
> > that there's some other record in there that might be queried again,
> > but that doesn't get queried often enough to keep it alive, then the
> > additional cost of the recursive lookup is just not that big a deal.

> A big part of the problem is that TTLs reflect the server's estimate
> of how long it might be until the data changes, but not the client's
> likelihood of reusing the data.  I publish a BL of hosts in Korea.
> The data changes maybe once a month so from my point of view a large
> TTL would make sense, but most of the hits are for bots spraying spam
> at random, so the client's not likely to reuse the data even if it
> sticks around for many hours.
>
> A plausible alternative to a partitioned cache might be TTL capping,
> some way to say to your cache that no matter what the TTL is on
> data from a range of names, don't keep it for more than a few seconds.
>
> Another thing that would be useful to me for figuring out the BL cache
> stuff would be traces of incoming IP addresses and timestamps for mail
> servers larger than my tiny system, so I could try out some cache models.

About any caching nameserver supports forwarding. So if you REALLY are 
afraid this will bite you. Fire up another instance. Forward all the 
reverse DNS to that and you are set. That other instance will handle your 
reverse DNS with a cache that you will specify. The other ones are not 
impacted at all. When you use forwarding it doesnt cache the entry. 
('forward only' option in bind for example).

So:

Caching resolver -> Caching resolver dedicated for reverse DNS.

Your first resolver does not cache reverse DNS and you are safe there. On 
the second you do the reverse DNS.

I talked with Paul Vixie about doing this internal inside bind but that 
was not something they would be delighted to do (at least not now). If you 
could define how large your cache pool was for certain objects that would 
fix it also.

Reverse DNS isnt the only issue here. There are many sites that give each 
user a subdomain. And if i look at my top talkers on some busy resolvers i 
do see that thats doing about 25-30% of the lookups currently.

akamai.net, amazonaws.com and so on. All make nice use of DNS for this.
Those have litterly millions of entry's in DNS also. And thats what 
currently is doing the load on resolvers...

Oh and dont forget DNSSEC. Traffic went up allready by a factor 7 due to 
that. Those objects are also much larger to store.

Bye,
Raymond.