[Rserpool] Study of DNS performance in progress (fwd)

Bernard Aboba <aboba@internaut.com> Mon, 16 April 2001 18:25 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10649 for <rserpool-archive@odin.ietf.org>; Mon, 16 Apr 2001 14:25:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03712; Mon, 16 Apr 2001 14:21:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03681 for <rserpool@ns.ietf.org>; Mon, 16 Apr 2001 14:21:28 -0400 (EDT)
Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10542 for <rserpool@ietf.org>; Mon, 16 Apr 2001 14:21:28 -0400 (EDT)
Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA70807 for <rserpool@ietf.org>; Mon, 16 Apr 2001 11:15:14 -0700 (PDT) (envelope-from aboba@internaut.com)
Date: Mon, 16 Apr 2001 11:15:14 -0700
From: Bernard Aboba <aboba@internaut.com>
To: rserpool@ietf.org
Message-ID: <Pine.BSF.4.21.0104161111230.70799-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [Rserpool] Study of DNS performance in progress (fwd)
Sender: rserpool-admin@ietf.org
Errors-To: rserpool-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Reliable Server Pooling <rserpool.ietf.org>
X-BeenThere: rserpool@ietf.org

FYI... it appears that short TTLs are having an effect on DNS
performance. Would probably be worth citing this report when it comes out.


---------- Forwarded message ----------
Date: Mon, 16 Apr 2001 13:23:40 -0400 (EDT)
From: Tim Seaver <tas@bellsouth.net>
To: randy@psg.com
Cc: namedroppers@ops.ietf.org, narten@raleigh.ibm.com
Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent
    (draft-ietf-dnsop-parent-sig-00.txt))

 > > > I.e, the DNS does the things it is designed for quite well.
 > >
 > > opinions on this seem to vary.  and the trend seems to be more
 > > dissatisfaction.  responses are perceived to be slower, though
 > > hardware is faster and bandwidth wider.  it would be helpful
 > > to have actual data.

I'm in the middle of a DNS performance study. Right now, I can
say with confidence that most DNS performance problems from my
perspective in the network/DNS topology come from:

1) Short TTLs on second-level NS records combined with overload of
gTLD servers, leading to caching server retries for delegation data.

2) Short TTLs on popular address records combined with overload of
second-level domain servers, leading to caching server retries for
web host address records.

3) Short TTLs on second-level NS records combined with second-level
servers in a different domain than the name being queried combined
with BIND's decision to ignore additional data in such circumstances
combined with BIND's decision to drop client queries when no address
records exist for the authoritative servers required to resolve a query,
leading to non-response from caching servers and client retries.

Network-level problems come in a distant second to server problems
combined with short TTLs. When I have a report done, I'll see if I
can release it to the list.

Thanks,

	Tim


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.


_______________________________________________
rserpool mailing list
rserpool@ietf.org
http://www.ietf.org/mailman/listinfo/rserpool