On Fri, 2014-02-28 at 14:05 -0500, Michael Richardson wrote: > Paul Wouters <[email protected]> wrote: > > 1 Applications can either do dnssec validation themselves, or trust the > > AD bit. > > > 2 It is undesirable that each application has its own DNSSEC validation > > code, trust anchors and DNS cache. > > > 3 It is undesirable that applications blindly trust the AD bit when > > resolv.conf points to another host as the AD bit could have been > modified > > on the network. > > > 4 In the ideal world tomorrow, each host has its own automatically > > configured, perfectly working validing DNS server and resolv.conf can > > be ignored or is always hardcoded with nameserver 127.0.0.1 > > My problem isn't that the AD is insecure, but that it isn't very useful. > Going back 10 years to the various DNSSEC workshops, one of the things that I > wanted was more information about why there was a validation failure. > > For instance, if I have previously contacted example.com, and I have > it's A/AAAA or more interestingly, the DANE borne public key for the service > I want to reach cached, or leap-of-faith'ed, I don't care as much if the > DNSSEC fails to validate because a signature expired. > > If it fails to validate because the data is correct, I expect the bad data to > be discarded, and for it to try again. At some point (<<5s) the application > needs to get some kind of report that name is not presently available. > (Happy eyeballs, or some other mechanism might want to try something else) > > This is doubly true if I have contact with the user who > can I can: > a) advise of the specific reason for the failure > (which up to now, would be followed by facepalm and one of geeks > goes to fix the problem....) > > b) find out what they want to do now. > > SERVFAIL / "Host now found" is simply not acceptable information. > > For this reason, I think that applications should not set or depend upon the > AD bit, even if the resolver is ::1. They either understand DNS(SEC), or > they use an API call way more sophisticated than getaddrinfo() to do their > connections. Java had the right idea, but the implementation and error > reporting was very poor.
Nothing in this proposal prevents you from doing that for applications you care about. OTOH forcing applications to a completely new API by refusing this proposal on your grounds will guarantee less applications will use DNSSEC. And DNSEC support will rapidly fragment making system-wide management a lot more difficult. I think that prospect is a much worse evil. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
