On Feb 6, 2014, at 9:16 AM, Viktor Dukhovni <[email protected]> wrote:
> On Thu, Feb 06, 2014 at 04:55:24AM +0000, Viktor Dukhovni wrote: > >> All I know is that libresolv (used in Postfix) returns the TTL with >> each RR. This is only a single data point, so I would not be at all >> shocked to discover that other stub resolvers are different in this >> regard, just very mildly surprised. > > OK, I also used the DNS client library in Python once for SRV record > lookups, and this too returned TTLs. > > Independently of Mark (who beat me to the punch with a more foreceful > objection), I was also wondering whether perhaps you're misremembering > the issue. Without DANE, browsers have no need for explicit DNS > lookups, they just lookup network address information via getaddrinfo() > and friends. So perhaps the issue you had in mind was that > getaddrinfo() returns no TTLs and no validation status. This is > a well known limitation. > > Once applications are doing explicit DNS lookups (SRV, TLSA, ...) > perhaps TTLs are generally available along with the RRDATA. To follow all of this up: I think Andrew was illustrating a couple of important issues, and one of them is that we cannot always all rely on full knowledge of how people will adopt DANE processing (look at the TTL, don't look at AD, etc.). Even if we fully specify how it should be used (only look here, don't look over there, etc.), we still have to be liberal in what we accept. Rather than focusing narrowly on how an RP might or might not find SMIMEA RRs, consider an incremental deployment case whereby someone rolls _SOME_ of their constituency over to DANE, and leaves some of their clients on (say) AD. Now, I need my RPs (the MUAs) to know the difference between ``DANE doesn't want you to use a cert,`` and ``you may go find the cert somewhere else.'' IMHO, the TTL discussion is useful because it illustrates that not everyone will even _know_ to go looking for it, but we might want to realize that there are other issues we will have to confront when people consider operational rollouts of this. Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
