Someone bought 'Google.com' from Google for one minute(finance.yahoo.com) |
Someone bought 'Google.com' from Google for one minute(finance.yahoo.com) |
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.
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.
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)
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
Do you have the same behavior in a private window?
[1] http://www.doublewide.net/
[2] http://www.bloomberg.com/apps/news?pid=newsarchive&sid=at_jl...
http://www.npr.org/2014/04/01/297690717/why-doesnt-america-r...
How is that any different than walking in to someone's house and leaving them $20 for the TV you took? It seems to me that "oops, take-backs" Is not a legitimate enough justification to reverse a transaction under contract law.
It seems rather ominous if even this kind of situation is permitted because it sets a precedent that corporations can simply decide to change their mind when something is not in their favor. Sure, it's an example that many people will simply rationalize or defend, but just on matters of assuring the credibility of the integrity of the whole market based system, Google should not be allowed to simply step away from this as if nothing happened without at least a fine that gets noticed by the executive suite.
How would you feel if in the future mega consolidated food corporation can arbitrarily decide that "oops, we changed our mind. That food you ate and sold to you for $X should have really been charged at $3X. Don't worry, we will charge your account. Have a nice day"
How about a different scenario; the airline industry decides that "oops, someone else was willing to pay more for that last seat on that flight you just booked. We just cancelled it and refunded your money. Have a nice day"
I get that it was probably a mistake of some kind. But what is it that immunizes corporations from the consequences of mistakes? I guess that's kind of rampant right now in our society and economy, but still.
http://technology.ie/google-ie-hijacked/
The ccTLD register (The IEDR) had a vulnerability in their management portal that was exploited (I believe it was an SQL injection if I recall correctly).
The attacker changed the DNS servers to their own and then put an A name record pointing google.ie to their own server.
The server just displayed a hijacked by page.
It was probably just some kid. If it was a criminal they would have done some thing far more malicious.
yahoo.ie also got hijacked.
It was an absolute pain, for months after the IEDR's portal was disabled, you had to call them to make any changes to any .ie domain.
https://www.linkedin.com/pulse/i-purchased-domain-googlecom-...
Edit: Here's a mirror for those that happen to have linkedin.com nullrouted in hosts or something: https://archive.is/HKPhn
Your comment implies that the sale should have gone through anyway, which is nonsensical. Otherwise we could have situations where I steal foo.bar from you (which you have registered with, say, NameCheap) by buying it through, say, GoDaddy, which is currently experiencing a similar bug that incorrectly marks your domain as available.
... I find the choice of words funny. If he hadn't bothered to buy a domain he knew he would never be able to keep, there would be no ordeal!!!
There is also the counterpoint of the case of Nissan Motor Co vs. Nissan Computer Corp [1] where Nissan Motors owns the trademarks but have not been granted nissan.com.
[0] https://www.icann.org/resources/pages/policy-2012-02-25-en#4 [1] http://www.internetlibrary.com/cases/lib_case292.cfm
Google.com should be fine until 2020, but I randomly looked up some of their ccTLDs and a lot of them are set to expire in less than a year. Google.co.uk has only four months left.
I wonder why large companies with deep pockets don't just register all of their domains for the maximum duration. There are a few ccTLDs that only allow 1-2 year renewals, but those are few and far between. Most domains can be renewed for 5-10 years at a time.
However, most big companies use someone like Netnames, MarkMonitor, etc, who simply wouldn't let a domain drop, even if nobody asked them to renew it - instead they'll renew it themselves, keep it active, and simply add it to the next invoice.
Mistakes can and do happen in business all the time, because businesses are composed of people and people aren't perfect. The solution is to deal with mistakes in whatever is the most sane way.
Let's say you're selling a 10$ gift card on your website but through some bug/error it's now worth 1000$ (an easy mistake to make, just forget the decimal place). What if someone bought the 1000$ worth gift card for the original intended price of 10$? I'm sure you would invalidate that purchase and send them an email explaining that it was a mistake, and it would be perfectly within your rights to do so.
It goes both ways too, if a mistake is made that advantages the seller, they have to fix it.
Vertical integration just means that Chrome cooperates more with Google's webadmins than Twitter's.
Just to clarify, Nissan Computers also holds trademarks but in a difference field of commerce.
Just like Volkswagen and Canon both hold trademarks on Eos.
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.
Note: exact same browser session, minutes apart.
It sucks because now your employee can MITM you for gmail/google chat/etc
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.
You can also setup a rouge DHCP server that sends a different DNS address.
There are likewise many other methods.