And most people won't have any idea which is the correct answer, will pick one at random or pick the default, and then spend the rest of the install process worrying that they picked the wrong answer. Why would any OS maker want to inflict that on their users?
On the other hand, she has also never installed an operating system.
Perhaps there should be an "advanced" step during install, which would be skipped by default.
Root domain CNAME records are not allowed by the DNS specification.
Older recursors and mail programs may not follow this CNAME.
You may want to change this record to an A record if you plan to
use it as a MX or SRV target.
Oddly enough, unlike the article, Comcast's DNS was working fine with my domain fine on the root CNAME.
Most services like Heroku or Google's AppEngine (where you set up a CNAME for your domain rather than an A record) recommend that you have your DNS provider to a redirect to the "www." version. Namecheap's DNS will do this (a lot of providers offer redirects in their DNS system which isn't really DNS, but is a simple value-add for them to provide).
You don't have to use a DNS provider to do redirection with AppEngine.
My solution is to use CloudFlare for my DNS (it's free, why not?) and use their "page rules" feature to do a 301 (permanent) redirect from domain.com/* to www.domain.com/$1.
You can see what happens if you run `curl -I maxmasnick.com`.
dnsimple.com (another DNS provider) also lets you add a "URL" record, which also is a 301 redirect.
One should be careful with 301 redirects because the are cached locally and quite thus permanent (see: http://www.jacquesmattheij.com/301+redirects+-+a+dangerous+o...). But in this case I think this is what you want.
Just checked, and our root record is indeed CNAME'd.
One question though. Is there a single source to reference for the discussion I'm starting with our host?
I think this is a little naive. Let's say you want to fix this, what could you do? Well, you could sign the responses; that would prevent hijacking, but it wouldn't stop the ISP from returning SERVFAIL, since the server could really be unavailable.
Well, then you could use another DNS server, and encrypt the queries so that the ISP has no idea what's being queried (and therefore can't do selective censoring). But now you've replaced one single point of censorship for another.
You could then send queries to multiple DNS servers simultaneously, so that no single server can censor.
Now think of all the latency added by that system, and which is useless because the ISP can wait for the DNS to resolve and then drop the HTTP request to that host.
You could make the ISP a dumb pipe by using a VPN, but now you've gone back to replacing an evil for another.
Eventually, to really fix the problem you'd need a Tor like system with anonymity, dynamic routing and hash-based addresses, but that's extremely inefficient and complete overblown for vast, vast majority of cases unless you're in a dictatorship.
>Now think of all the latency added by that system
If you send the requests at the same time, the latency should be the same as querying the slowest of the DNS servers individually (or the nth fastest server, where n is the number required to establish a quorum, if you don't require results from all the servers).