maybe a dumb idea on how to fix the dns problems i don't know....
Tomas L. Byrnes
tomb at byrneit.net
Mon Aug 11 05:01:14 UTC 2008
Unix machines set up by anyone with half a brain run a local caching
server, and use forwarders. IE, the nameserver process can establish a
persistent TCP connection to its trusted forwarders, if we just let it.
That old sneer we used to use against Windows users of not having a
"full featured host" and all.
Windows stub resolvers multiplex through AD to a MS DNS server; which
can easily use TCP to its trusted forwarders; unless they have no DC,
which is not so common; in which case they just use standard queries,
presumably to a patched ISP host (often a Nominum box).
In both cases, the fix is in the local server, which serves only a few
(and in a "full featured host" only one) machines using TCP to its
forwarder, and the chain repeating itself.
I don't see the problem with going to TCP for the recursive queries
here. It's akin to the CDN scaling model, which has worked pretty well.
> -----Original Message-----
> From: Joe Greco [mailto:jgreco at ns.sol.net]
> Sent: Sunday, August 10, 2008 3:14 PM
> To: Chris Paul
> Cc: nanog at merit.edu
> Subject: Re: maybe a dumb idea on how to fix the dns problems
> i don't know....
>
> > But we only care about TCP connection setup time in *interactive*
> > sessions (a human using something like the web). If you have a
> > persistent connection to your dns server from your dns resolver on
> > your browser machine, you just send the request.... no TCP setup
> > there at all. You can even pool connections. We do this
> stuff in LDAP all the time.
> >
> > How does TCP resolution work in most resolver libraries? A TCP
> > connection for each lookup? That is kind of dumb isn't it,
> speaking of
> > dumb.... I actually don't know. Not much of a coder, so
> I'll let you
> > coders check your code and get back to me on that...
> >
> > well.. maybe i'll fire up snort or wireshark and check it out later
> > with some different dns libs....
>
> Pretending for a moment that it was even possible to make
> such large scale changes and get them pushed into a large
> enough number of clients to matter, you're talking about
> meltdown at the recurser level, because it isn't just one
> connection per _computer_, but one connection per _resolver
> stub_ per _computer_ (which, on a UNIX machine, would tend to
> gravitate towards one connection per process), and this just
> turns into an insane number of sockets you have to manage.
>
> For your average ISP recurser where they only have 50,000
> people online at any given time, this could still be half a
> million open sockets. We already know this sort of thing
> doesn't scale well.
>
> This is very broken in any number of other ways. This
> message is not intended to imply otherwise.
>
> ... JG
> --
> Joe Greco - sol.net Network Services - Milwaukee, WI -
> http://www.sol.net "We call it the 'one bite at the apple'
> rule. Give me one chance [and] then I won't contact you
> again." - Direct Marketing Ass'n position on e-mail spam(CNN)
> With 24 million small businesses in the US alone, that's way
> too many apples.
>
>
More information about the NANOG
mailing list