[dns-operations] resolvers considered harmful

Paul Wouters paul at nohats.ca
Thu Oct 23 16:11:58 UTC 2014

On Thu, 23 Oct 2014, Mark Allman wrote:

>  - I don't know what your load is, but do you have any idea how much
>    your load will increase if shared resolvers did not shield you from
>    some of it?  We quantify this a little in our paper (for .com).  We
>    should use numbers to talk about these things instead of just waving
>    our hands at some boogie man.

You mean like the numbers Kaminsky and I provided for some of the large
scale DNS caches: http://dankaminsky.com/2011/01/05/djb-ccc/#caching

cache hit rate is about 80%-90% for those caching you think can be
removed. Note that this cache hit rate is heavilly skewed because of
the facebook "one time" uncachable hostnames they were using at the
time. If you also include the fact that these caches were feeding
other caches, you will see the enormous amount of queries you are
suggesting to unleash on authoritative nameservers on the internet.

And I'm not even counting the 99% of nonsense queries now hitting the
TLD servers that would get amplified by missing the caching servers
negative cache times.

>  - And, I'd spin this around on you ... You clearly care about your 3
>    poor nameservers.  That is natural and rational.  But, why do you
>    think it is someone else's job to run a cache to shield you from
>    load?

If you really believe the mode of the internet should be that the
weakest device should be able to deal with the largest volume load the
world can throw at it, there is not much point discussing this further.
I'm just happy that people like Van Jacobson designed the internet.

> Why should we at ICSI run a shared resolver for your benefit?

Because thousands of ISP run caches for your servers' benefit.
Using your reasoning, we should drop all the exponential backoff
in our TCP/IP protocols. You'll just have to deal with the load,
and if you get blasted off the net it's clear your fault for being

>    If we get benefit and it happens to help you, too, great.  But, I
>    can tell you that we certainly don't factor your load into our
>    considerations of how to run our infrastructure.

Good luck expanding that infrastructure.

>> Suggesting to dismantle the largest distributed database in the world
>> and thinking you can get away with it is a very ill thought plan not
>> rooted in reality.
> Well, ...
>  - We root our argument in some empiricalism, anyway.  That is more
>    than you're doing.

See the above link that was also used to refute djb's dnscurve claims
that dns caches could be removed from the internet.

>    are talking about eliminating optional caches from the system.  The
>    actual database embodied in the auth servers remains untouched.  I
>    have had many conversations with people over the last year about
>    this idea and I always find it sort of interesting that resolvers
>    are viewed as a required component of the system and that it so much
>    blows people's minds that the system could or should work without
>    them.
>    (Yet, web caches---which one can view as pretty analogous---do not
>    seem to rise to the level.  I.e., folks seem to view them for what
>    they are---perhaps a helping hand---and not as some crucial
>    component of the system.)

web caches are opt-in. Whoever runs them designs those caches to take the
additional load. When their web caches then go down for some reason,
their origin servers are also completely blown off the web. In fact,
that mere fact is the business model of companies like CloudFare. They
are successfull and making sure organisations can exist without needing
the kind of server farms to deal with the global internet at large at
peak time. It is quite the opopsite of you what you are suggesting we
do with DNS.

>  - Doing what we have always done because we have always done it and
>    not thinking about the implications of that seems like a lousy plan,
>    too, BTW.

You seem to make assumptions that I have no numbers and haven't thought
about these issues before.


More information about the dns-operations mailing list