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) -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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
