On 10/24/14, 6:06 PM, "Doug Barton" <[email protected]> wrote:
>But worse yet, in the operator error case you make such errors painless. >Instead, if they are painful (as in, screw up DNSSEC and you go off line) >then it leads to more people taking DNSSEC seriously, and doing it right. >Of course I realize that the counter-argument is that if DNSSEC fails are >too painful then people will simply not do it. But to the extent that >people use that as a line of reasoning it's simply one more in a long >string of excuses. I think we¹re seeing a collision of how we¹d like the world to work and how it actually works. ;-) Operators are on the front lines here; trust us on the realities of getting stuff like this deployed. While I totally get & 110% agree that when someone screws up their auth records they should feel the pain - and that this pain is a signal to do it better/right the next time - the reality is that the real pain is felt by the DNS operator. Of course I am going to pains to point out who is really to blame here: http://tools.ietf.org/html/draft-livingood-dnsop-auth-dnssec-mistakes-00 Anyway, if a popular domain like google.com or facebook.com or netflix.com was to sign - and then made a mistake - the call centers of an validating operator would pretty much melt down. It wouldn¹t matter that we were not to blame, we¹d feel the pain and people would be angry at us. There¹d be pressure to Œmake the pain stop¹ (and associated costs). Oh - and these days in the U.S. we¹d probably be blamed for ³blocking access² to the site - violating net neutrality (that the facts would say otherwise wouldn¹t matter**). So - two choices - turn off DNSSEC validation for ALL domains or just the one affected (assuming you can prove out it is a mistake and not an attack). Which one is worse? The market has already answered that: Negative Trust Anchors - turn it off in as narrow a case as possible. The question for us here is whether we wish to acknowledge this reality or pretend it does not exist. ;-) >The other problem is that this feature is only really useful in the >DNSSEC ramp-up period. Sure, mistakes are more common now, software is >immature, etc. etc. But if DNSSEC is successful, the software will get >better (it already is a lot better than even a few years ago), and >mistakes will be less common (both on an absolute, and on a percentage >basis). But once you introduce a feature like this, you cannot remove it. We address the timeframe issue in the draft. Certainly you are correct that the feature is still there afterwards, but of course the feature already exists today so the genie is out of the bottle as they say. >So can we please let the functionality of DNSSEC stand as designed, and >not give people a giant trapdoor that they can trigger at the slightest >sign of trouble? Otherwise, why bother? I wouldn¹t say that it is at the Œslightest¹ sign of trouble. This is intended for use when there are major problems. Turning this around: DNSSEC deployment only got as far as it did to date because of NTAs. Without NTAs, I don¹t believe it¹ll go much further. So do we want to help the world understand what it takes to push ahead with DNSSEC? >... and of course, I should point out that adding this as a knob is >utterly pointless, since any reasonably competent validating resolver >operator can engineer their own trapdoor. Yes - we all decided the way to do it was with a Negative Trust Anchor. That¹s what the draft documents. ;-) - Jason Livingood ** From the discussion above (scroll back up to refresh your memory). A good recent example is a claim by some anonymous poster in a Reddit thread that Comcast was blocking Tor. Within hours it went viral and was posted to major news sites, never mind that it wasn¹t true. I posted http://corporate.comcast.com/comcast-voices/setting-the-record-straight-on- tor and yet still to this day there are tweets and reposts about how we block Tor, pointing back to the original news articles. I can¹t wait for what will happen when a major domain breaks if a NTA did not exist. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
