[dns-operations] Getting rid of ISP's recursive DNS servers? (Was: Eircom "DNS Attacks" ?
Paul Vixie
vixie at isc.org
Sun Jul 19 17:18:58 UTC 2009
> Date: Sun, 19 Jul 2009 11:10:51 +0200
> From: Stephane Bortzmeyer <bortzmeyer at nic.fr>
>
> > > I wonder what do the root name server operators think about his
> > > suggestion?
> >
> > Uhm, what have the roots got to do with it?
>
> Because, if any SOHO (and, why not, residential users) suddenly starts to
> have its own complete resolver, the load on root name servers (and TLD
> name servers) will increase (see Bill Manning's article for actual
> measurements).
as a rootop, i am completely unworried about this. i worry that many of
these resolvers will be misconfigured in a way that they cannot hear our
responses and so endlessly repeat their queries to us, but as to actual
load from correctly functioning resolvers, i think that most rootops would
say "if the load isn't erroneous then just bring it on and we'll solve any
provisioning problems that come up."
> Cache sharing (between the clients of one ISP) is supposed to decrease
> the load on authoritative name servers, after all.
as long as there *is* a cache in front of every application, then sharing
these caches between large groups of users has only a second-order effect.
in other words i'm happy to tell two hundred million endsystem caches how
to find the COM nameservers, and i'm comfortable with them being powered
off a dozen times a day and thus asking me the same question that often;
it's when caches never hear my responses, or don't remember them at all,
that the root nameserver system feels some pain.
so, this proposed configuration change (no cache-sharing, every SOHO has
their own) would have an effect barely perceptible beyond the noise margin
for the authority servers i'm familiar with, including f-root. i do dearly
wish that sturgeon (see <http://en.wikipedia.org/wiki/Sturgeon's_Law>) was
right and that only 90% of queries were crud. sturgeon was an optimist.
More information about the dns-operations
mailing list