North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: That MIT paper

  • From: Siegbert Marschall
  • Date: Wed Aug 11 02:46:30 2004

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.