nanog mailing list archives

Re: What DNS Is Not


From: David Andersen <dga () cs cmu edu>
Date: Sun, 8 Nov 2009 19:17:16 -0500

On Nov 8, 2009, at 7:06 PM, Dave Temkin wrote:

Alex Balashov wrote:



For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS?

-- Alex

In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers.

He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests.

This myth (that Paul mentions, not to suggest Dave T's comment is a myth) was debunked years ago:

"DNS Performance and the Effectiveness of Caching"
Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris
http://pdos.csail.mit.edu/papers/dns:ton.pdf

Basically: Caching of NS records is important, particularly higher up in the hierarchy. Caching of A records is drastically less important - and, not mentioned in the article, the cost imposed by low-TTL A records is shared mostly by the client and the DNS provider, not some third party infrastructure.

From the paper:

"Our trace-driven simulations yield two findings. First, reducing the TTLs of A records to as low as a few hundred seconds has little adverse effect on hit rates. Second, little benefit is obtained from sharing a forwarding DNS cache among more than 10 or 20 clients. This is consistent with the heavy-tailed nature of access to names. This suggests that the performance of DNS is not as dependent on aggressive caching as is commonly believed, and that the widespread use of dynamic low-TTL A-record bindings should not degrade DNS performance. The reasons for the scalability of DNS are due less to the hierarchical design of its name space or good A-record caching than seems to be widely believed; rather, the cacheability of NS records efficiently partition the name space and avoid overloading any single name server in the Internet."

  -Dave



Current thread: