Re: That MIT paper
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.
participants (2)
-
Joe Shen -
Siegbert Marschall