[dns-operations] EC2 resolver changing TTL on DNS answers?

[Paul Vixie]

Colm MacCárthaigh wrote:
>
>
> On Tue, Nov 28, 2017 at 9:14 PM, Giovane C. M. Moura
> <giovane.moura at sidn.nl <mailto:giovane.moura at sidn.nl>> wrote:
>
>     And I wonder how manipulating TTLs on the resolver side can actually be
>     an issue during a major DDoS attack. I mean, shorter TTLs may lead to
>     caches on applications/stub resolvers/recursive resolvers to expire much
>     more quickly, which under normal operations are fine, but we may be
>     discarding prematurely a valid  answer that could  be an issue during a
>     major DDoS against authoritative servers (any thoughts on that?).
>
>
> This is a good concern! It's actually fairly easy to mitigate though -
> when you can't reach an authoritative server, be willing to serve the
> most recent, but stale, cache entry. In practice this is much more
> resilient and overall better than returning SERVFAIL to clients.

so, takedown of criminal domains has to be by removal of the delegation, 
because if all we can do is disrupt connectivity to the servers, 
previously-cached records will be immortal? since criminal domains are 
taken down many times per day, and authority server ddos attacks are 
somewhat more rare, i think this is the wrong optimization.

also:

i'd like to think that hierarchical autonomy would mean that i, as a 
zone publisher, would be in sole control of how long my data is cached. 
if rdns operators want to negotiate, by protocol, over longer leases, 
then by all means let's make that possible.

finally:

it's worth noting that people who are not in the dns business per se 
still depend on the dns and may be depending on documented behaviour of 
the dns -- but may not feel a need to participate in this mailing list. 
in other words, beware of the echo-chamber effect in these discussions.

-- 
P Vixie