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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf