I use a free DNS benchmarking piece of software to actually test my DNS fallback servers. Out of the box, this tool can measure the raw performance of a whole variety of publicly available DNS servers as they perform ON YOUR NETWORK. This means that if you have a slow route to OpenDNS, but a fast one to google for network topology reasons, this tool will show that. It is really worth a look for anyone wanting to speed up their DNS performance. If you run your own DNS server with forwarding, make sure you compare the *non-cached* performance parameters (your local DNS should win hands down for any cached requests) On a LUG, it is probably bad form to recommend a MS windows utility, but flame away, this tool performs a useful task: http://www.grc.com/dns/benchmark.htm -- Kevin Ubuntu Server 10.04 On 1/13/2011 10:44 AM, Mr. B-o-B wrote: > Hello, and a good day to you all. I was wondering if anyone has ever used > the public Goggle DNS servers, and if they are reliable. > > I recently installed a WAN traffic manager at two of our locations. > > http://www.ecessa.com/pages/products/products_powerlink_pl200.php > > These units are cool. I am now bonding 3 isp data connections at one > location, and two isp connections at the other. It also allows me to do > line bonding for site to site vpn connections which was a selling point > for me (why is the system slow calls from the remote office have > seriously decreased :) ). > > Since I installed this unit, I have notice a slight performance hit in the > DNS department. Internally I have a Slackware box running BIND as a > caching nameserver. Beneath that there are a > handful of M$ (sorry guys, > but it's a business& corporate is clueless) AD - DNS servers that > maintain& handle the local dns > & forward external requests to the Slackware BIND box. Prior to > installing the traffic manager, I had BIND setup to forward its > unknown non-cached requests > to the ISP DNS servers that was hooked up to my LAN. This worked great > for years. When I hooked up the traffic manager, I added the other ISP > dns servers to the list of forwarders in my BIND config. After all, > half the reason I picked up the traffic manager was for redundancy (in > case ISP link 1 goes down, etc.). Once I added the other ISP forwarder I > started to notice delays in DNS queries. Since the traffic manager is > spitting out my traffic on 3 different ISP I believe this is where the > problem is. If my BIND sends a forward query to ISP DNS 1, but the query > is actually sent via ISP data link 2, or 3 then when DNS server 1 > receives the request it is saying "I don't think so stranger". Then my > BIND retries until it actually get the magic ISP DNS on the correct ISP > link. End result = Ring, Ring, Why does my browser take so long to > load!. > > I realize I could just ditch forwarding all together, but I prefer to let > an upstream ISP server handle the load& not constantly bother the top > level servers for every new request we get. A solution I think would be > to forward my dns queries to a server that will accept from any of our ISP > lines. I don't think I really trust the old 4.2.2.2, but I noticed Goggle > has a public dns service @ 8.8.8.8. This could solve my problems. > > Does anyone have an opinion on using the Goggle DNS? > > I have also considered putting a box on the outside of the traffic manager > with 3 nics (one hooked into each ISP)& running BIND that way. Although I > fell this would work fine, it just seems like more work that I want to do > & yet another thing I will have to worry about. > > Another option is the wan manager has QoS I can setup so all my > external DNS > forward requests go via one of the links. I am reluctant to go this route, > and I want to keep things as redundant as possible. > > Sorry for the long winded post. > > Thanks! > > B-o-B > > > > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20110113/782bc3cb/attachment.htm