How has app.net adoption been going?
LinkedIn suffers DNS hijack
21–30 of 95 posts
Re: LinkedIn suffers DNS hijack
#22The 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 doe…
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
Re: LinkedIn suffers DNS hijack
#23I guess they didn't mark their cookies as 'Secure'. Oh well, the real story here is an app.net link at #1 on HN.
Looks like app.net isn't perfect either. Their HSTS isn't implemented correctly. Only 'alpha.app.net' and 'join.app.net' are protected while 'app.net' is not. They fell into one of the common pitfalls with their http->https redirects: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-p...
You can verify this at: chrome://net-internals/#hsts
Re: LinkedIn suffers DNS hijack
#24I guess it's a good thing I never reset my LinkedIn password after they lost them all, so I don't have a LinkedIn account to be hijacked.
Re: LinkedIn suffers DNS hijack
#25Can anyone think of a good reason LinkedIn didn't mark their cookies as HTTPS-only? http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly
They forgot?
Re: LinkedIn suffers DNS hijack
#26The 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 doe…
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…
It's always the new guy, f'n new guy.
Re: LinkedIn suffers DNS hijack
#27Someone turned off the 'more magic' switch...
Re: LinkedIn suffers DNS hijack
#28 DNS hacks on big public companies seems like a big security oversite form the linkedin team. wow.
Perhaps my HTTPS anywhere extension could have helped folks.
Re: LinkedIn suffers DNS hijack
#29Earlier quoted context omitted.
> Oh well, the real story here is an app.net link at #1 on HN. I can't tell if this is sarcasm or a serious comment. Could you elaborate on this comment? I don't get why a link by app.net would be news worthy.
My understanding is app.net is trying to be a paid version of twitter. There was/is much debate whether it could ever take off. This is the first time I've ever seen someone link to it. Although now I realize that the link is to the app.net cofounder so that doesn't really say much.
OP works there according to his twitter feed.
Re: LinkedIn suffers DNS hijack
#30Random anecdote:
One of the DNS issues I tried to fix with NIS+ was the 'maintaining a list of trusted servers' problem by distributing the management of the authoritative servers. Trust was built bottom up, and authority came top down.
The way it worked was that clients used a 'coldstart' file which was the (small number) of servers you trusted to provide your namespace lookups. You to their public key and you put it into your coldstart file. Similarly, a server put the key(s) of the servers it trusted above it in the name space in its coldstart file. And at company 'root' level was a set of servers run by a trusted authority.
Locating the authoritative name server for x.y.z from p.q.z (same as DNS root is rightmost) client in x.y.z asks its server for a trusted y.z server, gets it, and asks that server for a trusted z. server, then asks that server for a q.z. server and finally for a p.q.z. server. Once this has happened once you know trusted servers can can jump to the nearest one to start resolving a new path in the namespace.
It was slower on initial lookup and then just as fast as DNS on later ones.
It had the downside that compromised (or borked) high level servers could send you on a different path to different root if the server above them was incorrect.
It is one of the more fun problems in the whole name/directory service space.