Similarly, which ISPs are protected on the recursive DNS side?

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

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.

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.

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