Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

[Bob Harold <[e-mail]>]

On Wed, Jul 20, 2016 at 9:40 AM, 延志伟 <[e-mail]> wrote:

> Hi, Ralf, I understand prefetch by the recursive server and it is the
> common case.
> [https://tools.ietf.org/html/draft-liu-dnsop-dns-cache-00]
> But if recursive server asks: give me the a RR and all the related RRs
> under your domain. And the authoritative server sends back  the requested
> domain name RR and the related RRs under its domain. It can also improve
> the efficiency.
> Zhiwei Yan
>
> 在 2016-07-20 20:48:07，"Ralf Weber" <[e-mail]> 写道：
> >Moin!
> >
> >On 20 Jul 2016, at 14:36, 延志伟 wrote:
> >> But anyway, let's go back to the scenario considered by our draft to
> >> illustrate its necessity.
> >> I show an example as following (although I think we have described it
> >> several times. :-)):
> >> In order to visit the www.baidu.com, the user has to query
> >> www.baidu.com and many other related domain names
> >> (for many related resources such as images, java script, html, flash,
> >> video, sound), then a series of queries happen as the attached figure
> >> shows.
> >So what. If your recursive resolver is used by many people these records
> >will be in the cache. There will be no gain. Now of course if your
> >resolver only serves you that might be the case, but that is not the way
> >DNS was designed or is operated today. Oh and your example have out of
> >zone queries (also very common like facebook.com asking for fbcdn.com)
> >that can not be solved by this anyway. There is no better tool than a
> >prefetching hot resolver for lots of users to solve this problem.
> >
> >So long
> >-Ralf
>
>
> Some thoughts:
With CDN's answering based on location, are they using very short TTL's,
and thus the cache goes 'cold' quite frequently?
And even if users of large pre-fetching resolvers are not helped, what if
it helps users of smaller non-pre-fetching resolvers?

-- 
Bob Harold