> From: Andrew Sullivan <[email protected]> > I don't think this is the problem at all. The problem is that even if > you can get that out at the end point (and I can, using DNSSEC > Trigger), it does you no good because your application _can't tell_ > what happened. If I'm a web browser programmer, I want to be able to > know whether the DNSSEC validation worked before I start using the > TLSA record. Today, that is too much work (and probably reduces to > "implement a resolver in the browser").
Browsers are certainly not the only application, even if it is true as Paul Vixie recently said that the Internet is little more than the web for most connected computers (e.g. phones). Writing DNSSEC validation code for every application that depends on accurate DNS data would be as crazy as not using libraries and daemons for other local authentication and authorization. The only reasonable solution is to give stub resolvers some of the features of recursive resolvers including DNSSEC validation and caching to make the costs of DNSSEC tolerable. Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
