In a message written on Mon, Oct 03, 2011 at 09:27:46AM -0400, Danny McPherson wrote:
User Exercise: What happens when you enable integrity checking in an application (e.g., 'dnssec-validation auto') and datapath manipulation persists? Bonus points for analysis of implementation and deployment behaviors and resulting systemic effects.
I think this is a (to some on the list) cryptic way of asking "If all your routes to the server go to someone masquerading, what happens when you try to validate that data?" The question being if you configure your nameserver to validate the root, but don't get signed answers back will your nameserver refuse to serve up any data, effectively taking you and your users offline? The answer should be no. This is part of why there are 13 root servers. If a nameserver is told the root is signed and it gets unsigned answers from one of the 13, it should ignore them and move on. I do not off the top of my head know all the timeouts and implementation dependant behaviors, but also remember that a up caching resolver will make approximately 1 query to the root per day for _valid_ names, but many queries per day for invalid names. Thus the impact to valid names should be minimal, even in the face of longer timeouts. Is there enough operational experience with DNSSEC? No. Can we fix that by saying it's not good enough yet? No. Run it. The people who write nameserver software are comitted to fixing any issues as quickly as possible, because it is our best way to secure DNS.
Network layer integrity techniques and secure routing infrastructure are all that's going to fix this. In the interim, the ability to detect such incidents at some rate faster than the speed of mailing lists would be ideal.
Network layer integrity and secure routing don't help the majority of end users. At my house I can choose Comcast or AT&T service. They will not run BGP with me, I could not apply RPKI, secure BGP, or any other method to the connections. They may well do NXDOMAIN remapping on their resolvers, or even try and transparently rewrite DNS answers. Indeed some ISP's have even experimented with injecting data into port 80 traffic transparently! Secure networks only help if the users have a choice, and choose to not use "bad" networks. If you want to be able to connect at Starbucks, or the airport, or even the conference room Wifi on a clients site you need to assume it's a rogue network in the middle. The only way for a user to know what they are getting is end to end crypto. Period. As for the speed of detection, its either instantenous (DNSSEC validation fails), or it doesn't matter how long it is (minutes, hours, days). The real problem is the time to resolve. It doesn't matter if we can detect in seconds or minutes when it may take hours to get the right people on the phone and resolve it. Consider this weekend's activity; it happened on a weekend for both an operator based in the US and a provider based in China, so you're dealing with weekend staff and a 12 hour time difference. If you want to insure accuracy of data, you need DNSSEC, period. If you want to insure low latency access to the root, you need multiple Anycasted instances because at any one point in time a particular one may be "bad" (node near you down for maintenance, routing issue, who knows) which is part of why there are 13 root servers. Those two things together can make for resilliance, security and high performance. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/