Warren Kumari wrote: > ... I think > that the actual algorithm specified is a secondary consideration -- > first we need to agree on if the concept / idea is good for general > use.
that will depend on the algorithm. for example if it's only stretchy for timeouts and servfail, but nxdomain is authoritative as before, then the best-case and worst-case outcomes are suitable for eachother, and general use could not be worse than googledns, opendns, and akamai all doing it with apparent success. since it allocates no code point and the method requires no interop, this draft feels a bit like resimprove, which died on the vine for no reason i can now recall. it's harmless as an FYI, but does not belong on the standards track. speaking of resimprove, i hope you'll include in this draft the idea of using delegation-TTL as a delegation-recheck interval, and using an authoritative NXDOMAIN from the delegator as proof that you need to run an "rm -rf" in your cache. i bring this up because we need to be able to kill more cached data faster-- the opposite of stretchiness-- for abuse control reasons. if you're going to soften the signaling for cache expiration, you really ought to balance that out with this simple method of also hardening it. -- P Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
