Big companies that rely on Internet presence are quite pro-active, and there are teams of people whose job is to prevent something like this from happening in the first place.
DNS is not a secure protocol, and you can redirect connections intended for google.com from the same local network easily, yet the world still keeps turning.
You can also setup a rouge DHCP server that sends a different DNS address.
There are likewise many other methods.
It's also advised to do so for unauthenticated users on shared/public wifi so that you can provide an agreement page/site. Also, so that unauthenticated users can't use DNS as a tunnel method, which is pretty damned cool, but insecure.
You can put TLS into a DNS tunnel too, it's just even slower.
Reading that along with the rest of this thread reminds me just how bad it is to have so much of the internet rely on large sites like this. The amount of trust and dependency that rests on Google is very dangerous. The amount of damage to the world that could result in a failure of their service is beyond imagination.
Vertical integration just means that Chrome cooperates more with Google's webadmins than Twitter's.
This looks like because Google's domain selling tool thought he bought the domain, he was authorized for the domain for all the rest of the Google tools, which is scary, but probably not earth shattering. Kind of depends on what you can do in the tools to send people to another site.
If they actually hijacked the domain, they would probably kill their DNS servers, but they could do a lot of things; including likely get some domain control certificates (but likely not from the registrars Google pins to, and a lot of people have google's certificate pins)
It sucks because now your employee can MITM you for gmail/google chat/etc
This somehow reminds me about Gamil [0]
http://www.spiegel.de/netzwelt/web/domain-gekapert-google-un...
Clients and caches sometimes disregard the TTL or use their own, so sometimes changes to a record "haven't propagated" to some clients, but what's really going on is something that's supposed to keep its info fresh decided not to.
Though it's possible for clients to get out of date, the story of a built-in propagation speed you can't do anything about is based on misconceptions. The record owner has a lot of say in how and when their records get refreshed.
Resolver libraries and daemons keep cached results in volatile memory, so in practical terms, if a high TTL is set, the spoofed result will continue to be used until the given machine is rebooted. For some middle boxes, this can be years.
[1] RFC 1035 section 2.3.4 https://www.ietf.org/rfc/rfc1035.txt
I think what really tends to happen, and this gets the folks confused, is that the initial TTL is high (say, 3 days), then the sysadmin wants to do some changes, and because they want to be able to keep changing the IP quickly, while they're working on it, they set the TTL low (say, 1 minute). Only you cannot retroactively lower the TTL of the records that have been sent previously, they'll expire whenever during the following 3 days.
Your point still stands, mostly. The probability of the old record with a high TTL to be evicted from a resolver's cache during any given short period of time is low.