[dns-operations] resolvers considered harmful

[Mark Allman]

> >  - As noted in the paper 93% of the zones see no increase in our
> >    trace-driven simulations.  That is, they are accessed by at most one
> >    end host per TTL and therefore see no benefit from the shared cache
> >    and hence will see the same load regardless of whether it is an end
> >    host or a shared resolver asking the questions.
> 
> How does this compare to resolvers with one or two (or four) orders of
> magnitude more clients behind them?  

Presumably pretty well.  I only know of old results here, but Jung's
IMW 2001 paper suggests that the cache hit rate levels off after 10-20
users.  I have in mind that there is a more recent (but not last year)
validation of this, but I don't have a reference at my finger tips.

(And, that follows my intuition, BTW.  I.e., that most of the cache hit
rate comes from popular names and you don't need many users to coax
those popular names into the cache.)

> > - There is also a philosophical-yet-practical argument here.  That is,
> >    if I want to bypass all the shared resolver junk between my
> >    laptop and the auth servers I can do that now.  And, it seems to
> >    me that even given all the arguments against bypassing a shared
> >    resolver that should be viewed as at least a rational choice.
> >    So, in this case the auth zones just have to cope with what shows
> >    up.  So, do we believe that it is incumbent upon (say) AT&T to
> >    provide shared resolvers to shield (say) Google from a portion of
> >    the DNS load?
> 
> It doesn’t look to me like your paper has done anything to capture
> what it looks like behind AT&T’s resolvers, so I’m not sure how you
> can come to that sort of conclusion.

Correct.  This is a thought experiment with exemplars that I gave names
to. 

allman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141023/97435416/attachment.sig>