Hi,
The paper doesn't pass any judgement on types of lookups, but obviously
not all DNS lookups are equal from the end user perspective.
In our observation, looking for IP address consists 70% of our cache server load,
MX consists of 14% and PTR only occupies 5%. And, on the other hand, the coarse
analysis of our network traffic shows, Web traffic occupies only 8% while
stream meadia occupies the most part of traffic. So, the authors the conclusion
may be correct as viewing film online does not rely on DNS so much as
browsing web pages.
But, to my understanding a too short TTL will do harm to cache server performance
esp. the amount of RR cached is so large that BIND have to wait for swapping I/O
and re-fetching those timeout RR again.
"In our follow-up measurement study, [we found] that DNSBL related
DNS lookups at CSAIL in February 2004 account for 14% of all DNS
lookups. In comparison, DNSBL related traffic accounted for merely
0.4% of all DNS lookups at CSAIL in December 2000."
Is these work published or available publicly? Any work done with performance tuning
with cache server?
1. almost nobody has time to invest in reading this kind of paper.
2. almost everybody is willing to form a strong opinion regardless of that.
3. people from #2 use the paper they didn't read in #1 to justify an opinion.
people rely on their experience, but science tries to find on basis of analysis.
Usually, we met problems which is caused by people replace scientific conclusion with
their experience.
Joe
---- Introducing Spymac MailPro: http://www.spymac.com/mailpro/
Hi,
But, to my understanding a too short TTL will do harm to cache server
performance
esp. the amount of RR cached is so large that BIND have to wait for
swapping I/O
and re-fetching those timeout RR again.
I think you missed the main point of the report, it does not say that
low TTLs are a good idea in general.
What it does say is that the stability and performance of the DNS is
mainyl based on a rather high TTL for NS records, which distrubutes
the query load among a larger number of servers and avoid therefore
SPFs and Bootlenecks.
Compared to that the overall performance and load impact of lowering
the TTL for A records down to a few 100 seconds is not an issue, mostly
because the large number of queries for A records vom clients happen
in very short intervals of time, just look at what your webbrowser is
doing when you are surfing and therefore will be cached after the first
query by the local nameserver anyway. The important thing here is that
this nameserver does not have to go throught the same chain od DNS servers
again to find the one who gives him the right answer a few hours or days
later, but instead can just ask this server directly from his cached NS
record.
Parts of this I can also verify from my own experience. Although a nicely
tuned cascade of nameservers might add some measurable performance to DNS
resolution on client side, when surfing, the most noticeable performance
improvement is having a decent DNS server in your local lan which you can
reach within a few �S.
So in short:
LOW TTL A Records, will not affect stability and perfomance of DNS much.
LOW TTL NS Records, bad bad Idea.
Bye, Siggi.