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.