Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, George Michaelson writes:
> 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.

I didn't say 24 hours is a problem.  I stated the practical limit
is / will be 3 hours as that is what is the default negative cache
limit is.

> 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?

Because it a trade off in how long people are prepared to wait for
new names to become visible.  People don't like waiting a day.  3
hours is a stretch.

> (I can believe btw, its a good choice)
> 
> -G
> 
> On Wed, Oct 19, 2016 at 8:54 AM, Mark Andrews <[e-mail]> wrote:
> >
> > In message <[e-mail]>, "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: [phone]                 INTERNET: [e-mail]
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]