4 ms·
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 ap
by zzzeek 14y ago
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/ http://eyes.nasa.gov/).
- Jamiecon 14y agoAll 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 :-)