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

[Colm MacCárthaigh]

On Tue, Nov 28, 2017 at 11:29 PM, Paul Vixie <paul at redbarn.org> wrote:

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

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.

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.

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

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.



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


We have a really tight feedback loop with our customers - we hear problem
reports and feature requests efficiently I think :)

-- 
Colm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20171129/139372c3/attachment.html>