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

[João Damas]

If you think of a recursive resolver as a sort of slave server for a subset of the zone, then the parameters that the master express in the zone’s SOA that indicate for how long the master is happy for the slaves to do each thing (refresh, negate, drop, etc) should be a good starting point, at the expense of having to do an SOA query to obtain said parameters.

Joao

> On 25 Oct 2016, at 10:56, Paul Vixie <paul at redbarn.org> wrote:
> 
> 
> 
> Dave Warren wrote:
>> On Mon, Oct 24, 2016, at 15:06, Paul Vixie 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.
>> 
>> I wonder if these concerns could be negated by only applying the "use
>> stale data" logic when all authoritative servers timeout (or maybe also
>> a SERVFAIL?), but a REFUSED, NOERROR, NXDOMAIN would still be handled
>> with current logic?
> 
> yes, i think there's likely some safe way to do this. my caution about
> it is because of the expansion of the number of moving parts, and the
> added difficulty for diagnostic personnel to understand what's where and
> why. for background on that, consider the complexity arguments here:
> 
> http://queue.acm.org/detail.cfm?id=1242499
> 
>> I don't think we need to deal with configuration errors, or anything of
>> that sort, the goal would be only to deal with negating the impact of a
>> DoS attack. Of course, getting services to use TTLs of reasonable
>> lengths would also help, but I somehow don't see that happening either.
> 
> i think the best way to do this is without any signalling change. just
> use the TTL for expiration, and use some other interval like 10% of the
> TTL or 3X the SOA MINIMUM for re-fetch. but you'd only do this for
> things in the cache that actually get used a lot.
> 
> in other words this can be a resolver improvement with no protocol change.
> 
> -- 
> P Vixie
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations