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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to