At 05:59 PM 8/27/2005, email builder wrote:
We just migrated to Tinydns from BIND and are looking at our cache size
(OK, so I am really talking about dnscache, not tinydns itself). Looking at
our cache logs from the last 12 hours (2am Friday night to 2pm Saturday
afternoon), I see our "cache motion" is already 75MB of data. Wow. That's
in a relatively low activity time for us. We get an average of somewhere
under 100,000 mails a day.
Well, figure the following:
SA makes the following DNS queries, at least:
2 URIBLs (SBL and SURBL) for each URI in a message, limited to 20 uri's.
11 DNSBLS per IP in the Received: headers (counted by queries not by tests,
ie: sorbs is 1 not 10)
1 MX record check on the return-path or from address.
So figure a typical message has 1 uri, and 2 Received: headers. Thats's 25
DNS queries, per message. And that's not counting any recursion.
At 100k messages a day, that's 2.5 million queries/day, ballpark, just for
SA lookups. That's not counting the MTA's reverse lookups, MX lookups, etc,
or any other DNS activity in the network.
I'd figure your SA traffic is going to generate at least 25-50mb of cache
motion a day.
If your tinydns server is a multi-purpose resolver, ie: it resolves for
both your mail system and client boxes, you might consider setting up one
that's dedicated to your mail system to "split the load" of DNS caching
between client requests and mail systems. The DNS lookups are going to be
very different between the two, so you won't be wasting anything by having
separate caches. The user queries will mostly be A record lookups for
www.*.com and the mailserver will mostly be MX and PTR queries.
If IPs are scarce, but you have hardware to spare, you could set up two
caching resolvers with private IPs, and have them forward to one resolver
with a public IP that does recursion.
