On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote: > I think the primary concern about that is the possibility > of introducing additional latency, given that we're trying > to minimize the DANE performance hit on clients like browsers,
It's got to be roughly comparable to the WebPKI performance hit. In fact, it will be better because there is no CRL/OCSP for DNSSEC. There may be a few more signatures to check in the DNSSEC case, since it's a proper PKI, so there may be no performance difference. > who tend to be extremely sensitive to delay. We probably > need clearer discussion about what we're trying to optimize > for. But in either case, whether we're using a resolver > in a DNS library or handing it off to a service, encoding > the records in DNS wire format is going to be easiest for > implementers. Several people have talked about writing > their own bare-bones resolver that does not use an entire > DNS library but I don't have any sense that that's going > to be a common case. It's worth talking to people working > with highly constrained devices in any event. Well, I've made a barebones resolver out of the traditional BSD/ISC resolver library as a base. It's almost cheating, yes, but I spent a fair bit of time cleaning and modernizing decades-old code. My codebase still doesn't handle async resolution, but it will, and all in all it's rather simple and small -- small because it relies on a local caching, validating resolver. The hard part is all in the latter. This is not an approach everyone can take: because a local caching, validating resolver daemon is not universally guaranteed to be present. But a local caching, validating resolver ought to be always present: it's the best place for caching that can be trusted by the user. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
