<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 28, 2017 at 11:29 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">This is a good concern! It's actually fairly easy to mitigate though -<br>
when you can't reach an authoritative server, be willing to serve the<br>
most recent, but stale, cache entry. In practice this is much more<br>
resilient and overall better than returning SERVFAIL to clients.<br>
</span></blockquote>
<br>
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.<br></blockquote><div><br></div><div>DDOS attacks against authoritative DNS servers are not rare though, unfortunately.  You can lower the TTLs you present to stubs/clients, but still use the "real" TTL to decide just how long to cache a stale entry for. You can also cap the "immortal" in general.</div><div><br>Also at scale, with dedicated security teams, invalidation, and automation that can identify problem domains and block them pro-actively, there can be much more in place than relying on up-stream take-downs too. The balance of everything together still has to work well, of course. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>I think on balance, I would still prefer if every resolver served from stale cache when auth DNS becomes unreachable, rather than return SERVFAIL, at least for a few hours. You're right that that means a domain that's being taken down may persist, but if we can take down the DNS servers, is taking down the web servers (or whatever) ... really harder or more complex? I also think that hi-jackers and criminals can use high TTLs to evade that technique anyway; so blocking criminal domains really needs integration at the resolver level to be effective. On the other hand, a DDOS attack against auth DNS needn't be so crippling and some answer that a client may be able to reach, is better than none. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
finally:<br>
<br>
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.</blockquote><div><br>We have a really tight feedback loop with our customers - we hear problem reports and feature requests efficiently I think :) </div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Colm</div>
</div></div>