To:
dnsop@cafax.se
Cc:
namedroppers@ops.ietf.org
From:
Tim Seaver <tas@bellsouth.net>
Date:
Mon, 16 Apr 2001 16:37:03 -0400 (EDT)
Sender:
owner-dnsop@cafax.se
Subject:
RE: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf -dnsop-parent-sig-00.txt))
> 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