NASA can't handle the DNS config to redirect nasa.gov to www.nasa.gov | Hacker News Reader

NASA can't handle the DNS config to redirect nasa.gov to www.nasa.gov

blogs.nasa.gov

8 pointszzzeek15 comments

First of all, www.nasa.gov is a CNAME:

  $ host www.nasa.gov
  www.nasa.gov is an alias for www.nasa.gov.speedera.net.
  www.nasa.gov.speedera.net is an alias for www.nasa.gov.edgesuite.net.
  www.nasa.gov.edgesuite.net is an alias for a1718.dscg.akamai.net.
  a1718.dscg.akamai.net has address 96.17.148.50
  a1718.dscg.akamai.net has address 96.17.148.40
  a1718.dscg.akamai.net has IPv6 address 2001:559:0:301::6011:6d11
  a1718.dscg.akamai.net has IPv6 address 2001:559:0:301::6011:6d38

CNAMEs have special usage restrictions. Specifically, "CNAMEs must have no other resource records of other types (MX, A etc) as specified by RFC 1034 section 3.6.2 and RFC 1912 section 2.4." [http://www.dnsuniversity.com/cname.html]

nasa.gov has MX records associated with it:

  $ dig nasa.gov MX

  ; <<>> DiG 9.7.3-P3 <<>> nasa.gov MX
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48927
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

  ;; QUESTION SECTION:
  ;nasa.gov.			IN	MX

  ;; ANSWER SECTION:
  nasa.gov.		293	IN	MX	10 ndjsnpf01.ndc.nasa.gov.
  nasa.gov.		293	IN	MX	10 ndjsnpf02.ndc.nasa.gov.
  nasa.gov.		293	IN	MX	10 ndjsnpf03.ndc.nasa.gov.
  nasa.gov.		293	IN	MX	10 ndmsnpf01.ndc.nasa.gov.
  nasa.gov.		293	IN	MX	10 ndmsnpf02.ndc.nasa.gov.
  nasa.gov.		293	IN	MX	10 ndmsnpf03.ndc.nasa.gov.

  ;; ADDITIONAL SECTION:
  ndmsnpf02.ndc.nasa.gov.	3	IN	A	198.117.0.122

  ;; Query time: 27 msec
  ;; SERVER: 192.168.1.1#53(192.168.1.1)
  ;; WHEN: Wed Aug  8 15:04:31 2012
  ;; MSG SIZE  rcvd: 202

To handle the redirection of nasa.gov to www.nasa.gov, they would need one or more nasa.gov A records that each point to a single IP address. These addresses would have HTTP servers that listen on ports 80 and 443 and redirect to www.nasa.gov. And this must be done in a highly-available way.

This infrastructure would be distinct from their existing web infrastructure (which appears to be Akamai-fronted).

So while yes, it's not the most difficult thing in the world to set up, it's not as simple as a DNS configuration change. Given NASA's strained budget and most browsers' handling of failed DNS lookups (automatically link/redirect to www.<domain>), is it really worthwhile? NASA thinks not.

What a trollish headline. Yeah, I'm sure the guys who just threw an object the size of a minivan 350 million miles through space and hit a target the size of the parking lot in front of 7-11 can't figure out bind.

I'm guessing there's lots of Apis from the wayback that are URL dependent and diverting just web through all that madness over to the www servers isn't a cakewalk.

but that's not what the article says. it says:

> Setting up our infrastructure to do that is technically straightforward: we need to add more servers to handle a lot of additional traffic on the front end, before people get to content.

as a description of the problem, the above seems kind of nonsensical. Which suggests that even this blogger is in fact, guessing, and then worse just passing it off as an explanation, and then we're back to NASA looking kind of bad here.

My best guess is that they're trying to say that whatever www runs off looks at the host header, and that they'd need to do some additional work in either 301ing requests, or set up a reverse proxy. In either of these cases, yeah, the headline is a little sensationalist.

Based off the wording, it sounds like they're responding to "why can't I browse http://nasa.gov/x without the www?" rather than "why doesn't http://nasa.gov/x take me to the NASA website?", but as they're a government agency, it's quite possible that there's so much bureaucracy / cost involved that it legitimately isn't even worth it to add a url-redirect server somewhere.

I'm pretty sure the MSL team is a different team than the ones managing the DNS servers, and expertise in one area doesn't transfer to another automatically.

Maybe they do have some reason why it would be difficult to add a CNAME, maybe not.

The reason why it would be difficult to add a CNAME is simple: They need NS records for nasa.gov, and a CNAME record precludes any other records for the same name.

also, I apologize. I should have said, "hosting configuration". I can't edit the headline now. I would rather delete it than leave it as is.

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.

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 :-)

The number of people in the comments who know enough about DNS to put together the phrase "nasa.gov CNAME www.nasa.gov." but not enough about DNS to know why that's a terrible idea is very worrisome.

Setting up our infrastructure to do that is technically straightforward: we need to add more servers to handle a lot of additional traffic on the front end, before people get to content. There are both implementation and ongoing operational costs to doing so, and that's where the decision point is. Is this the best use of NASA's resources?

Wow, that is total BS. Good on yah zzzeek for calling them out on it.

Nice troll. But I'm sure you could explain the DNS setup that would work to "redirect" nasa.gov. to www.nasa.gov., right? Bonus points for not using provider proprietary implementations like ALIAS.

I apologize. I should have said, "hosting configuration". I can't edit the headline now. I would rather delete it than leave it as is.

No worries, I was being grumpy. It is interesting that their was explaining the business justification for not making a technical change. People can forget about that whole business thing sometimes.

Reply on news.ycombinator.com