[dns-operations] TTL=0; Last known good answer (Re: dns retries amplify attack)

[Damian Menscher]

On Mon, Oct 24, 2016 at 4:01 PM, Mark Andrews <marka at isc.org> wrote:

> In message <580E8CC5.9010909 at redbarn.org>, Paul Vixie writes:
> > Damian Menscher wrote:
> > >     many domain names or rrsets need badly to be taken down, for the
> good of
> > >     the internet. this "use stale data at ttl=0" is exquisitely wrong
> > >     headed.
> > >
> > > It seems like we actually need two different TTLs:
> > >   - how long before we want the client to refresh their cache:
> > > O(seconds/minutes) for agility
> > >   - how long we want the client to remember our latest answer:
> > > O(hours/days) for availability
> > >
> > > Is there anything in the protocol today that would support this, or is
> > > there interest in adding it?
> >
> > this is dns-operations@, where questions of this nature aren't on-topic.
> > however, i'll bite:
> >
> > the current TTL is 32 bits unsigned, and i'd be very happy to see it
> > split into two 16-bit unsigned quantities. TTL longer than 65535 is
> > hardly ever operable.
>
> 65535 is ~18 hours which is way too small for max retension.
>
> A 19/13 split could work.  A couple of hours for newness and nearly
> a week for max retention.


Uneven splits sound icky -- if we were designing a new protocol I could
imagine doing it with either:
  - [long|short] --> max_retention=2^long, min_refresh=2^short
  - [long|short] --> max_retention=long*short, min_refresh=short

But we're not designing a new protocol, and flipping high-order bits will
cause older recursors to do the wrong thing.

> the SOA MINIMUM is currently almost this, but only for negative answers.
> > expanding it to be used for positive answers as well could be done
> > without a wire-change.
>

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.

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20161024/5e3dcab6/attachment.html>