RE: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf -dnsop-parent-sig-00.txt))

Tim Seaver <tas@bellsouth.net> Tue, 17 April 2001 06:31 UTC

Received: from nic.cafax.se ([192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03732 for <dnsop-archive@odin.ietf.org>; Tue, 17 Apr 2001 02:31:44 -0400 (EDT)
Received: by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) id f3H5xtBj023146 for dnsop-outgoing; Tue, 17 Apr 2001 07:59:55 +0200 (MEST)
Received: from naptop.autonomica.se (flaptop.liman.sunet.se [193.10.90.102]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3H5xnLt023141 for <dnsop@cafax.se>; Tue, 17 Apr 2001 07:59:49 +0200 (MEST)
Received: by naptop.autonomica.se (8.12.0.Beta1/8.12.0.Beta1) id f3H5xSiB000498 for dnsop@cafax.se; Tue, 17 Apr 2001 07:59:28 +0200 (MEST)
Received: from spike.eng.bellsouth.net (spike.eng.bellsouth.net [205.152.33.1]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f3GKb6Lt020606 for <dnsop@cafax.se>; Mon, 16 Apr 2001 22:37:06 +0200 (MEST)
Received: (from tas@localhost) by spike.eng.bellsouth.net (8.9.3/8.9.3) id QAA29022; Mon, 16 Apr 2001 16:37:03 -0400 (EDT)
Date: Mon, 16 Apr 2001 16:37:03 -0400
From: Tim Seaver <tas@bellsouth.net>
Message-Id: <200104162037.QAA29022@spike.eng.bellsouth.net>
To: dnsop@cafax.se
Subject: RE: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf -dnsop-parent-sig-00.txt))
Cc: namedroppers@ops.ietf.org
Sender: owner-dnsop@cafax.se
Precedence: bulk

 > Seems like this thread has strayed into operational territory, so I'm
 > directing replies to dnsop@cafax.se (and including the whole message for
 > background).

Randy sounded like he wanted some operational data injected into
the thread, so I complied. The redirect is fine.

 > Tim, could you please elaborate on your #1 below?  I'm not sure if you're
 > attributing the short TTLs to the {com,net,org} zone contents.  But I just
 > wanted to point out that although all delegations in the {com,net,org} zones
 > have a 48-hour TTL, that should have little effect on how long a zone's NS
 > RRset is actually cached.  In any BIND name server since 4.9, as well as the
 > Microsoft DNS server (at least the W2K version--don't have an NT 4 system
 > handy to test), the NS RRset in the delegated zone overrides the RRset
 > obtained from the parent.  So NS RRsets for subzones of {com,net,org} with
 > "short" TTLs are an issue with individual zone administrators.

Exactly. There are lots of popular domains with short NS records at
the second level. The delegation records are fine. The second-level
authoritative data with 1 hr or shorter TTLs on NS records are
questionable and definitely contribute to poor DNS client performance.
I don't know why people do this, but it seems to be endemic to
well-known web domains.

 > What do you mean by "overload of gTLD servers"?  We've sized the
 > {com,net,org} name servers very carefully and monitor the query volume in
 > real time.  We have lots of headroom and have yet to come close to our
 > maxmimum.  I'd be very interested in any data you've got--I wouldn't like to
 > think we've missed something.

I see regular outages from several of the closest gTLD servers. These
may be scheduled reloads rather than overload, but they are outages
and they contribute about 20% to the caching server query losses I see
on a select set of queries. We can take further details offline.

Thanks,

	Tim