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

[Robert Edmonds]

Paul Vixie wrote:
> 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.

According to the list description:

    https://lists.dns-oarc.net/mailman/listinfo/dns-operations

    An open public forum for informal reporting, tracking, resolving,
    and discussing DNS operational issues including outages, attacks,
    errors, failures, and features. Note that discussion of non-ICANN
    root systems is explicitly off-topic.

    Subscription requests from which a natural person is not readily
    identifiable will be subject to moderation and may be asked for
    additional verification.

The only banned topic is discussion of non-ICANN roots, and it doesn't
say that "features" means only currently existing features. So I take it
that discussion of hypothetical features (especially ones that would
help ameliorate operational issues like outages, attacks, and failures)
is on-topic on this list.

> 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.

Hardly ever is not never (for instance: the 42 day TTLs in the
root-servers.net zone, the 2 day TTLs on delegations from most TLDs, the
4 day TTLs on ns[1-4].google.com), not to mention that this would be a
protocol break.

> 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.

This would not be particularly useful since it would be common to want
both a small negative TTL (on the order of seconds/minutes, for agility)
combined with a long serve-stale time (on the order of hours/days, for
availability). And it wouldn't be able to express policy for serving
stale negative answers.

The easiest thing to do would be to specify a "stale time" EDNS option
that the client sets with no data to indicate support, and in response
the server sets the option with a single value to indicate the number of
seconds that stale RRsets from the response could be retained past the
expiration of the TTL and returned if the authority is subsequently
unreachable. (The only downside is that this would apply to all RRsets
in the response, which isn't too bad.)

-- 
Robert Edmonds