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

[Paul Vixie]

Colm MacCárthaigh wrote:
...
> DDOS attacks against authoritative DNS servers are not rare though, ...

if i said they were rare in any absolute sense then i was confused. i 
meant only that they are rarer than criminal domain takedowns.

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

my thinking about ttl stretching and rrset leasing are here:

https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f

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

indeed, takedown is already quite difficult -- the advantage is right 
now to the criminals, whose costs are lower and whose benefits are 
higher. anything that adds costs to takedown will raise my eyebrows.

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

so in order to protect one kind of target (adns) from many kinds of 
ddos, you're advocating a vast increase in rdns and resulting system 
complexity?

i think on a cost/benefit basis we would be better off asking amazon, 
google, microsoft, yahoo, and netflix to require fully audited BCP38 
compliance by all of their BGP peers, including their transit providers. 
and of course they'd have to implement BCP38 internally.

we also need to get DNS RRL installed on all authority servers, since 
many ddos's against an authority server are reflected through other 
authority servers, and some attacks relay on saturating the victim 
authority server with queries so that it will ddos its own output path.

perhaps it's out-of-style to try to solve the underlying problem rather 
than band-aiding the symptoms. but whenever added systemic complexity is 
proposed, we should urge the former, and avoid the latter.

see also: https://queue.acm.org/detail.cfm?id=2578510

>     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 :)

i really don't want to change the internet system design to facilitate 
your work with your customers, unless there is no burden passed to 
others by doing so. what we need to remember is that those others are 
not here to argue for their needs. their absence isn't their 
nonexistence. their silence isn't their unconcern.

-- 
P Vixie