Subject: [e2e] DNS

From: Randy Bush <[email-masked]>
Date: Tue, 18 Sep 2001 17:28:59 -0700

[ excuse the crosspost, but ... ]

[ the caching result for a rrs is good.  i am aware of other research which
  shows caching of ns rrs is quite beneficial -- rb ]

---

From: Hari Balakrishnan <[email-masked]>
To: [email-masked]
Subject: [e2e] DNS
Date: Tue, 18 Sep 2001 20:02:21 -0400

We've been collecting client-side traffic traces of DNS traffic, jointly with 
the driving TCP connection workload, for a couple of years now, and a recent 
paper analyzing these data sets may be of interest to many on this list.  Our 
data spans many months of collection at the border router connecting MIT's LCS 
and AI Lab to the rest of the Internet, as well as a border router at KAIST in 
Korea.

The paper, "DNS Performance and the Effectiveness of Caching," 
by Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris, is at 
http://nms.lcs.mit.edu/papers/dns-imw2001.html

Some of our non-obvious (to us!) findings and conclusions are: 

- About a quarter of all DNS lookups never get an answer. More than 50% of
the DNS-related packets in the wide-area correspond to such lookups...

- The DNS retransmission protocol appeears to be overly persistent: while
most successful answers are received in at most 2-3 retransmissions, the
lack of an answer or response causes a much larger number of retransmissions
and a corresponding number of DNS packets traverse the wide-area.

- Replacing the A-record TTL's for most (or all) Internet hosts to a value
as small of 10 minutes is not likely to degrade the scalability of DNS in
any noticeable way.

- The scalability of DNS has little to do with its hierarchical organization
or good A-record caching. Most of the DNS name space is a flat, two-level
structure.  A-record caching does not seem to add much more to the per-host
or per-application caching done by end clients today.  Rather, the
scalability derives from the good name space partitioning achieved by the
cacheability of NS records, which avoid load on the root and top-level name
servers.

The paper details the combination of trace analysis and trace-driven cache
simulation that we used to arrive at these conclusions.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Sep 2001 20:24:08 -0700

>> [ the caching result for a rrs is good.  i am aware of other research
>>   which shows caching of ns rrs is quite beneficial -- rb ]
> The packet loss result is not so good -- 25%! Perhaps there is a case for
> standardizing resolver retransmission behavior after all.

oh, indeed!  my comment was merely to limit any undue inferences that might
be made from the a rr caching result.

randy

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Sep 2001 20:14:57 -0700 (PDT)

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 19 Sep 2001 17:22:08 -0400

While the report was a bit of an eye-opener, I think the conclusion that
(paraphrased) "reducing A-record TTLs won't hurt" is a little facile,
especially given the other conclusion that (paraphrasing again) "NS-record
caching is saving our collective butts". After all, the referral-following
mechanism requires A-records *in*addition* to NS-records and if the TTLs on
*those* A-records drop precipitously, then most of the benefits of NS
caching will be lost. The authors of the paper seem to be treating
NS-records as if they exist entirely separately from A-records, but in
reality of course NS-records and A-records and the respective caching
characteristics of each are interdependent as the protocol stands today. It
would take something like my "REFER" record-type proposal (see the archives)
to reduce or eliminate that interdependency.

- Kevin