<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 24, 2016 at 4:01 PM, Mark Andrews <span dir="ltr"><<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">In message <<a href="mailto:580E8CC5.9010909@redbarn.org">580E8CC5.9010909@redbarn.org</a>><wbr>, Paul Vixie writes:<br>> Damian Menscher wrote:<br>
> >     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<br>
> >     headed.<br>
> ><br>
> > It seems like we actually need two different TTLs:<br>
> >   - how long before we want the client to refresh their cache:<br>
> > O(seconds/minutes) for agility<br>
> >   - how long we want the client to remember our latest answer:<br>
> > O(hours/days) for availability<br>
> ><br>
> > Is there anything in the protocol today that would support this, or is<br>
> > there interest in adding it?<br>
><br>
> this is dns-operations@, where questions of this nature aren't on-topic.<br>
> however, i'll bite:<br>
><br>
> the current TTL is 32 bits unsigned, and i'd be very happy to see it<br>
> split into two 16-bit unsigned quantities. TTL longer than 65535 is<br>
> hardly ever operable.<br>
<br>
</span>65535 is ~18 hours which is way too small for max retension.<br>
<br>
A 19/13 split could work.  A couple of hours for newness and nearly<br>
a week for max retention.</blockquote><div><br></div><div>Uneven splits sound icky -- if we were designing a new protocol I could imagine doing it with either:</div><div>  - [long|short] --> max_retention=2^long, min_refresh=2^short</div><div>  - [long|short] --> max_retention=long*short, min_refresh=short</div><div><br></div><div>But we're not designing a new protocol, and flipping high-order bits will cause older recursors to do the wrong thing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">
> the SOA MINIMUM is currently almost this, but only for negative answers.<br>
> expanding it to be used for positive answers as well could be done<br>
> without a wire-change.<br></span></blockquote><div><br></div><div>Right, this is the direction I was leaning.  Or maybe stuff extra details in an additional record?  Something to do with EDNS?  I don't know the protocol... just noting that there appears to be a use-case, and a limited amount of extensibility we might be able to utilize.</div><div><br></div><div>Damian</div></div></div></div>