

NASA can't handle the DNS config to redirect nasa.gov to www.nasa.gov - zzzeek
http://blogs.nasa.gov/cm/blog/nasadotgov/posts/post_1306860816073.html

======
mikebabineau
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.

------
noonespecial
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.

~~~
Nogwater
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.

~~~
soult
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.

------
Jamiecon
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.

~~~
zzzeek
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/>).

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

------
geofft
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.

------
wamatt
_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.

------
donavanm
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.

~~~
zzzeek
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.

~~~
donavanm
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.

