This is exactly the sort of issue that's supposed to be eliminated by DNSSEC validation.
The registrar's database gets corrupted? They are not hosting my DS records, anyway. That's in the top-level domain. You will be the least of anybody's worries if the top-level domain dies. And as long as the DS record is live, a validating nameserver can tell that the faulty DNS server is sending incorrect resource records, and should be disregarded.
Side note: My DNS server is a hidden master, that publishes zones via secondary servers, run by separate companies.
The corruption would still be disruptive, but it would not be such a disaster.
This is exactly the sort of issue that's supposed to be eliminated by DNSSEC validation.
Emphasis on "supposed to be," because what DNSSEC brings to the table in practice is headaches and outages. You won't see stories on HN about the IETF, NASA or entire TLDs going down due to DNSSEC because it's normal, expected.
I am almost sure that the reasoning for the redirect script was something like this: since they have ads on that "parking" page, whoever tries to access the server, should see the ads. That's probably why they have this terrible redirection script in place. Which still keeps the original question "who would do that", because this is terrible.
The TTL value has no direct connection to the parking page. It's probably by the coincidence that DNS record had a high TTL and pointed to that IP address. But no one can be sure here, because there is always a posibility that DNS was hacked, although the DNS hosting provider sais that DNS error was not a result of a hack.
One semi-solution to that (which would have made the problem almost invisible to any webpage visitors) would be to only serve the script over HTTPS. Presumably the domain parking page was not using a cert that matched "cdn.qbaka.net", so a browser would fail to download anything due to a cert mismatch.
That was my original thought as well but since cdn.qbaka.net was just a cname to their real cdn it wouldn't have worked. Unless they gave their private ssl key to the cdn provider, which is really not recommended.
No point in shaming, anyone can experience this kind of problem. Even Google once marked all websites as "contains virus", and Amazon cloud was unavailable due to a storm. It was not the well known domain name registrar's DNS.
[+] [-] Decade|11 years ago|reply
The registrar's database gets corrupted? They are not hosting my DS records, anyway. That's in the top-level domain. You will be the least of anybody's worries if the top-level domain dies. And as long as the DS record is live, a validating nameserver can tell that the faulty DNS server is sending incorrect resource records, and should be disregarded.
Side note: My DNS server is a hidden master, that publishes zones via secondary servers, run by separate companies.
The corruption would still be disruptive, but it would not be such a disaster.
[+] [-] Panino|11 years ago|reply
Emphasis on "supposed to be," because what DNSSEC brings to the table in practice is headaches and outages. You won't see stories on HN about the IETF, NASA or entire TLDs going down due to DNSSEC because it's normal, expected.
[+] [-] mcguire|11 years ago|reply
Who would do that?
"The TTL value of the corrupted DNS record was one week."
For a parking page? Who would do that?
[+] [-] amima|11 years ago|reply
The TTL value has no direct connection to the parking page. It's probably by the coincidence that DNS record had a high TTL and pointed to that IP address. But no one can be sure here, because there is always a posibility that DNS was hacked, although the DNS hosting provider sais that DNS error was not a result of a hack.
[+] [-] spindritf|11 years ago|reply
Google allows users to flush a record from their cache https://developers.google.com/speed/public-dns/cache which is better than nothing, especially if you use Google's resolvers on your servers.
[+] [-] amima|11 years ago|reply
[+] [-] kelnos|11 years ago|reply
[+] [-] hjlklhj|11 years ago|reply
[+] [-] oasisbob|11 years ago|reply
[+] [-] amima|11 years ago|reply
[+] [-] PeterWhittaker|11 years ago|reply