|
I’m interested in CircleID community’s take on NeuStar’s recent announcement of Cache Defender. While only effective for domains the company is authoritative for, that does cover a large number of big Internet brands and financial institutions. Why wouldn’t an ISP deploy this now, while waiting for all the myriad issues involved in DNSSEC to be resolved?
See this related story from CIO.
Full Disclosure—I consulted with NeuStar on this announcement.
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byWhoisXML API
Sponsored byVerisign
I just checked the top 10 US banks, and not a single one of them is using NeuStar as far as I can tell.
They should publish a list of domains that would actually be protected if they want people to implement this.
Similarly, which ISPs are protected on the recursive DNS side?
In spirit, is this any different than DLV? With DLV, the administrator of the zone must DNSSEC sign the zone (will have to do this anyways) and provide DNSKEYs to the DLV. The operator of the recursive resolver then sets up a trust anchor for DLV (the ISP’s opt-in step).
Neustar presumably has added systems to add signatures at the authoritative side, and ISPs must add systems to their recursive resolvers to verify signed responses coming from UltraDNS. Seems like a similar solution, but the same amount of effort, plus hardware opex/capex, for something specific to Neustar customers.
The only benefit to Neustar customers, as I see it, is that they do not have to send DNSKEYs to DLV, as the Neustar system is run in-line. However, many providers are working with various DLV registries to automatically perform this step.
Is it possible this will only hold up DNSSEC rollout overall because operators may think that this is a good enough band-aid?
Chris,
Full Disclosure—I think UltraDNS is deceptive and has sleazy annoying sales people, but that’s just my opinion. (I put my disclosure at the top!)
First, how Ali allowed this to get posted on Circle ID I have no idea…
Second, as to why people will ignore it… My guess is Ultra just added some EDNS options like the rest of us have been doing for a long long time, long before Neustar decided to copy the idea and in the case of OpenDNS, even before the Kaminsky vulnerability was ever disclosed.
But since the press release says nothing useful and their website says nothing useful, my guess is that it’s just made up because they haven’t announced anything interesting lately… but of course that’s just speculation, I have no idea.
And I predict I’ll get (yet another) nasty email from Rodney in about an hour for sharing my thoughts on UltraDNS publicly… :-)
Taking in reverse order:
David—Your disclosure doesn’t disclose you compete with UltraDNS, it just criticizes the company.
Regarding the technology, you don’t have to “guess” at all. It’s described in the release how ISP customers would be protected from cache poisoning re-directs, provided NeuStar is authoritative for the domain. If you don’t think that’s important, explain why. Without the bias and the insinuations.
Tom—I remember DLV being promoted in 2006, but I’m not an engineer. I’m tracking down an answer to that question. Regarding the ISP question, only name that is public right now is Grande, the one quoted in release.
Mike—you’re right about a list being very interesting, but NeuStar isn’t likely to publish a list of all its enterprise MDNS customers. The public number is over 4,000, including around 550 banks. If it’s none of the top ten, well that’s still a lot of online banking customers who could use protection.
Chris -- (1) I don't compete with UltraDNS, it would be apparent if I did because I'd be siphoning off their customers. It's tempting, though. (2) People who read Circle ID by and large know who I am and likely know me in person. In fact, both Tom and Mike know me in real life. As to the technology, the press release doesn't say anything about how it works. It seems like a scam to me or just FUD + Vaporware. But who knows cuz it doesn't say anything.
Do you think the subscribers (you know the ones paying for something) should have any say or control over their DNS? Granted, there are a minimal number of subscribers (considering the aggregate) that do use alternative DNS and a handful of CPE providers to the residential market that ease this process. What I'm referring to is along the lines of a self service website (much like opt-out sites for various commercial DNS query services) that goes beyond turning the redirect to a website service "off" but one that allows for a competitive DNS selection. I'm just wondering how long it will be until practices surrounding the curation of DNS query data from subscribers is hauled into a congressional setting. How service providers are monetizing the collected data from the corpus of queries seems like a legitimate interest in terms of consumer rights. Perhaps offering a opt-in to an elsewhere service could shift concern over the captive network scenario to where the network provider gets a pass to continue without inquiry or they would have to place DPI or other third party collection agreements in place with disclosure in their privacy notice... Anyway. Just thinking/asking out loud. :)
What are the “myriad issues”?
One word: Akamai. DNSSEC will never work because it believes that answers should be globally consistent, a perspective that has no place on the Internet we use today. DNSSEC also is designed with the implementation being done in offline signing, which is a PITA. For DNSSEC to gain any real-world traction, this will be the first thing to go. I could go on, but it's better done in a separate blog post. Keep in mind, I'm not against DNSSEC in theory. I'm against how people are deploying it and how it's currently being deployed. There is no question that the current DNS security model is lower than the bar needed to protect against the current DNS security threats. It's not clear that DNSSEC raises that bar adequately and I am positive there are alternate, easy-to-deploy, security extensions that can exist today that are easier to digest than DNSSEC. :-)
"DNSSEC will never work because it believes that answers should be globally consistent, a perspective that has no place on the Internet we use today." I don't think so. Using BIND views, I should be able to give hand out a.example.com==10.1.1.1 for clients in 10.1.0.0/16, and hand out a.example.com==10.2.2.2 for clients in 10.2.0.0/16, both with valid signatures in the example.com zone. Akamai should be able to do the same thing. Yes, the answers may depend on the ip address of the client asking the question, but both sets of answers can be properly signed such that the clients can verify those signatures. "DNSSEC also is designed with the implementation being done in offline signing, which is a PITA." Define "offline signing". BIND can sign records inserted dynamically via nsupdate. "I'm against how people are deploying it and how it's currently being deployed." Exactly what are people doing with dnssec that you are "against"? Do you feel that they are somehow abusing the protocol, or that they are opening some security hole, or what? Please be specific.
DNSSEC will never work because it believes that answers should be globally consistent, a perspective that has no place on the Internet we use today. "Will never work", huh? DNSSEC, of course, works. Whether or not it will see widespread deployment is a valid question, but that is separate from whether it actually works. As for Akamai-zation, if you are the authority for the zone, you can still play "stupid DNS tricks" to modify the answers returned depending on network topology, latency, phase of moon, etc. All that is necessary is that you resign the data which implies online signing keys and more CPU. DNSSEC, of course, makes it impossible for caching server operators (e.g., OpenDNS) to modify responses inflight in order to point people at advertising or whatever. Whether or not that is sufficient to dissuade people from using DNSSEC remains to be seen, but this may explain why some folks are ... resistant to DNSSEC deployment. DNSSEC also is designed with the implementation being done in offline signing, which is a PITA. Well, no. The design of DNSSEC did not make any requirements regarding online vs. offline keys. Initial implementations assumed offline because that was more secure. Online vs. offline signing keys is a question of tradeoffs regarding convenience vs. security. I believe most production signed zones, particularly those with dynamic content, have moved to online signing keys I could go on, but it's better done in a separate blog post. I look forward to that blog post. Keep in mind, I'm not against DNSSEC in theory. I'm against how people are deploying it and how it's currently being deployed. My impression is that you may misunderstand how DNSSEC is actually being deployed. There is no question that the current DNS security model is lower than the bar needed to protect against the current DNS security threats. It's not clear that DNSSEC raises that bar adequately DNSSEC, which ensures data cannot be modified undetected as it traverses the network from the authority to the validator nothing more or less, addresses a particular class of vulnerabilities that are now being exploited. What is not clear is whether or not the value of that protection outweighs the costs, including increased software and operational complexity, that DNSSEC imposes. Fortunately, many of those costs can be hidden or reduced by tools and automation. and I am positive there are alternate, easy-to-deploy, security extensions that can exist today that are easier to digest than DNSSEC. :-) Do tell. Of all the alternatives I've heard, most only protect the channel of communication and hence are vulnerable to in-path attackers (or 'enhancers' if you prefer) as opposed to protecting the data as DNSSEC does. We've gone down the path of partial solutions like protecting the channel in the past and have gotten burned. It is time to actually solve the problem. Believe me, after working in/around DNSSEC for more than a dozen years, if there is a better solution than DNSSEC that really solves the problem, I'll be among the first to consign DNSSEC to /dev/null with glee.
David—to my understanding both technical and political issues. For a long time there was disagreement around who would control the root signing process. And the issue of Dept. of Commerce oversight of ICANN complicates and politicizes DNSSEC.
For tech, there are many in this forum who could better describe, but here are some challenges according to wikipedia:
However, the DNSSEC specification has been challenging to develop. NSEC3, one of its critical pieces, was only formally defined in an RFC in March 2008, and it is not yet widely deployed.
In addition, DNSSEC deployment in large-scale networks is also challenging. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will adopt it. DNS servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP-using client must have their DNS resolver (client) updated before it can use DNSSEC’s capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC. Ozment and Schechter observe that DNSSEC (and other technologies) has a “bootstrap problem”: users typically only deploy a technology if they receive an immediate benefit, but if a minimal level of deployment is required before any users receive a benefit greater than their costs, it risks remaining undeployed.
An interim selection for parties involved in root signing has been made and will be discussed at the ICANN meeting this week in Sydney. Even if root were not signed, the existence of the ITAR (https://itar.iana.org) and automated tools that allow for inclusion of the contents of that trust anchor repository would allow folks to validate contents of signed zones. ORG and GOV are already signed with NSEC3, but NSEC3 is not critical to DNSSEC deployment. According to the last figures I looked at, around 2/3 of the queries hitting the 'L' root server signify support for DNSSEC (that is they set DO=1 in the query). That works out to about 5000 queries per second steady state on one root server, so the bootstrap problem seems to have been addressed. This is not to say that fully deploying DNSSEC is not going to take time, but it'd be helpful if real issues were identified so they can be addressed.
"according to wikipedia:" not exactly an authoritative source. "DNS servers must be updated with software that supports DNSSEC" Both BIND and the dns server in Windows Server 2008 R2 support dnssec. Others have given statistics on the percentage of queries that advertise support for dnssec. "and DNSSEC data must be created and added to the DNS zone data." If you just want to verify the signatures on other folks signed zones, you don't need to do much. Of course, if you publish zones over dns that you want other folks to be able to verify, then yes, you need to sign them. "A TCP/IP-using client must have their DNS resolver (client) updated before it can use DNSSEC's capabilities." No, the client resolver might be pointing to a local dns server that does both recursion and validation of the dnssec signatures. Bind can do this, so you don't need to update the stub resolvers on all the client workstations. "What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC." Yes, you need some master key that you implicitly trust. For now, that can be the isc.org dlv key. Eventually, that can be the root key. But again, this key gets added to the local dns server, not to every client workstation.
1. IP claims against the software by a US software vendor - which US companies like HP, Dell etc would need to settle before they could consider this.
2. Some would also raise questions about the process by which this sofware was chosen and mandated instead of remaining vendor neutral (say “will ship with some filtering software that has a chinese language interface)
What IPR claims? Haven’t heard of any being raised.
Not sure what you mean by ‘the process by which this software was chosen’. If you’re speaking of the DNSSEC protocol, it has been in development for more than a decade in about as open an industry forum as you can get (the IETF). There are multiple independent implementations available, so this would seem to imply vendor neutrality.
.. that post was the one about the "green dam" chinese filtering software. I seem to have typed it into the wrong firefox tab (got 3..4 circleid articles open in different tabs).
Tom—got some feedback on the DLV question.
If I’m correct, some issues are that BIND currently only supports one DLV provider, and some vendors like MicroSoft and dnscache don’t support DLV. Cache Defender protects all recursive products (for the domains NeuStar is authoritative for of course.) And there is no opex/capex—ISPs aren’t paying for this, just investing the time needed to deploy.
A separate issue is that with Cache Defender, an ISP is not putting another organization in front of all its DNS queries.
“BIND currently only supports one DLV provider”
Is that really an issue? Is there any other provider of a dlv tree that is competitive with isc.org? This is intended as an interm step until the root is signed. Once that happens, the entire dlv thing can go away. So I don’t see any pressure that would cause a competitor to start up a new dlv tree.
“some vendors like MicroSoft and dnscache don’t support DLV”
Yes, Microsoft apparently thinks there is not enough demand to support DLV. Given the *average* level of dns competence among users of Microsoft DNS products, that is not suprising.
“Cache Defender protects all recursive products (for the domains NeuStar is authoritative for of course.)”
Yes, and bind with dnssec and dlv from isc.org protects you for all domains where the owners cared enough to sign their zones. That should be a lot more than just the ones for which NeuStar is authoritative. NeuStar would do their customers a better service by dnssec signing all those zones, and then arranging with isc.org to bulk add all those keys into the dlv tree.
“A separate issue is that with Cache Defender, an ISP is not putting another organization in front of all its DNS queries.”
How so? Given an existing recursive resolver box (bind or MS), you still need to reconfigure that box to point it to some other box which actually does the signature checking. This other box is either local or at NeuStar, but it is a dependency on another vendor.
What is the transition mechanism when the root finally gets signed? With the bind/dlv/isc.org scheme, you just replace the dlv statement with a trust anchor for the root key. With this NeuStar scheme, you start over learning how dnssec actually works.
Yesterday ISC announced that NeuStar and Afilias were supporting DLV:
http://www.cio.com/article/499417/Afilias_Neustar_Adopt_DNSSEC_Validation_Technology
Thought this was interesting and on point for this discussion. Eight months after this post, ComputerWorld finds major registrars nowhere near ready for DNSSEC. Seems like any and all interim measures should be considered—it’s going to be a long wait: http://bit.ly/cI7JSU