In message <cakr6gn384nystxcoo7-qhm7e_+34p-0wp3vfkpkz-0hzoan...@mail.gmail.com>, 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 <ma...@isc.org> 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: ma...@isc.org > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
