Please explain how. The whole point of DNSSEC is to provide a cryptographic validation that the material put into DNS by the operator of a zone is the same information you get out of DNS when you perform DNSSEC validation.
I'm quite tired of seeing the assertion that "DNSSEC can be re-directed" without people actually walking through HOW that redirection can occur. (Thank you in advance for doing so.)
tptacek already explained this in some detail in the original article that this article is a rebuttal to.
DNSSEC doesn't secure browser lookups: http://marc.info/?l=namedroppers&m=99635022704707&w=2
DNSSEC only guards against the relatively small problem of cache poisoning for individual records, but it can't even do that properly. It all falls apart w/ MITM and the browser wouldn't even be able to detect MITM since it's relying on a flawed source of truth.
http://www.cse.wustl.edu/~jain/cse571-07/ftp/cafecrack/#Sect...
See tptacek's original post for more info. http://sockpuppet.org/blog/2015/01/15/against-dnssec/
In any case, you've made my case for me much better than I could have made it myself. The problem with the 'redirect DNS' argument is that -- it seems -- most people misunderstand that in order to redirect a DNSSEC signed domain, you need to control the 'root' key AND re-sign every domain under that key.
So, can it be done? Yes.
Is it likely to happen? No.
I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero.
Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over?
There are several exceptions to the above example.
First, if "example.com" does not support DNSSEC, there will be no RRSIG record
in the answer and there will not be a DS record for "example.com" in the "com"
zone. If there is a DS record for "example.com", but no RRSIG record in the
reply, something is wrong and maybe a man in the middle attack is going on,
stripping the DNSSEC information and modifying the A records. Or, it could be a
broken security-oblivious name server along the way that stripped the DO flag
bit from the query or the RRSIG record from the answer. Or, it could be a
configuration error.
If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records.
http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g...
If you scroll down that page you'll see higher statistics, such as 70% of all queries being DNSSEC-validated in Sweden, because almost all the ISPs there are now validating.
In the USA, about 23% of all DNS queries are being DNSSEC-validated:
http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1
So the argument that "no one is checking" is no longer true.
Don't think: 1/10,000 chance. Think: 1/1,000,000,000,000,000,000,000 chance.
You are much more likely to die by getting run over by an airplane while walking down the road while also holding a Dalmatian over your head, than to have your DNSSEC signed domain redirected.
The edge case that's being argued about NSA taking over DNSSEC is rather over done.
However, if the argument is denial of requests, so as to block traffic, DNSSEC or not matters not - so the argument again -- is not about DNSSEC as a specific service or architecture.
Without those, everything collapses, and even if they're there, you still might be in very real trouble and not even know it.
Scenario 1: best of all worlds: you're running an awesome mythical OS (edit: or browser plugin as jocluteseh mentioned below) with up to date root keys and you're trying to get to a single zone and you know the root zone key... but the DNSSEC root key was compromised. No one knew this, because there's no way to detect. Your MITM attacker just forges everything. But you feel secure, since you have DNSSEC. ;)
Scenario 2: you're running some really new fancy OS with a pre-shared DNSSEC root key and you make a query for DNSSEC for a zone that you don't have a key for. The recursor simply tells you that that zone doesn't have DNSSEC records. oops.
Scenario 3: you're running a current OS without any root zone anchors at all. You make a query to your preferred recursive DNS server (probably whatever you were handed via DHCP) and it just lies to you, about everything.
I don't understand your point about probabilities. In each of these scenarios, they're not a 1 in anything chance of getting owned in those circumstances.. that's a 1 in 1 chance. All it took was a MITM. To say nothing of the traffic analysis and complete lack of any sort of encryption for passive MITM's.
First: There are two arguments to be had. One is the server side, and one is the browser side. The server is going to know about the key problem if it happens. The client side browser can know, if the client is using plugins like this one:
https://www.dnssec-validator.cz/
Second: Here is the root key: https://www.iana.org/dnssec/files