Paul, if you posit that TTL manipulation is the sole problem w/ caching, then you might be right. My experiences with cache manipulation suggest there are many other problems with the existing caching design as used by the DNS. Your experiences may be different and the assumptions in the draft may include caching behaviours. Based on Richards email, it didn't seem so. --bill On 20October2010Wednesday, at 13:18, Paul Hoffman wrote: > At 12:43 PM -0700 10/20/10, bill manning wrote: >> while I agree that the hierarchical and distributed nature of the DNS is >> a scintillating, shimmering attractant, it is wise to be aware of the baseline >> assumption in your arguement, e.g. that a client will -ALWAYS- ask an authoritative >> source... >> >> The DNS is so designed that caching is a huge component of the scalability of >> the DNS... and its greatest hinderance for such ideas as are laid out in the ENUM >> dip lookup. You can't be assured that the data is timely. This is a strong reason >> to consider that the DNS is _NOT_ the droid you are looking for, in spite of its other >> attractive qualities. > > This line of reasoning is getting old. DNS records have TTLs that are established at the same time, and in the same interface, as the data itself. Caching based on TTLs is trivial to do, and devices that do it wrong usually don't do it at all, which affects long-lived TTLs just as badly. > > If you want to argue "TTL=5 considered harmful", that's fine, but for the kind of data that is being discussed here (someone's phone number, not Google's IP address), the operational difference between TTL=3600 and TTL=5 is lost in the noise. And it's not like the alternative you are hoping they use, HTTP, is any different with respect to caching, systems that ignore the TTLs, and so on. > > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf