If You Use Comcast DNS Servers, You Cannot Read This (try with www.) | Hacker News Reader

If You Use Comcast DNS Servers, You Cannot Read This (try with www.)

diegobasch.com

12 pointsdiego19 comments

> I believe that OS makers should give people an option to choose among several DNS servers during the installation process, and explain why.

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?

You already pick a ton of defaults when installing an OS (English keyboard, whatever). Same as when downloading something from a random mirror. People don't think twice about these things.

My mother has never once downloaded anything from a mirror.

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.

Cloudflare's DNS editor warns with this when CNAME'ing a bare domain:

    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.

I fell into this problem a while back with the domain I use for my mail. Everything was set up nicely in Namecheap's DNS so that the MX records were pointing at GMail and the root CNAME was pointing at my webhost. After a couple days not getting mail, I figured out what the problem was.

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

http://support.google.com/a/bin/answer.py?hl=en&answer=2...

You don't have to use a DNS provider to do redirection with AppEngine.

You can't do CNAME with the root domain record. That is all.

http://pzxc.com/cname-on-domain-root-does-work begs to differ.

The reality begs to agree.

Yeah, I give up. I just changed it.

That blog post is just as wrong today as it was a year ago:

http://news.ycombinator.com/item?id=2593403

Yes, your screenshot shows you putting a CNAME in at your domain's root. The GUI should have disallowed this, as it's not permitted in DNS.

It's telling that the writer included a screenshot rather than just stating what he did. He believed the GUI was doing something for him when it was not.

You're right that using an A record isn't great because your hosting provider loses the flexibility of being able to change IP addresses. This article explains it really well: https://devcenter.heroku.com/articles/avoiding-naked-domains...

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.

Why naturally jump to the conclusion that Comcast (Who, while many will criticize, probably know vaguely what they're doing) is broken before researching /why/ it wasn't working? DNS isn't the most simple thing in the world, and things like this can catch a lot of people out, particularly if your DNS host doesn't tell you root level CNAMEs are not recommended, but automatically assuming someone else must be doing something wrong, just because you think it should be working, is frankly stupid. It's the sort of thing I'd expect from TheDailyWTF or /r/talesfromtechsupport, not a reader of Hacker News.

I did research, what you're seeing is part of the research process :)

Appreciate the discussion here. You all may have just solved an occasional and annoying issue on my website. I'm a Dev at www.theblaze.com and we've had varied reports over the past little while that the site is inaccessible on Comcast. I use Comcast as well at home and I've noticed intermittent failures. My first thought was DNSSEC errors like those that took NASA down a few months back, but we don't use DNSSEC at all.

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?

DNS in its current form is broken as well. It wasn't designed to be used by the current internet. Furthermore, a particular ISP can decide to use its DNS servers as a mechanism for censorship.

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.

>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

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

Reply on news.ycombinator.com