top | item 8168243

A report on a DNS issue that was causing page redirections

34 points| amima | 11 years ago |blog.qbaka.com | reply

13 comments

order
[+] Decade|11 years ago|reply
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.

[+] Panino|11 years ago|reply
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.

[+] mcguire|11 years ago|reply
"Any request to .js file resulted in a valid javascript. This script was loaded and executed instead of Qbaka tracking script."

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
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.

[+] spindritf|11 years ago|reply
we cannot call every single internet provider around the world and ask them to drop DNS record from cache

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
The Google DNS was not affected, or more likely it was quickly flushed (I guess, the guys who made this error were the first to flush Google DNS).
[+] kelnos|11 years ago|reply
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.
[+] hjlklhj|11 years ago|reply
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.
[+] oasisbob|11 years ago|reply
Anyone know who the DNS provider was? This seems like a perfectly appropriate time to name and shame.
[+] amima|11 years ago|reply
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.
[+] PeterWhittaker|11 years ago|reply
Thanks for the detailed report, good lessons learned herein.