All 3 of my DNS servers are in the same room. In fact, one is on the same virtual host... They are all caching from the roots. I won't even trust my upstreams, I go to the top. I know, I should have at least one offsite. I'm thinking about dropping a server in one of my customer's just for DNS.
Anyhow, I'll have to do some numbers myself but I think since the inside DNS are caching, it's almost as good as running cache on QMT. > Phil Leinhauser wrote: >> Speaking of DNS... >> You guys seem to be running a fairly large setup. Are you running DNS >> servers in house? Are you also running DNS caching on QMT? >> >> I'm running 3 DNS servers for my hosted domains and I'm just pointing >> QMT >> to those. I don't seem to be having any kind of speed problems relating >> to DNS. I'm just curious if there really is enough benefit to running >> the >> QMT w/DNS cache. >> > > I run 3 DNS servers for my own stuff and my projects (DNS servers > located in California, NJ, Florida). I always set up caching nameservers > on my mail servers (regardless of QMT or Postfix) and point them at my > DNS servers as the next upstream for DNS resolution. > A caching DNS resolver saves milliseconds, but if it looks up an IP it > does not need to look it up again (until TTL is hit) thus saving on > traffic/overhead (and maybe RBL checks if they're cached - might help > with limits imposed by the "free" RBLs out there). Might not seem like > much, but over 80,000 emails it adds up to seconds saved at worst. I > imagine I could generate some real metrics on the subject if you really > want, or at least extrapolate some: > j...@jake-desktop:~$ time dig +short whoknows.com > > real 0m6.630s > user 0m0.000s > sys 0m0.008s > j...@jake-desktop:~$ time dig +short whoknows.com > > real 0m1.438s > user 0m0.004s > sys 0m0.000s > j...@jake-desktop:~$ time dig +short whoknows.com > > real 0m1.015s > user 0m0.004s > sys 0m0.000s > j...@jake-desktop:~$ time dig +short whoknows.com > > real 0m1.194s > user 0m0.004s > sys 0m0.008s > j...@jake-desktop:~$ time dig +short whoknows.com > > real 0m0.914s > user 0m0.004s > sys 0m0.000s > j...@jake-desktop:~$ > > The first lookup took 6.6 seconds (rounded). The next took 1.4 seconds - > a savings of 5.2 seconds. Over the course of 5 lookups if we assume that > I was *not* running a caching resolver, this would have taken 33 seconds > but in reality took 11 seconds. This was a single lookup over the span > of 10 seconds which I don't think it's unreasonable for a server to get > 5 emails from the same server in the span of 10 seconds, especially on > high-load servers. Granted this is not a very accurate test (I cache > against my upstream's DNS, which undoubtedly is also cached) but it gets > the point across and at least gives some generalized metrics. > > Plus by pointing my mail servers (and those I set up for other people) > at my own DNS servers I have another degree of control/troubleshooting > available to me. Such as this issue that Eric helped me with. *MY* tests > all came back okay since the mail servers I used for testing used my DNS > servers; the client's used their ISP's DNS servers which were causing > the problem. If it was my DNS servers caching something they were not > supposed to, I can usually fix it by "service named restart" (or > /etc/init.d/bind9 restart on the Debian name server). That is not so > easily done with a ISP's DNS servers. In my experience I've found that > DNS admoins for some reason have no phones and can only communicate via > email. To get the ISP's DNS servers even to even restart the service > will most likely take 3-4 days of emails back and forth. Wish I had a > job where I only ran a group of DNS servers and didn't have to answer > phone calls.... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
