You apparently don't understand DNS. DynDNS is a very reputable DNS provider that twitter and many others use. For someone to take them down requires a massive amount of effort. Running a redundant DNS provider is expensive as all hell.
While 'expensive' is a relative term, I disagree that it's cost-prohibitive for most firms, as I looked into this specifically (ironically considered using Dyn as our secondary). The challenge isn't coming up with the funds, it's if you happen to use 'intelligent DNS' features; these are proprietary (by nature) and thus they don't translate 1:1 between providers.
In addition to having to bridge the divide yourself, by analyzing the intelligent DNS features and using the API from each provider to simultaneously push changes to both providers, you have to write and maintain automation/tooling that ensures your records are the same (or as close as possible) between the providers. If you don't do this right, you'll get different / less predictable results between the providers, making troubleshooting something of a headache.
Thus in that case the 'cost' in man effort (and risk, given that APIs change and tooling can go wrong) in addition to the monthly fee.
If all you're doing is simple, standard DNS (no intelligent DNS features), it's not as hard, and it's just another monthly cost. Since you typically get charged by queries/month, if you run a popular service you're probably well able to afford the redundancy of a second provider.
The sarcasm is curious. It's a business decision. Either your revenue is high enough that the monetary loss from a several-hour intra-day outage is potentially worse than the cost of said redundancy, or you don't care enough to invest in that direction (it's expensive).
Making things redundant is exactly a core piece of what infrastructure engineering is. I guess with the world of VPSes and cloud services, that aspect is being forgotten? And yes, redundancy / uptime costs money!
It may, at scale, be like 100% (one provider), 55%+55% (two) and 40%+40%+40% (three). Still eminently affordable.
Route53 on AWS is $0.50/zone and $0.40/million queries. API integration is also very easy.
Using something like Route53 as a backup is significantly cheaper than suffering from the current Dyn outage.
$ dig -tNS github.com @8.8.8.8
; <<>> DiG 9.8.3-P1 <<>> -tNS github.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15616
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;github.com. IN NS
;; ANSWER SECTION:
github.com. 899 IN NS ns-1283.awsdns-32.org.
github.com. 899 IN NS ns-1707.awsdns-21.co.uk.
github.com. 899 IN NS ns-421.awsdns-52.com.
github.com. 899 IN NS ns-520.awsdns-01.net.
github.com. 899 IN NS ns1.p16.dynect.net.
github.com. 899 IN NS ns2.p16.dynect.net.
github.com. 899 IN NS ns3.p16.dynect.net.
github.com. 899 IN NS ns4.p16.dynect.net.
;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Oct 21 13:01:48 2016
;; MSG SIZE rcvd: 248
$ dig -tNS twitter.com
; <<>> DiG 9.8.3-P1 <<>> -tNS twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62729
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;twitter.com. IN NS
;; ANSWER SECTION:
twitter.com. 75575 IN NS ns3.p34.dynect.net.
twitter.com. 75575 IN NS ns4.p34.dynect.net.
twitter.com. 75575 IN NS ns1.p34.dynect.net.
twitter.com. 75575 IN NS ns2.p34.dynect.net.
;; ADDITIONAL SECTION:
ns3.p34.dynect.net. 54698 IN A 208.78.71.34
ns4.p34.dynect.net. 81779 IN A 204.13.251.34
ns1.p34.dynect.net. 8544 IN A 208.78.70.34
ns2.p34.dynect.net. 54775 IN A 204.13.250.34
;; Query time: 0 msec
;; SERVER: <local>
;; WHEN: Fri Oct 21 13:02:14 2016
;; MSG SIZE rcvd: 179> Running a redundant DNS provider is expensive as all hell.
What makes you think that?