What DNS Is Not
David Andersen
dga at cs.cmu.edu
Mon Nov 9 00:17:16 UTC 2009
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
More information about the NANOG
mailing list