On Tue, 14 Aug 2007, [iso-8859-1] Bjørn Mork wrote:
"Chris L. Morrow" <christopher.morrow@verizonbusiness.com> writes:
This is still a client issue as, hopefully, the cache-resolvers don't funnel their business through nscd save when applications on them need lookups... (things like ping/telnet/traceroute/blah)
nscd may represent a problem if the application in question is a http-proxy without it's own resolver. There's also a number of more-or-less broken http-proxies doing their own resolver caching regardless of actual TTL.
that's fine, that's still a client problem, not a cache-resolver problem... These devices look 'upstream' for a cache-resolver to do their dirty work, these just add an extra layer of indirection for the CDN to figure out (my client is in SFO, my proxy is in IAD, my cache-resolver is in CHI).
Such applications represent a problem wrt any DNS-based load balancing, including CDNs, since they can serve a large number of end-users, redirecting them to the "wrong" address long after the TTL should have expired.
Yup, people should be aware of what the systems in their path are doing, or as was mentioned earlier, have lots of exceptions on the CDN side.