On Tue, Nov 30, 2010 at 07:01:32PM -0500, Richard Pieri wrote: > On Nov 30, 2010, at 2:30 PM, Derek Martin wrote: > > > > False. Typically, ISP's DNS servers get a lot more traffic than one > > you run yourself at home, so cached answers for sites that you visit > > infrequently tend to stay cached, whereas your home server may need to > > do a full look-up every time you visit. As a result, for infrequently > > used sites, your ISP's DNS servers will very often be faster. It's > > Faster by a whole half a second, give or take, for the first lookup > only. Then the local lookup will be about an order of magnitude > faster than hitting the ISP due to network latency. That depends on a great many factors. I've no doubt you know how DNS works so you know that a DNS lookup is not just one lookup. I do run my own DNS, and I very frequently see lookups for sites I don't use often take 5 or 10s or longer, and even time out... plenty often enough to be noticeable. Odds are the ISP's DNS servers will have been asked about whatever site you're visiting a lot more often than yours have. I basically never see this when I'm at work or visiting family members and using their ISP's DNS servers. [I've run ad-hoc benchmarks in the past that showed this, but not in any sufficiently scientific way that mentioning that is anything but an anecdote.] And suppose you're researching something on line, visiting a number of sites that (may or may not) have info about the thing you're researching? Odds are you've never been to any of them, or at least not recently. So you'll need to do that first look-up for each and every one of them. If only half of them are slow, you're going to notice, and not in a happy way. And as for it being the first time... maybe, maybe not. As I mentioned, these days it's extremely common for sites to use very low TTLs, e.g.: $ dig www.ford.com [...] ;; QUESTION SECTION: ;www.ford.com. IN A ;; ANSWER SECTION: www.ford.com. 1800 IN CNAME www.ford.com.edgesuite.net. www.ford.com.edgesuite.net. 21600 IN CNAME a1200.g.akamai.net. a1200.g.akamai.net. 20 IN A 74.203.241.11 a1200.g.akamai.net. 20 IN A 74.203.241.8 So it's the first time... and every 20s after that. [Granted, well-run CDNs have ways to deal with this -- JPG's are not the only thing CDNs can accelerate -- but they are not the only ones using such tricks.] Sites will vary, of course. It really depends on the resources of the site in question and how clueful their technology staff is. Latency is not the only issue. The ISP's servers are much more likely to be closer to much higher bandwidth pipes which much lower packet loss. Most ISPs (sensibly) are much faster to respond to troubles that affect their infrastructure, than they are to deal with localized problems affecting only a small number of users. Your DNS server is much more likely to be on a link that experiences packet loss, route flapping, or other connectivity problems for much the same reason. These may or may not affect the rest of your connection/session... For sites served by CDNs, there is another potential issue: If they decide to map you based on where the DNS request is coming from (remember that the first interaction the CDN has with you is when *your* DNS server asks *their* DNS server about the site you're trying to go to; it has to make at very least a first-pass decision where to map you THEN, before it even knows your IP address), then it may make bad mapping decisions for lack of good topological info about your DNS server's (i.e. your) network segment, depending on how sophisticated they are. That may not make your DNS look-up slow; but it will ruin your day... And don't forget that your home DNS server's performance will be impacted by whatever else you're doing on that machine. Your ISP's DNS servers are very likely fairly beefy, and dedicated to their purpose. As for ISPs rewriting TTLs, it's annoying, but in practice it mostly doesn't matter much. If you get mapped to a bad server because of it, you'll see that the site is b0rked and come back later. Odds are that a) you won't realize that's what's happened, and also b) it won't actually happen... even if the mapping changes, it's fairly likely that the previous IP is still up and serving, and you won't notice anything. But if you have to look up the host name every 20s, you will probably notice *that*. Perception is reality. > Going to the ISP for every lookup is a big, fat lose. Even when it *is* a lose, it's very, very far from being a big fat one. The reality is, for the average person on this list, choosing your own server or your ISP's server isn't going to make too much difference. On average, if your ISP isn't complete crap, and doesn't mess too badly with DNS (or you don't much care if they do, as long as stuff works), using their servers may well be slightly faster (see Edward's comments about benchmarks). And on average, you probably won't notice much... but sometimes you will, and usually not in a good way. Of course if your ISP *is* complete crap, all bets are off; the solution there is to find a new one. > Which brings me back around to the point: the only good reason not > to run your own local resolver cache is because you are unwilling or > unable to do it. Which remains false. Typically on average it buys you very little, if anything; and it definitely can have a noticeable negative impact on your Internet-using experience, depending on many different factors. Given that, regardless of whether you're willing and able, it may simply not make sense to bother doing the work required to set it up and maintain it. It's probably only worth doing if you notice that your ISP's DNS servers are crap, AND you can't identify some better ones; or if you have some other good reason to do it, like serving DNS for your own domain on your network. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.