So, my immediate thought on reading each of these points is:
"* servers in multiple data centers and close to your end customers"
"* multiple backbone providers"
If you need both of these for DNS, then you need both of these for all of your other services, right? Or it's pointless to have bulletproof DNS. If you don't have multi-homed web service, an outage of your server is still going to take you off-line, regardless of whether you have working DNS or not. Likewise email, database, etc. I think one should have a backup hold and forward mail server, and that should also act as your secondary DNS server. And it should be in a different data center.
As for locality-based DNS, what name service software do you think people are using that they can choose a DNS server close to them? That data isn't available when the decision for which DNS server to use is selected. So, having DNS service close to clients is roughly pointless. And, the services that CAN be locality-aware (pretty rare and esoteric) almost universally use DNS records to achieve it. So, DNS would be the one service that cannot possibly benefit from being available in a bunch of different locations around the world (except by accident).
"* some idea of what to do when your first DOS attack hits"
What to do when the first DoS hits is to try to figure out how the hell to fix the web server or database or whatever it is that actually has trouble dealing with the load. DNS isn't going to be the attack vector or a source of trouble. DNS records are tiny, heavily cached all over the world (so you regular users would be roughly immune to a DNS DoS), and very very cheap to serve. BIND named (by no means the fastest DNS server) provides almost all of the worlds root name service on a few dozen machines. That's billions of requests every day. A DoS would saturate your network before it would take out BIND.
"* a sysadmin who monitors all this stuff and gets paged when it fails"
So, you don't need one of those for your web application or email or databases?
I'm not saying having outside secondaries is a bad thing, I just don't understand the benefits to outsourcing something so fundamental to the success of your website--DNS can make seconds worth of difference in the response time of your site. Why trust some random dudes with that?
So, there's nothing wrong with using them for secondary service. I just don't know that I'd want to trust primary service to somebody else.
I agree with nearly every point you've made here, except that you're not considering cost. Remember that I said:
"You might say this is overkill for a new startup, but when we can get all this for $50/year or less..."
DNS is the most straightforward and undifferentiated service you'll need to run your site. There's little distinction between competing providers unless you're looking for massive capacity or exotic services. I can get all of the points I listed from EasyDNS for $20/year.
I can't think of another service, with the possible exception of email, where the benefit/cost ratio is so high. And as long as those random dudes are in the full time business of running DNS, I'd much rather have them do it than someone who's not a expert and has a much longer, higher value list of things to concern themselves with.
"* servers in multiple data centers and close to your end customers"
"* multiple backbone providers"
If you need both of these for DNS, then you need both of these for all of your other services, right? Or it's pointless to have bulletproof DNS. If you don't have multi-homed web service, an outage of your server is still going to take you off-line, regardless of whether you have working DNS or not. Likewise email, database, etc. I think one should have a backup hold and forward mail server, and that should also act as your secondary DNS server. And it should be in a different data center.
As for locality-based DNS, what name service software do you think people are using that they can choose a DNS server close to them? That data isn't available when the decision for which DNS server to use is selected. So, having DNS service close to clients is roughly pointless. And, the services that CAN be locality-aware (pretty rare and esoteric) almost universally use DNS records to achieve it. So, DNS would be the one service that cannot possibly benefit from being available in a bunch of different locations around the world (except by accident).
"* some idea of what to do when your first DOS attack hits"
What to do when the first DoS hits is to try to figure out how the hell to fix the web server or database or whatever it is that actually has trouble dealing with the load. DNS isn't going to be the attack vector or a source of trouble. DNS records are tiny, heavily cached all over the world (so you regular users would be roughly immune to a DNS DoS), and very very cheap to serve. BIND named (by no means the fastest DNS server) provides almost all of the worlds root name service on a few dozen machines. That's billions of requests every day. A DoS would saturate your network before it would take out BIND.
"* a sysadmin who monitors all this stuff and gets paged when it fails"
So, you don't need one of those for your web application or email or databases?
I'm not saying having outside secondaries is a bad thing, I just don't understand the benefits to outsourcing something so fundamental to the success of your website--DNS can make seconds worth of difference in the response time of your site. Why trust some random dudes with that?
So, there's nothing wrong with using them for secondary service. I just don't know that I'd want to trust primary service to somebody else.