[kcen]

The DNS was not exactly hijacked, there were issues inside of LinkedIn's top level DNS provider whom were delegating www.linkedin.com authorization to unauthorized nameservers, namely NS[SOMETHING].ztomy.com. The ztomy DNS replaces its delegated domains to point to a domain parking page if there is no record exiting. These changes were then propagated to other nameservers and thus to the end user. End result, dns doesn't point where you think it does.

[inopinatus]

Au contraire; having the delegation going somewhere unwanted is practically the definition of a DNS hijack. The question is - how did that happen? A malicious third party? a blundering sysadmin? or a bug in some provisioning code?

It does sound like LinkedIn's NOC are playing the blame game already. Well, I guess they've gotta get all those spamming recruiters & sales reps back online.

EDIT: heh, maybe it was The New Guy: http://www.simplyhired.com/job-id/y5bvoz46k6

[kcen]

It's always the new guy, f'n new guy.

[yannk]

ahaha, the job posting is a good find. We'll know if you are right if tomorrow a different add asking for "Total badass, Expert guru knowledge of Bind 9"

[gravitronic]

That makes sense since we just saw the same problem with USPS realtime shipping rates via production.shippingapis.com, which seems like an odd attack target.

edit: and I mean the exact same issue, it was resolving to a confluence owned IP that was serving a squatter page for the domain.

[dsl]

You used a lot of the right words, but not in the right context. Could you share your source do we can get the full picture?