mailing list archives
Re: DNS caches that support partitioning ?
From: Raymond Dijkxhoorn <raymond () prolocation net>
Date: Sat, 18 Aug 2012 11:35:58 +0200 (CEST)
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).
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.