<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 28, 2017 at 9:14 PM, Giovane C. M. Moura <span dir="ltr"><<a href="mailto:giovane.moura@sidn.nl" target="_blank">giovane.moura@sidn.nl</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And I wonder how manipulating TTLs on the resolver side can actually be<br>
an issue during a major DDoS attack. I mean, shorter TTLs may lead to<br>
caches on applications/stub resolvers/recursive resolvers to expire much<br>
more quickly, which under normal operations are fine, but we may be<br>
discarding prematurely a valid  answer that could  be an issue during a<br>
major DDoS against authoritative servers (any thoughts on that?).<br></blockquote><div><br></div><div>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.</div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Colm</div>
</div></div>