Hacker News Reader

Comment by Jamiecon | Hacker News Reader

Looking at your profile, which indicates you are technically proficient, I'm struggling to understand how you have come to the conclusion in the headline. Unless you're just looking for attention, in which case er, well played.

The two hostnames point at two completely separate pieces of infrastructure.

If you want to support every URI under www.nasa.gov on the naked domain, you would need to deploy web resources on that separate network to handle the redirects, and maintain them.

Perhaps a willingness to be pragmatic and leave this job for another day is the reason they are successful in other areas such as, you know, putting a robot on Mars.

View on HN

I apologize for the headline, where I carelessly used the term "DNS config" incorrectly. I was hoping instead for the actual explanation for this. The web apps they've deployed for publicizing the Mars landing are extremely well done, and certainly took a tremendous amount of effort and money. They obviously have a huge commitment to a strong and polished web presence.

So really it's mystifying to me that they leave "nasa.gov" unreachable.

When you say "the two hostnames point at two pieces of infrastructure", "nasa.gov" only has MX records. There isn't existing "nasa.gov" infrastructure, at least on the open internet, to be redirected.

Since they do have to host "nasa.gov" separately due to the akamai thing, we're talking a moderate set of EC2 instances which do nothing more than send a 302 redirect including path info to www.nasa.gov. It's a couple of lines of mod_rewrite. The load on the instances, which could be high due to many visitors, would still be limited by the fact that unique visitors would only hit it once, or perhaps a small initial handful of times, per session. The total amount of bandwidth for 302 redirects is very small.

It's not zero effort, and requires some hosting. But I'm not yet clear on why the "implementation and ongoing operational costs" aren't microscopic compared to those which they spend on an app like the "Eyes on the Solar System" application (http://eyes.nasa.gov/).

All fair points. My response was a little harsh and possibly ad hominem. Apologies for the aggression.

In fairness their explanation is not a model of clarity, but the impression I get is that there are legacy concerns here. Perhaps they are using some type of split horizon DNS for access to internal services.

The resources necessary to make this kind of change aren't necessarily raw compute power (which as you point out can be purchased cheaply), more the necessary people and access to investigate the impact that such a change would have, then assuming it's viable, document the change, get signoff, then make the change.

I work for a company that has < 500 employees, but our IT infrastructure (which includes corporate IT and a web site handling a comparatively tiny 3m uniques / month) has a history that can be traced back around 15 years. Changes can be hellish, however small they first seem.

It's also worth bearing in mind that in a large organisation, independent projects (such as the Eyes on the Solar System product) are so much easier to get done than those which require interaction with other departments.

Basically, getting shit done in large organisations is hard. A lot of it is paperwork, which is annoying, but a lot of the paperwork is necessary - in a 5 person startup you can just shout across the room (or drop them a text if they've left the company), but at an organisation with hundreds (or thousands) of employees there must be protocol and documentation in order to competently deal with employee churn and similar.

No idea if I'm right about this, but hopefully it was more constructive :-)

Reply on news.ycombinator.com