On Sun, Oct 26, 2014 at 9:52 AM, Livingood, Jason < [email protected]> wrote:
> > Warren - Your suspicions are right on the money. A good reference is > http://dns.comcast.net/images/files/dnssec_validation_failure_nasagov_20120118_final.pdf. > Take a look at the flak we got on page 9 – truly fascinating. In any case, > posting on Twitter and our DNS website is what we have been trying to do > based on how people respond. And in nearly every case I have seen so far we > have had PR involved since we have usually gotten press calls about it or > could expect to (in the NASA.gov example it was ironically enough MSNBC). > > Unless and until DNSSEC and DNS management is fully automated everywhere, use of DNSSEC information is going to require curation. The problem here is a very common one in security: Every security problem is simple if you only recognize one problem. It is the need to balance different concerns that makes security hard. This is also why I try to resist the narrowly focused WG charters designed to produce a quick specification that only meets half the real world concerns. In the real world, the goal is to be able to connect to the correct site. This means that there are two (main) failure modes, not one: 1) Client connects to the wrong site. 2) Client is unable to connect to the correct one. Any decision process that is going to be implemented in the end point has to be able to respond to every set of inputs in a deterministic way. One of the reasons the DKIM policy discussion was so nonsensical was that people would suggest solving problem A by adopting decision strategy X and problem B with strategy Y. But there was no deterministic means of choosing between X and Y. So the implementations would have to work by magic. Moving the decision point to the resolver allows a more powerful decision strategy because a resolver can bring more information to bear. Instead of discarding expired records, a high volume resolver can make use of them to make better decisions. So if the DNSSEC records have expired but the A records have not changed, keep serving them. Negative trust anchors are one approach to curating the DNSSEC data but there is a much larger family of possible approaches and curating DNSSEC for A records is not the same as curating for DANE or security policy records.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
