For what its worth, Google namebench ( http://code.google.com/p/namebench/ ) showed that our caching DNS servers were faster than Google's public ones or OpenDNS. Guess our users keep the cache warm. I'd encourage everyone to run namebench and tune up their DNS servers or select the fastest ones.
What works for us at the moment is 3 boxes running Unbound on Solaris 10 behind IOS SLB load balancer. Both our DNS IPs live on the load balance and it does round robin across all servers. Next iteration will get rid of IOS SLB in favor of pairs of servers at different locations anycasting the DNS IPs. On Wed, May 26, 2010 at 12:33 PM, Tom DeReggi <[email protected]> wrote: > Not necessarilly. > > There are two points for bottle necks. > > One is the time it takes to respond to an inquirey from your end user, for > cached content. That can be related to distance to the end user, processsing > power/load. > The second is time to resolve DNS info and populate your cache, when a cache > hit is not successful by end user. This can be effected by distance to > authorative cache servers, the size of the cache, the odds of common DNS > queries by all end users, and and processing load on all servers involved, > including congestion on remote authorative DNS servers. > > The principle behind Internet born public DNS servers is that the chances of > a cache hit will be higher, because the odds the site has preveiously been > looked up is higher with more users using it. Gaining a cache hit > drastically increases performance, beyond that of new lookups or any > bandwidth latency or transfer rate limits injected in to the equation. The > second is simply hassle of managing your own. The third is potential for > better diversity. My point here is that managed public sservers can in many > cases give better performance. More so, if provider optimizes their hardware > selection/solution, and if servers are hosted nearby such as in same data > center your transit terminates at. > > We host our own servers for one reason, but it is not performance. IF we > ever have a transit outage or dispute, we do NOT want our end user's DNS > disrupted. It creates way to many service calls and accelerates the time > period in which subscribers notice a problem. (For example, Email loosing > password, after pop server does not resolve) > > Its also relevent to point out using a lcoal server for primary and a public > server for secondary is not always ideal. The reason is that not all > services query primary DNS1 first. > Some applications may do a round robin approach, alternating which DNS it > checks. My point is secondary DNS may not just be relevent for > diversity/redundancy. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > > ----- Original Message ----- > From: "Travis Johnson" <[email protected]> > To: "WISPA General List" <[email protected]> > Sent: Wednesday, May 26, 2010 12:57 PM > Subject: Re: [WISPA] Fast DNS cache > > >> Not faster than having your own servers on your own network... ;) >> >> Travis >> Microserv >> >> >> Jerry Richardson wrote: >>> I can't believe how fast the google servers are. >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of David E. Smith >>> Sent: Wednesday, May 26, 2010 9:48 AM >>> To: WISPA General List >>> Subject: Re: [WISPA] Fast DNS cache >>> >>> On Wed, May 26, 2010 at 11:40, Mike Hammett <[email protected]> >>> wrote: >>> >>>> I am setting up some new DNS servers and I'd like to figure out what the >>>> quickest caching DNS server is. Google keeps telling me to go to Open >>>> DNS. I'm not opposed to them and may use them as either primary or >>>> secondary, but I want at least one server within my own network. >>>> >>> >>> If you're looking for off-site service, I'm surprised Google isn't >>> plugging their own public caching-only DNS servers (8.8.8.8 and >>> 8.8.4.4, I think). >>> >>> If you want to install your own, just use BIND. >>> >>> David Smith >>> MVN.net >>> >>> >>> -------------------------------------------------------------------------------- >>> WISPA Wants You! Join today! >>> http://signup.wispa.org/ >>> -------------------------------------------------------------------------------- >>> >>> WISPA Wireless List: [email protected] >>> >>> Subscribe/Unsubscribe: >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> Archives: http://lists.wispa.org/pipermail/wireless/ >>> >>> >>> -------------------------------------------------------------------------------- >>> WISPA Wants You! Join today! >>> http://signup.wispa.org/ >>> -------------------------------------------------------------------------------- >>> >>> WISPA Wireless List: [email protected] >>> >>> Subscribe/Unsubscribe: >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> Archives: http://lists.wispa.org/pipermail/wireless/ >>> >>> >> >> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: [email protected] >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
