use the 'reserved for Documentation' addresses then
http://tools.ietf.org/html/rfc5737 lists them
It isn’t actually news as such: while the DoE’s own Sandia Labs has warned that the notorious Stop Online Piracy Act is a threat to the deployment of secure DNS – DNSSEC to its friends – the fragility of the protocol has been discussed for ages. The problem is this: an end-to-end protocol is the simplest way to ensure that a …
http://tools.ietf.org/html/rfc5737 lists them
Let me point out that in order to convincingly fake a DNSsec-signed label you'd have to have access to the relevant key. And it just so happens they need only throw a bit of legalese at verisign (something with the patriot act, or a national security letter perhaps) and they could do whatever they pleased --undetectably-- with anything in dot-com and dot-net. That's most of what they'd like to target anyway. Most of the others are either American or ccTLDs and therefore mostly unimportant. But should any of those become a problem, there's always the root key. And who controls the one key to rule them all? That's right, the USoA government, by dint of basically owning ICANN despite pro-forma protests that this is not the case, honest (so why isn't DeNIC controlling dot-net then, eh?). The rest is technical details and therefore unimportant to politicians. Sorted.
This attack is prevented by DNSSEC chains of trust. Just because Verisign sign the root and .com, doesn't mean they can undetectably fake a response from further down the tree, because they don't have the keys for that.
They could sign a false delegation, in which case it would be instantly detectable because it wouldn't match any other published delegation data.
You could execute this attack on a single target, assuming you can sit inline with their IP transit and spoof DNS responses from the listed nameserver, but that isn't SOPA.
Finally, no-one owns the root key. You should take a look at the root signing ceremony. That's quite of list of people you'll have to compromise. Have fun working out how to hack it.
if you sign a zone, *you* have its dnssec keys, not verisign. the only action your parent zone can do - verisign in the case of .com or .net - is delete your delegation or the info that says it's signed. which they could do anyway. this would not be undetectable. in fact it would be glaringly obvious. people usually notice when names in the dns fail to resolve.
as for "the one key to rule them all", you've got that utterly wrong too.
the only thing the parent zone could do would be to remove the child's delegation or delete the info that says the delegation is signed. that could not go unnoticed. if the root tried to do that to a tld, it would be very, very far from undetectable. it would also create an almighty shit-storm because it would destabilise the security and stability of the internet, inferfere in matters of national sovereignty, force a united nations organisation to "take control" of the root, etc, etc.
you clearly don't understand how the root zone is signed either. no single entity has access to the root zone's key signing key: the one key that really does rule them all. the system and processes were intentionally designed that way. access to this key requires a group of trusted community representatives to gather in one place so that the key can be assembled. [the details are more complicated than that and would take too long to explain here.] the upshot of this is iana or icann would need these trusted community representatives to co-operate with any court orders.
the names and nationalities of these representatives is published. the majority of them are not american citizens.
i think you need to get yourself a new tin-foil hat 'cos the one you're wearing is obviously defective.
there, fixed it.
Politicians, that is
Didn't politicians once legislate that Pi = 3 in law?
Idiots isn't nearly strong enough. On any rational scale, politicians would have to have negative IQs, if zero is taken to be the result of random guessing.
... Exposing "personal information, credit card data, e-mails, documents, stock data, and other sensitive information" unencrypted over TCP/IP has been completely daft since ... oh, I dunno ... Flag Day?
C'mon folks, pay attention ... if you wouldn;t shout it from the rooftops, don;t put it online unencrypted. It ain;t exactly rocket science.
[please pardon semi-colon in place of apostrophe ... I have a 14 week old Greyhound at my elbow, and am kinda out of my normal typo(e)ing symmetry :-)]
correct, but when was the last time your DNS client used DNSSEC to resolve website address you went on to connect through SSL?
I use DNSSEC all the time, for distribution of my ssh keys.
If you visit https://dnssec.imperialviolet.org/ with Chrome then you have also just used a DNSSEC chain of trust to validate the hash of a SSL certificate.
I'd like to acknowledge the small victory achieved by the pedants for today's footnote...