What DNS Is Not

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