Mark, thats a bit of an unsatisfactory answer. the RFC (which you
authored) says:

"...As with caching positive responses it is sensible for a resolver to
   limit for how long it will cache a negative response as the protocol
   supports caching for up to 68 years.  Such a limit should not be
   greater than that applied to positive answers and preferably be
   tunable.  Values of one to three hours have been found to work well
   and would make sensible a default.  Values exceeding one day have
   been found to be problematic. ..."

So your response is an appeal to authority, which then cites nothing
to state why 1-3 hours is ok, and >24 is a problem.

The language is useful when it says "such a limit should not be
greater than that applied to positive answers" But it doesn't actually
tell us *why* Three Hours is a magic number.

The RFC is from 1998. The DNS has changed a bit since then.

Can you explain in a modern, 2016 DNS, why three hours is the "best"
time to chose, for this specific purpose?

(I can believe btw, its a good choice)


On Wed, Oct 19, 2016 at 8:54 AM, Mark Andrews <> wrote:
> In message <alpine.osx.2.11.1610181836450.35...@ary.qy>, "John R Levine" 
> writes:
>> >>> No.  They slow the leaks.  They do not STOP the leaks.  They depend on
>> >>> leaks to work.
>> >>
>> >> With a 24 hour TTL on the root zone, it ain't going to leak very much.
>> >
>> > The practical TTL is 3 hours.
>> How come?  This is a real question, unbound appears to believe the 24 hour
>> TTL.
> Because that is what RFC 2308 says to do with negative answers.
>> > But dummy stub zones (which is what is being I'm requesting) require
>> > changes in the root zone to add a insecure delegation to not break
>> > other things.  That requires IANA to be instructed to do so.
>> Hm, I see your point.
>> R's,
>> John
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET:
> _______________________________________________
> DNSOP mailing list

DNSOP mailing list

Reply via email to