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

"Larson, Matt" <mlarson@verisign.com> Mon, 16 April 2001 21:10 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: "Larson, Matt" <mlarson@verisign.com>
Reply-To: dnsop@cafax.se
To: 'Tim Seaver' <tas@bellsouth.net>
Cc: namedroppers@ops.ietf.org
Subject: RE: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf -dnsop-parent-sig-00.txt))
Date: Mon, 16 Apr 2001 15:56:50 -0400
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E14pFPo-000I8J-00@psg.com>
Content-Transfer-Encoding: 7bit

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).

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.

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.

Thanks,

Matt
--
Matt Larson <mlarson@verisign.com>
VeriSign Global Registry Services / www.verisign-grs.com


> -----Original Message-----
> From: Tim Seaver [mailto:tas@bellsouth.net]
> Sent: Monday, April 16, 2001 1:24 PM
> 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.
> 


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

RE: DNS vs. non-DNS Data (was Re: Signature at pa… Larson, Matt