<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 24, 2016 at 3:06 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Jared Mauch wrote:<br>
>       I'm wondering if anyone else implements the TTL=0 behavior so we<br>
> can investigate that to keep end-customer impacting issues to a minimum.<br>
><br>
>       I don't want to serve up invalid data, but keeping last known<br>
> with TTL=0 seems a fair response given enough resources to not have<br>
> that answer expired or invalidated with alternate data.<br>
<br>
</span>many domain names or rrsets need badly to be taken down, for the good of<br>
the internet. this "use stale data at ttl=0" is exquisitely wrong headed.<br></blockquote><div><br></div><div>It seems like we actually need two different TTLs:</div><div>  - how long before we want the client to refresh their cache: O(seconds/minutes) for agility</div><div>  - how long we want the client to remember our latest answer: O(hours/days) for availability</div><div><br></div><div>Is there anything in the protocol today that would support this, or is there interest in adding it?</div><div><br></div><div>Damian</div></div></div></div>