Whoever runs the comcast network really knows his stuff.
They are one of the first large ISPs to actually start real work on deploying IPv6.
And I remember calling during an outage and speaking to someone on the front lines (not second tier) who was actually very technically knowledgeable.
Whatever you may think of their business department (silly things like internet + cable costs less than internet by itself), the network side is really good.
I know a guy who knows the regional network manager for Comcast here in the Midwest. I hear he's actually great. Their business and management is the worst of the worst, but the poor saps who actually work on their infrastructure know what's up. It's why I was getting 10 mbit speeds back in the early 2000s.
I might be misremembering, and some of those folks may have moved on, but Comcast inherited a large portion of the '@home' cable modem network, which was, as far as I know, the first network to run out of RFC1918 space due to size and not horrible management.
You can't grow a network that large without knowing your stuff inside and out. The netops folks at comcast are fairly active in NANOG, etc. as well.
I use Comcast (I'm in Boston) and I once called their phone support to see if I could get the "Domain Helper" disabled, and the tech had no idea what I was talking about. Switching to Google's DNS servers helped.
In "My Account", go to "Users & Settings". There's an option for "Domain Helper" right there. I was on Google's DNS servers until I saw Comcast was implementing DNSSEC, so I disabled the "service" and switched back.
The only requirement that you need is your Comcast account information that was created when you signed up with them. If you don't know the username, to avoid the issues whichdan ran into just call them on the phone (or if you're on your home internet connection you can start a webchat with them at https://www.comcastsupport.com/ChatEntry/ and tell them you forgot the account, then once you know it, ask if they can reset the password for you).
This will reprovision your cable modem(s) with alternate DNS settings (which are actually the same DNS server settings as their DNSSEC servers: 75.75.75.75 and 75.75.76.76). If you don't want to mess with turning it on/off and you've got a router connected to the cable modem (or a computer directly connected - please never do this!), you can just manually change your DNS server settings to these values and get the same effect (effectively ignoring the ones provided through the cable modem connection).
It should trigger a reboot/update on your cable modem, which will then cause it to pull down the alternate DNS server settings. Per the documentation on their help page, you may need to reboot any attached routers so that they pull down updated DNS information (though loss of link with the cable modem should trigger that when the cable modem comes back up).
And though the parent commenter used Google DNS (which I really do like) - users that make use of the iOS App Store for their iPhones / iPods / iPads may want to consider using the Comcast DNS server settings - if not for all devices in their house, then at least manually enter them for WiFi networks served by Comcast cable modems.
In my personal experience, using the 8.8.8.8 / 8.8.4.4 Google DNS server settings resulted in rather slow downloads compared to using the Comcast DNS server settings, as I believe Apple's App Store CDN server addresses were resolving to geographically incorrect / distant servers.
CDNs can use DNS trickery to speed up delivery. When a domain server (your ISP's) looks up the IP address for a server name that's hosting content you want, the name server can return tailored IP addresses based on where in the world it thinks the request is coming from.
Google's DNS servers do their own trickery to attempt to connect you to a DNS server close to where you're at (or at least provide results quickly for where you're at), but Comcast's DNS servers are hosted on their core networks which can reach their customer base quickly. A CDN IP address result tailored for where the Comcast DNS servers are hosted will result in an IP address that your home connection will likely be able to pull down from very quickly as well.
Results may vary, and I do trust Google to do less evil with their DNS results than Comcast - but damn it, I wasn't willing to wait 20 minutes to download an app that should have taken only 2.
As far as I am aware; those are not Verizon's DNS servers but rather Level 3's anycast DNS servers. They are geographically located around the world and using anycast you go to whichever one happens to be closest to you.
For most of America you end up in Dallas, TX, for the UK you end up in London, and for The Netherlands I was ending up in Amsterdam.
I don't have access to more machines to do traceroutes to see what the last hops are, but you can easily check this for yourself with a traceroute and seeing what network it ends up at.
Also, I was under the impression that their DNS servers technically require payment before use (as a commercial entity when handing out over DHCP) and are technically only for Level 3 customers. Everyone and their mother has started using them because they are easy to remember.
Here is some more backstory of how the DNS server was originally set up:
For my iOS devices, the devices themselves are slow enough at rendering web content in MobileSafari that shaving a second or even two off the resolve is not so much a benefit.
The real benefit for me was the CDN content coming through much much quicker for the App Store. iOS 5 has gotten so capable of managing content with iCloud and such that I rarely tether this to my laptop any more.
As such, quickly downloading an app while on WiFi is very important, since anything over 20MB requires you be on WiFi to do it.
I only came about this information by noticing that I was getting significantly higher download speeds from the App Store while at my parents' house on their WiFi than I was at home - yet we were both Comcast customers and I knew that I was paying for a slightly higher data package and had been able to perform 16Mbps sustained transfers on my laptop for non-App Store content routinely.
So I copied down the Comcast DNS settings that my folks had and tried them out, manually, at home on my iPhone. The speed difference was almost immediately noticeable.
Prior to that, I'd been using Google DNS servers 8.8.8.8 and 8.8.4.4. Just simply changing my DNS servers resulted in a much better performance.
I'll have to shop around to see if I can tweak it even further :)
DNSSEC prevents spoofing (as does HTTPS), but that's about all it does that's relevant to SOPA. This may prevent a particular mechanism of SOPA enforcement, but that's easy enough for the government to work around, in theory.
Exactly. If an ISP simply returns an error for lookups of a blacklisted domain, DNSSEC shouldn't complain; it will just think there's a DNS outage.
Since no one has read it, here's the relevant text: "A service provider shall take technically feasible and reasonable measures designed to prevent access by its subscribers located within the United States to the foreign infringing site (or portion thereof) that is subject to the order, including measures designed to prevent the domain name of the foreign infringing site (or portion thereof) from resolving to that domain name's Internet Protocol address." (I wonder if I am now cursed.)
Right, I don't know know how most DNS client implementations handle time-outs but this could range from not mattering at all to degrading the performance of everything - imagine if twitter was taken down, then half the world's websites (I'm exaggerating a bit) that reference Twitter buttons would grind to a standstill (try browsing things like TechCrunch in China and you'll see this).
If ISPs wanted to avoid this scenario, it would essentially require fracturing DNS[SEC] into something the US Govt has the authority to sign properly without effecting the rest of the world - in other words a completely divided national internet.
Or we could just all switch to using DNSSEC servers on the Barbados Islands or something in the future.
I'm not talking about timeouts; I'm talking about immediately returning an error (apparently DNSSEC will break if you return NXDOMAIN, but there are other error codes). If browsers retry or hang after getting a DNS error, I guess they'll have to be fixed.
How do you mean 'break'? As I understand it, NXDOMAIN also has to be signed with a trust chain back to a root authority. I guess what I don't know enough to answer is if there are other equally sufficient error codes that don't require a trust chain (which would be surprising because allowing any non-trusted responses would seem to defeat the entire purpose of a non-tamperable DNS service)
It doesn't matter if the NXDOMAIN is forged or not (or whether forgery is detected or not). It's not like you can unforge and extract the original IP from such a response. Your browser can flash all the red warning lights it wants, you're not going to connect to the naughty site. DNSSEC does absolutely nothing to impede DNS blacklisting.
That's never been the issue. When people claim that "SOPA breaks DNSSEC" (note they don't say the reverse) they mean that a SOPA blockage looks the same as a MITM attack from the client's perspective. As I've explained earlier, ISPs can choose to make it look like a DNS server outage instead of an MITM; this might produce fewer misleading errors in the browser. SOPA works fine as written, it just makes DNS debugging harder. "Users running secure applications have a need to distinguish between policy-based failures and failures caused, for example, by the presence of an attack or a hostile network, or else downgrade attacks would likely be prolific." http://www.circleid.com/pdf/PROTECT-IP-Technical-Whitepaper-...
Even if DNSSEC and SOPA were mutually exclusive in all aspects (which they are not), being pro-SOPA does not mean Comcast cannot also prepare for the case where SOPA fails to pass.
I find this more interesting not from a SOPA standpoint but because comcast has in the past given me false responses instead of NXDOMAIN. Anyone happen to know if this could prevent such a thing, or at least provide a mechanism of testing for it other than blacklisting an IP?
They would have to give some kind of error code that indicates that the DNS server isn't working. Any false assertion about DNS results, including false NXDOMAIN responses, will break DNSSEC (your computer would notice that the response has been forged).
It's actually not incompatible with SOPA. The bill demands that ISPs block DNS routing for certain domains. Returning no response to a DNS request would not break DNSSEC. It would just look like that site did not exist.
Some people have proposed that instead of blocking DNS, ISPs should redirect a DNS request. That would be incompatible with DNSSEC--but that requirement is not in the bill.
