Comcast — Owner Of NBC Universal — Admits That DNS Redirects Are Incompatible With DNSSEC
from the well-look-at-that dept
Well, well, well. Here’s something interesting. Comcast, who owns NBC Universal (one of the main forces behind SOPA/PIPA), is officially a SOPA/PIPA supporter. However, yesterday, Comcast put up a post congratulating itself (deservedly so!) for completing its DNSSEC deployment, making it “the first large ISP in the North America to have fully implemented” DNSSEC across the board. That’s huge, and a clear vote of confidence for DNSSEC, obviously. They also urge others to use DNSSEC:
Now that nearly 20 million households in the U.S. are able to use DNSSEC, we feel it is an important time to urge major domain owners, especially commerce and banking-related sites, to begin signing their domain names. While in the past those domains may have wanted to do so but felt it would have limited effect, they now can work on signing their domains knowing that the largest ISP in the U.S. can validate those signatures on behalf of our customers.
All of this is good… but what may be much more interesting is that, along with this announcement, Comcast has also mentioned that it is shutting down its Domain Helper service. Domain Helper was a somewhat controversial DNS-redirect system, so that when you mistyped something, it would suggest the proper page or alternatives. Many in the internet community complained that these types of redirects mess with the underlying DNS system (which they do). But, as the DNS experts have been saying all along (and NBC Universal has been trying to play down), DNSSEC is incompatible with such DNS redirects. So… that makes this next part a little awkward. Comcast is now admitting, indeed, that DNS redirects, such as Domain Helper, are incompatible with DNSSEC:
When we launched the Domain Helper service, we also set in motion its eventual shutdown due to our plans to launch DNSSEC. Domain Helper has been turned off since DNS response modification tactics, including DNS redirect services, are technically incompatible with DNSSEC and/or create conditions that can be indistinguishable from malicious modifications of DNS traffic (including DNS cache poisoning attacks). Since we want to ensure our customers have the most secure Internet experience, and that if they detect any DNSSEC breakage or error messages that they know to be concerned (rather than not knowing if the breakage/error was “official” and caused by our redirect service or “unofficial” and caused by an attacker), our priority has been placed on DNSSEC deployment — now automatically protecting our customers…
Let’s be doubly clear about this, because it’s important. Just as NBC Universal and other SOPA supporters continue to insist that DNS redirect is completely compatible with DNSSEC… Comcast (and official SOPA/PIPA supporter) has rolled out DNSSEC, urged others to roll out DNSSEC and turned off its own DNS redirect system, stating clearly that DNS redirect is incompatible with DNSSEC, if you want to keep people secure. In the end, this certainly appears to suggest that Comcast is admitting that it cannot comply with SOPA/PIPA, even as the very same company is advocating for those laws.
It would appear that the left hand (people who actually understand technology) isn’t speaking to the right hand (lawyers/lobbyists) within the Comcast family. But, I think that NBC Universal and anyone else insisting that DNS redirects are fine in DNSSEC owe everyone else a pretty big apology… when their own company’s experts are admitting that the two are incompatible.
Filed Under: dns, dns blocking, dnssec
Companies: comcast, nbc universal
Comments on “Comcast — Owner Of NBC Universal — Admits That DNS Redirects Are Incompatible With DNSSEC”
Isn’t DNS blocking different from redirect? I thought the bills called for blocking, not redirect.
Re: Re:
No. What would happen, if they pass, is you type “www.insert-rogue-website-here.com” and it would be REDIRECTED to an official looking website saying “This site has been taken down due to copyright accusations”. The content of the “rogue” website would still be there: a very rough real-world equivalent would be a competitor complains about his competition, gets the directions to his competition altered in your GPS, you put in the directions into your GPS and get in your car and drive there, only to find that the directions instead lead to a very large billboard saying “This site is rogue”.
Re: Re: Re:
More like they force their competition to remove any signage, but if you know the address you can still get there.
Re: Re:
Fucking with DNS can generally occur at three points in the network:
1) You can fuck with DNS at the authoritative server for the zone.
2) You can fuck with DNS close to the end-user.
???? a) At the hosts file or stub resolver, or application software (i.e. browser)
???? b) At the recursive resolver, contacted by the user’s stub resolver
3) You can fuck with DNS somewhere in transit
???? a) On the wire
???? b) At intermediate, non-authoritative, caching servers (compare with 2b).
Re: Re: Re:
They’ll just change the SOA in the root servers. That’s only one set of things needing control, and it doesn’t rely on any cooperation amongst potentially hostile enemies. This is why this whole post is pointless, because DNSSEC not complying with redirect is useless. Once complete the root servers will just be modified to point the domain to blockedbysopa.dhs.gov or whatever.
Re: Re: Re: Re:
Er, hostile entities, not enemies.
If the government modifies the root record, they don’t have to worry about uncooperative or hostile ISPs (such as Comcast using a DNSSEC system which is not compatible with redirects or other ISPs with proprietary technology) is all I’m trying to say.
Re: Re: Re:2 Re:
And if the root record for the domain is not located within a US jurisdiction, how does “the government” modify the SOA?
Re: Re: Re:3 Re:
IANA is based on Marina del Rey, CA
Re: Re: Re: Re:
I think you may want to read this. Specifically the part where it says
If you’ll take careful notice, DNSSEC resolves the security issue, in part, by further distributing the zone of trust from the root server via asymmetric (and thus bi-directional) cryptographic checks. This means that a SOA, which only points out where the authoritative DNS servers are by name, can not be easily messed with in transit. Upcoming legislation, like SOPA and PIPA, would require that a domain name be modified in a manner inconsistent with the standard top down dissemination of record modifications. In other words, the ISPs would become the man-in-the-middle attacker. Alternatively SOPA/PIPA would require either the root DNS to maintain the authoritative record for all DNS domains, which massively centralizes the DNS system and reverses many years of work in the other direction, or that authoritative record changes be allowed to travel backward, which defeats the purpose of DNSSEC by allowing the many more downstream DNS servers to have an authoritative say in the DNS record. The second scenario is the worst as the authoritative DNS record for a lower level domain name could then be used to poison the cache of higher level servers through “secured” communication. This would also be possible under ISP moderated censoring of designated domain names. Cache poisoning and man-in-the-middle attacks are already the bane of the current DNS system when it comes to centralized authoritative records which are by some means or another subject to attack. Securing these channels and ensuring that the DNS system continues to move toward a more distributed hierarchical system removes many of these problems, but can not coexist with poorly conceived legislation like SOPA and PIPA, which demand the very vulnerabilities being corrected be reintroduced.
Re: Re:
Rikuo has the right of it, but to put things another way…
It depends on what “blocking” means. According to SOPA/PIPA, it means “if someone asks for http://www.roguesite.com, send them to us instead,” and as Comcast’s post notes, this looks EXACTLY like malicious redirection at a technical level. DNSSEC works because the domain names are signed and verifiable, and it prevents anyone from sending you to the “wrong” site, even if it’s the Government.
I suppose that if “blocking” meant returning a “destination unreachable” error then this would be different, but getting a workable system to just drop traffic seems like a really backwards effort, and there would be no “education” involved (because it would just look like your connection was dead).
Re: Re: Re:
Rikuo has the right of it, but to put things another way…
It depends on what “blocking” means. According to SOPA/PIPA, it means “if someone asks for http://www.roguesite.com, send them to us instead,” and as Comcast’s post notes, this looks EXACTLY like malicious redirection at a technical level. DNSSEC works because the domain names are signed and verifiable, and it prevents anyone from sending you to the “wrong” site, even if it’s the Government.
I suppose that if “blocking” meant returning a “destination unreachable” error then this would be different, but getting a workable system to just drop traffic seems like a really backwards effort, and there would be no “education” involved (because it would just look like your connection was dead).
The latter measure is what I understand the bill calls for. ICE engaged in redirects under current, US law. Returning a “destination unreachable” message is what the proposals call for and do not have any DNSSEC security issues that I am aware of. Though that distinction seems to be completely missing in the article.
Re: Re: Re: Re:
The distinction between being redirected to a page that tells you that you can’t get the website you were looking for and getting a message that you can’t get the website you were looking for is clear.
Re: Re: Re: Re:
Returning a “destination unreachable” message is what the proposals call for and do not have any DNSSEC security issues that I am aware of.
Ah, but it does. Paul Vixie explains it better than I could: DNS Policy is Hop by Hop; DNS Security is End to End.
Re: Re: Re:2 Re:
” Doubtless there are strong governments around the world who would like to be able to modify DNS data in flight without triggering any suspicion by their end user citizens or by secure applications.”
Surely only weak governments attempt to fools their citizenry, so am I right in assuming that he is being sarcastic here?
Re: Re: Re:3 Re:
I think it’s something of a misstatement, to use an ugly word. While he is talking about insertion of false data into hoop-by-hop responses I’m almost sure he means governments like Iran, Saudi Arabia and China rather than places like Syira (certainly weak right now) than free and democratic countries like the U.S. I think he’s using “strong” as in well established “system” rather than one that is under attack of some kind or other and may change so that designers of DNSSEC may be reluctant to take what they want into account.
The United States would, obviously, count as strong here though one might quibble about how strong or representative it is.
Re: Re: Re:2 Re:
“Returning a “destination unreachable” message is what the proposals call for and do not have any DNSSEC security issues that I am aware of.”
Ah, but it does. Paul Vixie explains it better than I could: DNS Policy is Hop by Hop; DNS Security is End to End.
Thanks for the link Rich. I understand that currently malicious sites like spam, malware etc are blocked at the DNS level. If that is true, it’s hard to believe that the same blocking provisions are unavailable and not built into DNSSEC. How will child porn be blocked under DNSSEC?
Re: Re: Re:3 Re:
This may be informative; it predates the earlier link from Rich, and they appear related. Vixie eventually concludes: Nevertheless the raw uncomfortable truth of the matter is that any form of mandated “DNS blocking” whose goal is to make certain domain names unreachable will be indistinguishable from the result of a Secure DNS failure – and a failure is a failure is a failure.
Re: Re: Re:4 Re:
Derp derp, here’s the link.
Re: Re: Re:3 Re:
I understand that currently malicious sites like spam, malware etc are blocked at the DNS level. If that is true, it’s hard to believe that the same blocking provisions are unavailable and not built into DNSSEC. How will child porn be blocked under DNSSEC?
We tend to say that they’re “blocked” — but they’re really not. It’s an imprecise use of language that leads to confusion. Let me try to explain.
Suppose that example.com are Evil Wicked Mean Nasty spammers, and that the good guys over at example.net are running a blacklist of such domains. We desire to use that blacklist to stop ourselves from accepting mail from example.com (and many other domains like it). We then configure our mail servers such that when mail is presented to us, we send a DNS query to:
blacklist.example.net
and in that query, we ask for the A record for
INCOMING-MAIL-DOMAIN.bl.example.net
as in (using this example)
example.com.bl.example.net
In other words, we’re not querying DNS servers that have anything to do with example.com. We’re querying a DNS zone over at example.net (bl.example.net) to see what it says. Typically, we’ll get back a response that either says NXDOMAIN (no such entry in the zone, domain is not blacklisted) or 127.0.0.1 (there IS an entry in the zone, domain is blacklisted). Our mail server can decide what it wants to do with that response. It could (a) refuse the message (b) accept the message (c) stash the query result and a get a second or third opinion (d) weight the query along with others or (e) many variations of these.
In other words: the blacklist blocks nothing, permits nothing. It simply gives an advisory opinion, and it’s up to us what we do with it. But we tend to abbreviate this process and say things like “mail was blocked by spamhaus.org’s blacklist”, which is certainly quicker but not really very accurate. By the way, this same mechanism can be used with other application-level protocols; for example, it can used in an HTTP proxy to cut off web access to example.com. But worth noting is that there’s no way to compel us to use example.net’s blacklist, or any other one: we choose to do so, presumably because we trust that the keepers of that DNS zone are reliable, accurate, etc.
As to how child porn (or anything else) gets blocked with DNSSEC: it doesn’t. That’s not what DNSSEC does. DNSSEC will let us securely/definitively acquire information about the child porn domain; we then have to decide, elsewhere, what we want to do about it. (This is glibly assuming that the operators of such a site are even using DNS…and that’s a pretty big assumption.) One of the ways that we can decide elsewhere is called DNS RPZ (see link that I furnished earlier in the thread).
Re: Re: Re:4 Re:
Thanks for the response, very helpful.
Re: Re: Re:4 Re:
They have to take down the server itself. DNS filtering won’t be missed under DNSSEC since it’s already useless (for filtering CP).
Re: Re: Re: Re:
I think you’re missing a distinction, or I’m not understanding you correctly.
When I say “destination unreachable,” I’m no longer talking in DNS, I’m talking in TCP/IP. That is, you give them the right street address but then block all the roads that lead there. I don’t think that’s really a feasible choice; the Internet was designed to route around such “damage,” so it would be a massive, backwards, counter-productive effort — if it’s even possible.
What you seem to be talking about is a DNS-level “destination unreachable,” where you simply fail to give them the right address. The article that Rich links to talks about what this won’t work — properly functioning DNSSEC will ignore anything but an authoritative, signed response; if you say you don’t have the address, DNSSEC will just ask someone else until it finds a signed response.
Re: Re: Re:2 Re:
There’s a problem with using ICMP to respond with “destination unreachable” — actually, there are several problems. ICMP (Internet Control Message Protocol) packets are (more or less) an out-of-band way of communicating errors or information. ICMP isn’t used like TCP or UDP to actually shovel data around, it’s used to make decisions about routing, packet sizes, and the like. ICMP packets have a “type” and a “code”, e.g., a type 3 code 10 means “destination unreachable, host administratively prohibited” while a type 12 code 2 means “bad length”.
Thus, ICMP operates at a fairly low level in the Internet’s plumbing — below that of DNS. Which brings up the first problem: you can’t block access to a web site using ICMP destination unreachable. You can only block access to a host or network. Which means that if you have a host using shared web hosting, and thus handling web servers for 816 domains, you’ll have to block the host — and thus 815 additional domains.
This works the other way too: suppose you’re going after the domain example.com — which uses round-robin DNS or any other load-balancing trick to resolve the A record for http://www.example.com to (let’s say) 12 different hosts, all of which have mirrors of the web site. You’ve got to identify and block them all.
And it gets trickier still: a heck of a lot of web sites don’t directly serve their own content: they use distributed caches (like Akami). So you’ve got to block all those too — which, by the way, will likely block a LOT of other domains.
And then we get to the issue of precisely how you’re going to issue these ICMP packets. You can’t just inject them randomly and expect hosts to pay any attention to them; you need to generate them on-the-fly, in the right place at the right time with the right contents — and in response to incoming IP traffic. That’s certainly non-trivial.
And even if you could install DPI (deep packet inspection) equipment everywhere, and even if you could manage it all, and even if you could avoid the numerous DDoS vectors that entails, and even if if if…it’s all still easily defeated by using botnets.
Re: Re: Re: Re:
Watch support calls sky-rocket as DNS requests get black-holed.
Re: Re: Re: Re:
A DNS that can lie is not a good DNS.
DNS should only return unreachable if it can not be reached.
DNS should when working correctly take you directly to the ip address associated with the domain name if the domain is registered and can be connected to.
Law enforcement should not fuck with this in any way. If a site is truly illegal then the court case will find them guilty and if done properly fuck them in the ass so hard they never stick their head out again.
But trying to have a few people decide without a court hearing who to immediately shut up is not a good thing.
If you can not see that you are a moron or a shill.
Re: Re: Re:2 Re:
Hey…no need to call people names. He/She asked a very valid question, and we here do our best to answer. Not everyone is computer-literate.
The true morons/shills would be those politicians supporting this bill and gleefully saying they don’t understand the technology and don’t WANT to understand it, or get advice from those who do.
Re: Re:
It too is my understanding the redirection has been deleted from the current iteration of SOPA in response to concerns articulated by the technical communities.
Re: Re: Re:
O RLY? I guess it makes SOPA sooo much better. Not.
But good point, just need the citation. I find it hard to follow all SOPA versions =(
Re: Re: Re:
Yes, the language was modified. But the language was modified by people who don’t have any clue what the difference is (or who don’t care). Those of us who work with/understand the technical implementations of what the SOPA writers want are the ones screaming out that there is no difference between the two and that the difference in language is nothing more than a facade to pretend that there is no problem. Once again, left hand not talking to right hand or right hand ignoring left hand.
Re: Re: Re: Re:
Basically, what I was trying to convey was the fact that the writers can change the wording all they want, but DNS has nothing to do with blocking a website. The only way to block using DNS is to redirect. Since any redirection is indistinguishable from malicious redirection (think man-in-the-middle attacks trying to steal your bank information), there is no way to implement SOPA. Period. Changing the wording and calling it something else doesn’t change the actual facts.
Edit: For clarification
Re: Re:
I have been blocked many times by psmnbc liberal
left wing Obama newtwork! now it’s been more than
a week and I have many emails and none will let me
log in to leave my comment! I hate psmnbc and its
agenda to re-elect this socialist! I guess they
don’t believe in free speech and hearing the truth
and other side like all liberals. I say boycott all
psmnbc shows and GE or anybody who advertises on
nbc! F them to hell!
Comcast is admitting that it cannot comply with SOPA/PIPA,
Not true at all. They CAN comply with SOPA, they just admit they can’t do it and still ensure they can keep people safe/secure.
Clearly the losses from data/identity theft are nothing compared to the losses from copyright theft. C’mon, what’s a few thousand people/small businesses being ruined every year compared to the ability of the entertainment conglomerates to limit distribution channels and force content creator to continue to relinquish their rights, and to limit choice for consumers to create artificial premiums?
Think of the poor CEO’s and lobbyists.
Re: Re:
Think of the poor CEO’s and lobbyists.
Yes, think about the 1%. Surely the needs of the few out weigh the needs of the many?
Re: Re: Re:
Remove that unsightly, unpatriotic question mark, free citizen.
Re: Re: Re: Re:
If there was a “pure comedy” button you’d get +3 “pure comedies” from me now and a beer. That was some good lolz, good sir!
Worth following in this regard, these mailing lists:
DNS RPZ
DNSEXT
DNSOP
DANE
DNS operations
BIND users
BIND announcements
These are the places where topics related to DNS and DNS software are discussed, frequently by the people crafting the standards and writing the code.
Damnit! This is gonna get closer to not passing.
I was really looking forward to its passage and then do my very best to ensure Rick Perry is elected; then move to Canada and laugh.
Re: Re:
Rick Perry for president is a no brainer
Re: Re: Re:
Rick Perry is a no brainer
FTFY
Re: Re: Re: Re:
no, you didn’t you just used a sledgehammer to crack a peanut
Re: Re: Re:2 Re:
or possibly an over ripe grape.
I hate to say, but what if they removed the “destination unreachable” to just removing the entry from the DNS registry…now it just doesnt exist. Although creating some dynamic dns system (even something rudimentary like a twitter feed for IP address changes) wouldn’t be difficult.
Re: Re:
Tor already proxies DNS, to avoid side-channel leakage.
Re: Re:
I think you’re mixing apples and oranges. “destination unreachable” is an ICMP response that you’ll get under various circumstances, but (simplifying) it means “this packet couldn’t be transmitted to the host that you were trying to send it to”. NXDOMAIN is the DNS response that means a domain/host name cannot be resolved. (And worth pointing out is a frequent error of omission: many people who talk about what can or can’t be done with DNS, or what should or shouldn’t be done, make the error of presuming that the only consumers of DNS responses are web browsers…which they’re not. A substantial argument can be made that while they may be the most prevalent and most visible to end users, they’re not the most important consumers.)
Re: Re:
There are some specific reasons why what you’re suggesting won’t work, but I’d like to make a more general comment.
It turns out that serving up huge databases on demand to the entire Internet is a hard problem. That’s why DNS exists — back in the old days, we actually all used a single “hosts” file that we periodically FTP’d to our servers from a central maintainer’s system. DNS is, in part, a response to the scalability issues of that setup.
Fast-forward a few decades, and it’s still a hard problem. Running a DNS zone with a hundred million entries and efficiently answering queries directed to it and updating it often and accurately and defending it from DoS attacks is a formidable challenge.
And even meeting that challenge (which only a few have done, and then only after a lot of effort and/or expense), still doesn’t mean that the desired result will be achieved — not in a world with of bots/botnets, which can neatly undercut all of it at will.
Mod quote: Think about the 1%. Surely the wants of the few out weigh the needs of the many?
ICE, DOJ, SOPA supporters
Checkmate. The interwebz won, FATALITY.
“It would appear that the left hand (people who actually understand technology) aren’t speaking to the right hand (lawyers/lobbyists) within the Comcast family.”
I think this is the left hand slyly showing their displeasure with SOPA. What better way for the Comcast technical experts to piss on this bill than to implement the next generation of internet security and then throw their hands up with “there’s nothing we can do!” if SOPA passes.
(and official SOPA/PIPA supporter)
Should be an, not and.
The internet is saved!!! Thank you, @ Comcast!!! Thank you. Thank you. *tear*
Re: Re:
“Thank you, @ Comcast!!! Thank you.”
See also: words that have never been uttered, ever.
Essentially they are talking about hijacking the DNS NXDOMAIN response. It’s good to see Comcast come to their senses and I wait for OpenDNS to do the same.