DNS cache does mitigate DDOS attacks on DNS providers, but the cache only SHOULD last for a short time.
The maximum time a resource record should be cached is specified by the server, called TTL.
The meaning of the TTL field is a time limit on how long an RR can be
kept in a cache. This limit does not apply to authoritative data in
zones; it is also timed out, but by the refreshing policies for the
zone. The TTL is assigned by the administrator for the zone where the
data originates. While short TTLs can be used to minimize caching, and
a zero TTL prohibits caching, the realities of Internet performance
suggest that these times should be on the order of days for the typical
host. If a change can be anticipated, the TTL can be reduced prior to
the change to minimize inconsistency during the change, and then
increased back to its former value following the change.
(taken from RFC 1034)
The server can tell the resolver that the record can be cached for over 68 years, which is usually long enough for an attack to be fixed. But servers usually don't do so. Big websites don't want a failure in the network to affect them for a long time. One way to do so is to set the TTL of their resource records to a relatively short time, such as 5 minutes. That way, they can to change their DNS record in case some of their servers fail. And clients querying the RR every 5 minutes isn't much overload than querying it only once.
Additionally, the applications usually cache the RR in RAM. So the records are lost once the application is restarted. (There are exceptions. You can dump BIND's cache to the filesystem for example.)
I want to mention Namecoin here. It stores domain names on the disk, in a blockchain. If your website uses a .bit domain, it is unlikely to go down solely because of the DNS provider.